From rehn at openjdk.org Tue Aug 1 05:31:51 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 1 Aug 2023 05:31:51 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: On Mon, 31 Jul 2023 16:05:13 GMT, Antonios Printezis wrote: >> What the title says. I started with the aarch64 version but changed it quite heavily. >> >> I haven't done anything with the macro assembler before, so detailed / picky feedback is very welcome! > > Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: > > changes based on code review feedback Thanks, looks good to me! You also have some tests here: test/hotspot/jtreg/compiler/intrinsics/sha/sanity/TestMD5xxx I'll take it for a spin. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1975: > 1973: assert_different_registers(dst, tmp); > 1974: assert_different_registers(src, tmp); > 1975: assert(shift < 64, "shift amount must be < 64"); shift should probably be less than 32. src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 599: > 597: assert_cond(dest != nullptr); \ > 598: int64_t offset = dest - pc(); \ > 599: guarantee(is_simm13(offset) && ((offset % 2) == 0), \ bool is_even(intx x) instead of mod ? ------------- PR Review: https://git.openjdk.org/jdk/pull/15090#pullrequestreview-1556160780 PR Review Comment: https://git.openjdk.org/jdk/pull/15090#discussion_r1280106727 PR Review Comment: https://git.openjdk.org/jdk/pull/15090#discussion_r1280121528 From jwaters at openjdk.org Tue Aug 1 05:58:51 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 1 Aug 2023 05:58:51 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: <_-f2Qyuw5hNzAgY00aVQLfJoHmS6oqFbBXeNmB1CK54=.df8cc296-bbe1-4d46-89d1-d149d9fb6d01@github.com> On Fri, 28 Jul 2023 07:50:19 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > zPhysicalMemoryBacking_windows.cpp Reopening - To fix the errors that were deemed as needing a fix ------------- PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1659616162 From duke at openjdk.org Tue Aug 1 06:29:28 2023 From: duke at openjdk.org (sid8606) Date: Tue, 1 Aug 2023 06:29:28 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for s390x (Big Endian). sid8606 has updated the pull request incrementally with one additional commit since the last revision: Fix typo Signed-off-by: Sidraya ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14801/files - new: https://git.openjdk.org/jdk/pull/14801/files/b81d5bb7..924b45bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14801.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801 PR: https://git.openjdk.org/jdk/pull/14801 From duke at openjdk.org Tue Aug 1 06:29:32 2023 From: duke at openjdk.org (sid8606) Date: Tue, 1 Aug 2023 06:29:32 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 14:27:38 GMT, Amit Kumar wrote: >> src/hotspot/cpu/s390/frame_s390.cpp line 228: >> >>> 226: >>> 227: bool frame::upcall_stub_frame_is_first() const { >>> 228: assert(is_upcall_stub_frame(), "must be optimzed entry frame"); >> >> typo: s/optimzed/optimized > > @sid8606 you left this one. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1280157849 From luhenry at openjdk.org Tue Aug 1 06:49:53 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Tue, 1 Aug 2023 06:49:53 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: On Mon, 31 Jul 2023 16:05:13 GMT, Antonios Printezis wrote: >> What the title says. I started with the aarch64 version but changed it quite heavily. >> >> I haven't done anything with the macro assembler before, so detailed / picky feedback is very welcome! > > Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: > > changes based on code review feedback src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1972: > 1970: > 1971: // rotate left with shift bits, 32-bit version > 1972: void MacroAssembler::rol32_imm(Register dst, Register src, uint32_t shift, Register tmp) { You could actually name it `rolw_imm` so that you can easily match it to [rolw](https://github.com/riscv/riscv-bitmanip/blob/6d33919c661a838f6ae89a05650b3ee6aa303440/bitmanip/insns/rolw.adoc#L3) when Zbb is available. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15090#discussion_r1280173799 From stefank at openjdk.org Tue Aug 1 06:57:52 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 1 Aug 2023 06:57:52 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 09:16:32 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> zPhysicalMemoryBacking_windows.cpp > > src/hotspot/os/windows/gc/x/xMapper_windows.cpp line 253: > >> 251: >> 252: if (!res) { >> 253: fatal("Failed to unreserve memory: " INTPTR_FORMAT " " SIZE_FORMAT "M (%ld)", > > Here, and in many other places: > > PTR_FORMAT -> INTPTR_FORMAT both macros are the same. > > We use PTR_FORMAT in many many places to print pointers. I prefer it to INTPTR_FORMAT, since it does not convey the assumption of a type. After all, the type does not matter: we just print the pointer as a raw hex value. Also, INTPTR suggests intptr_t which suggests signedness, which has no place here. > > *If* we want to change this, we should first agree on the INTPTR_FORMAT vs PTR_FORMAT difference. And why we use intptr_t in many places that actually call for an uintptr_t. > > But I would not change it. There is no need. Yes. Please keep using PTR_FORMAT to print what's semantically a pointer in ZGC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1280183227 From clanger at openjdk.org Tue Aug 1 07:42:54 2023 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 1 Aug 2023 07:42:54 GMT Subject: [jdk21] Integrated: 8313316: Disable runtime/ErrorHandling/MachCodeFramesInErrorFile.java on ppc64le In-Reply-To: References: Message-ID: <1LDEj08O83PjBGGOtvAS_6VAy4-ANeOSqoIOWjTo4ls=.1092b7c0-d71c-4c2c-a820-6486c6186d28@github.com> On Mon, 31 Jul 2023 10:38:44 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of [JDK-8313316](https://bugs.openjdk.org/browse/JDK-8313316), commit [807ca2d3](https://github.com/openjdk/jdk/commit/807ca2d3a1d498f8d51a33b062a003c96344d9b7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Christoph Langer on 31 Jul 2023 and was reviewed by Matthias Baesken. > > Thanks! This pull request has now been integrated. Changeset: 731b2e94 Author: Christoph Langer URL: https://git.openjdk.org/jdk21/commit/731b2e94b98233b357b819f2c4a2f8f57d3f29ae Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8313316: Disable runtime/ErrorHandling/MachCodeFramesInErrorFile.java on ppc64le Reviewed-by: mbaesken Backport-of: 807ca2d3a1d498f8d51a33b062a003c96344d9b7 ------------- PR: https://git.openjdk.org/jdk21/pull/152 From rehn at openjdk.org Tue Aug 1 08:03:40 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 1 Aug 2023 08:03:40 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: <5WKW5rVV3lZiDWvAqpOtIynIUL1Hny8AqsVL15ItMUQ=.0dc906bf-fdac-4191-ad4c-9392bbc7bbc2@github.com> On Mon, 31 Jul 2023 16:05:13 GMT, Antonios Printezis wrote: >> What the title says. I started with the aarch64 version but changed it quite heavily. >> >> I haven't done anything with the macro assembler before, so detailed / picky feedback is very welcome! > > Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: > > changes based on code review feedback Thumbs up from me. ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15090#pullrequestreview-1556386441 From rehn at openjdk.org Tue Aug 1 08:03:42 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 1 Aug 2023 08:03:42 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: On Tue, 1 Aug 2023 05:28:46 GMT, Robbin Ehn wrote: > Thanks, looks good to me! > > You also have some tests here: test/hotspot/jtreg/compiler/intrinsics/sha/sanity/TestMD5xxx > > I'll take it for a spin. Thumbs up! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15090#issuecomment-1659772908 From dholmes at openjdk.org Tue Aug 1 08:21:01 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Aug 2023 08:21:01 GMT Subject: RFR: 8307312: Replace "int which" with "int cp_index" in constantPool [v3] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 16:46:19 GMT, Matias Saavedra Silva wrote: >> Many accessors in the constant pool take an argument "int which" that is meant to represent an ambiguous index. Despite this, several methods in the API use "int which" when the argument is exclusively a constant pool index. This patch aims to rename all of these instances to "int cp_index" in order to be more clear and to distinguish methods that take constant pool indices and methods that use derived indices. >> >> The callers have been updated to use more clear naming as well. Verified with tier 1-5 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Reverted resolved_constant_at Thanks for rolling back some of those changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15027#issuecomment-1659807693 From dholmes at openjdk.org Tue Aug 1 08:35:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Aug 2023 08:35:49 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 15:27:36 GMT, Ashutosh Mehra wrote: >> @ashu-mehra you indicated that you had only done two basic manual tests to check the output. You need to check it for the cases that I flagged too. In the VM every top-level class is its own nest-host, but that is not expressed in a classfile attribute (it is just the defined semantics) so displaying this as-if it were an explicit attribute may not be right. > > @dholmes-ora I confirmed there is no nest-host or nest-members attributes generated by this patch for a top level class which doesn't have any nest-members. Is that what you wanted to verify? @ashu-mehra That was one case. I also want to know that you have tested deeply nested classes; and hidden classes (if applicable). Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15005#issuecomment-1659831895 From dholmes at openjdk.org Tue Aug 1 08:59:56 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Aug 2023 08:59:56 GMT Subject: RFR: 8313202: MutexLocker should disallow null Mutexes [v3] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 13:23:15 GMT, Aleksey Shipilev wrote: >> As seen in [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081), it is fairly easy to pass nullptr `Mutex` to `MutexLocker` by accident, which would just silently avoid the lock. >> >> There are a few places in Hotspot where we pass `nullptr` to simulate re-entrancy and/or conditionally take the lock. Those places can be more explicit, and the default `MutexLocker` can disallow nullptrs for extra safety. >> >> Open for some bikeshedding on the names of the new `MutexLockers`. Particularly `ReentrantMutexLocker` might lull readers into believing it does safepoint checks on re-entrant "lock", which it actually does not do. >> >> More thorough testing with different GC/JIT combinations is running now, we might find more issues there. Meanwhile, please comment on the approach. >> >> Additional testing: >> - [x] `grep -R "MutexLocker " src/hotspot | grep -i null`, no hits >> - [x] `grep -R "MutexLocker " src/hotspot | grep -i ?`, no hits >> - [x] Linux AArch64 fastdebug, `tier1 tier2 tier3` (re-run in progress) > > Aleksey Shipilev 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 six additional commits since the last revision: > > - Accept one more potentially nullptr mutex > - Merge branch 'master' into JDK-8313202-mutexlocker-nulls > - Replace ReentrantMutexLocker with ConditionalMutexLocker > - Workaround for JDK-8313210 > - Fixing CodeCache analytics > - Initial work Using `ConditionalMutexLocker` for all cases is acceptable naming wise. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15043#pullrequestreview-1556492324 From jbechberger at openjdk.org Tue Aug 1 09:39:52 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 1 Aug 2023 09:39:52 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v3] In-Reply-To: References: Message-ID: <4uJnQFgo1Qa2F5wS9m8g0vVOslP4t5Yhg-_gSb8B6jo=.8fde46c3-0863-4bb6-b12f-a86f33771b54@github.com> On Mon, 31 Jul 2023 07:12:21 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust COPYRIGHT year info Marked as reviewed by jbechberger (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15065#pullrequestreview-1556571647 From vkempik at openjdk.org Tue Aug 1 11:48:50 2023 From: vkempik at openjdk.org (Vladimir Kempik) Date: Tue, 1 Aug 2023 11:48:50 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: Message-ID: <7tSk1XE5GNwLWxTCIP8UKD0KlOHzA0ftpWADEyYle8Y=.a6c7d403-365a-451f-a9b2-30d3f41cf33b@github.com> On Mon, 24 Jul 2023 08:22:52 GMT, Ilya Gavrilin wrote: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Hello, anyone with c2 knowledges can please take a look ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14991#issuecomment-1660148250 From tonyp at openjdk.org Tue Aug 1 12:48:52 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Tue, 1 Aug 2023 12:48:52 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: On Tue, 1 Aug 2023 06:44:20 GMT, Ludovic Henry wrote: >> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: >> >> changes based on code review feedback > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1972: > >> 1970: >> 1971: // rotate left with shift bits, 32-bit version >> 1972: void MacroAssembler::rol32_imm(Register dst, Register src, uint32_t shift, Register tmp) { > > You could actually name it `rolw_imm` so that you can easily match it to [rolw](https://github.com/riscv/riscv-bitmanip/blob/6d33919c661a838f6ae89a05650b3ee6aa303440/bitmanip/insns/rolw.adoc#L3) when Zbb is available. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15090#discussion_r1280576909 From tonyp at openjdk.org Tue Aug 1 12:48:54 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Tue, 1 Aug 2023 12:48:54 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: On Tue, 1 Aug 2023 04:52:49 GMT, Robbin Ehn wrote: >> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: >> >> changes based on code review feedback > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1975: > >> 1973: assert_different_registers(dst, tmp); >> 1974: assert_different_registers(src, tmp); >> 1975: assert(shift < 64, "shift amount must be < 64"); > > shift should probably be less than 32. Copy pasta! Will fix. > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 599: > >> 597: assert_cond(dest != nullptr); \ >> 598: int64_t offset = dest - pc(); \ >> 599: guarantee(is_simm13(offset) && ((offset % 2) == 0), \ > > bool is_even(intx x) instead of mod ? I'll change it, but note that I didn't modify the condition, just the error message! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15090#discussion_r1280574819 PR Review Comment: https://git.openjdk.org/jdk/pull/15090#discussion_r1280576631 From tonyp at openjdk.org Tue Aug 1 12:48:47 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Tue, 1 Aug 2023 12:48:47 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: On Tue, 1 Aug 2023 08:00:12 GMT, Robbin Ehn wrote: > You also have some tests here: > test/hotspot/jtreg/compiler/intrinsics/sha/sanity/TestMD5xxx Thanks, I'll run those too! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15090#issuecomment-1660241816 From mbaesken at openjdk.org Tue Aug 1 13:05:50 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 1 Aug 2023 13:05:50 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v3] In-Reply-To: References: Message-ID: <1Oo8TxEUN6YJPGSaS6uyIYIO4KwS4zsTCVGbJyDUyhU=.5a5b24dd-6d2c-4613-a006-05a1b2b16816@github.com> On Mon, 31 Jul 2023 07:12:21 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust COPYRIGHT year info Hi Johannes, thanks for the review ! May I get a second review please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15065#issuecomment-1660267873 From kbarrett at openjdk.org Tue Aug 1 13:19:53 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 1 Aug 2023 13:19:53 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 07:50:19 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > zPhysicalMemoryBacking_windows.cpp Most/all of the PTR_FORMAT => INTPTR_FORMAT changes should not be made. Especially those where the argument is the result of a call to p2i. The p2i thing plus the definition of PTR_FORMAT are a bit of a kludge to work around the variations in the implementations of "%p", which is what one might wish PTR_FORMAT was using. I've not looked at the rest yet. It would be easier to do so once the PTR_FORMAT => INTPTR_FORMAT changes were removed. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15063#pullrequestreview-1556982044 From kbarrett at openjdk.org Tue Aug 1 13:19:56 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 1 Aug 2023 13:19:56 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 09:27:06 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> zPhysicalMemoryBacking_windows.cpp > > src/hotspot/os/windows/os_windows.cpp line 3382: > >> 3380: if (Verbose && PrintMiscellaneous) { >> 3381: reserveTimer.stop(); >> 3382: tty->print_cr("reserve_memory of %zx bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes, > > SIZE_FORMAT. Regarding SIZE_FORMAT - https://bugs.openjdk.org/browse/JDK-8256379. Some people have been replacing uses of SIZE_FORMAT when touching the relevant code for other reasons. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1280628344 From tonyp at openjdk.org Tue Aug 1 13:23:35 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Tue, 1 Aug 2023 13:23:35 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v3] In-Reply-To: References: Message-ID: <_3A-YHpxF4GLZJRDOh2JqHw29MG78bo8k2kXJihlPyY=.3a17b3a3-da67-42b5-a279-3df864a36b11@github.com> > What the title says. I started with the aarch64 version but changed it quite heavily. > > I haven't done anything with the macro assembler before, so detailed / picky feedback is very welcome! Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: more changes based on code review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15090/files - new: https://git.openjdk.org/jdk/pull/15090/files/1a840b39..01d6e64a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15090&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15090&range=01-02 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15090.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15090/head:pull/15090 PR: https://git.openjdk.org/jdk/pull/15090 From tonyp at openjdk.org Tue Aug 1 13:23:36 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Tue, 1 Aug 2023 13:23:36 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: On Tue, 1 Aug 2023 12:45:25 GMT, Antonios Printezis wrote: > You also have some tests here: test/hotspot/jtreg/compiler/intrinsics/sha/sanity/TestMD5xxx Yep, all tests in test/hotspot/jtreg/compiler/intrinsics/sha/sanity pass. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15090#issuecomment-1660300402 From tonyp at openjdk.org Tue Aug 1 14:28:50 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Tue, 1 Aug 2023 14:28:50 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v4] In-Reply-To: References: Message-ID: <0X4CTfy6_aoLJlq2zhizHW5fMANKRjI_Dq740ocRMY8=.797dd57e-310c-4afb-86f0-ab5a06bc1c1f@github.com> > What the title says. I started with the aarch64 version but changed it quite heavily. > > I haven't done anything with the macro assembler before, so detailed / picky feedback is very welcome! Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: use roriw for the rotate left operation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15090/files - new: https://git.openjdk.org/jdk/pull/15090/files/01d6e64a..32232492 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15090&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15090&range=02-03 Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15090.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15090/head:pull/15090 PR: https://git.openjdk.org/jdk/pull/15090 From jvernee at openjdk.org Tue Aug 1 15:46:21 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 1 Aug 2023 15:46:21 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API Message-ID: This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on unsupported platforms. All tests are turned on by default, instead of being skipped when the linker is not present. 10. https://github.com/openjdk/panama-foreign/pull/851 Minor code tweaks to ensure the JIT can constant fold through native access checks if the accessing class is statically known (see commit/original PR for changes). 11. https://github.com/openjdk/panama-foreign/pull/853 Remove all the `@PreviewFeature` annotations from the API. Update all `@since` tags in the Javadoc to `@since 22` (per [JEP 12](https://bugs.openjdk.org/browse/JDK-8195734)). Update tests and benchmarks to no longer build and run using `--enable-preview` (or the `@enablePreview` jtreg tag). I want to call out in particular that this patch finalizes the FFM API (by moving it out of preview), and requires all JDK implementations to implement it. Most ports already have full FFM API support. The ones that are missing are: s390 ([currently under review](https://github.com/openjdk/jdk/pull/14801)), windows-x86 (deprecated for removal), and linux-86 & arm32 (which can both be implemented using the fallback linker [1](https://github.com/openjdk/panama-foreign/pull/770) [2](https://mail.openjdk.org/pipermail/porters-dev/2023-March/000753.html)). ------------- Commit messages: - use immutable map for fallback linker canonical layouts - 8313265: Move the FFM API out of preview - 8313005: Ensure native access check can fold away - 8312981: Make the linker API required - 8312615: Ensure jdk_foreign tests pass on linux-x86 - 8312186: TestStringEncodingFails for UTF-32 - 8312059: Clarify the documention for variadic functions - 8311533: SegmentAllocator::allocateArray call can be ambiguous - 8310893: VarHandleTestExact fails - 8310820: Remove MemorySegment::segmentOffset - ... and 4 more: https://git.openjdk.org/jdk/compare/6fca2898...b0a1abaf Changes: https://git.openjdk.org/jdk/pull/15103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312522 Stats: 2444 lines in 224 files changed: 1084 ins; 721 del; 639 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From jvernee at openjdk.org Tue Aug 1 15:46:21 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 1 Aug 2023 15:46:21 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Open build question: the `jdk_foreign` tests will fail if a JDK does not have a full linker port, and is not built with `--enable-fallback-linker`. If the API is to become required, as proposed by this PR, then should the build also require the fallback linker by default on platforms that do not have a full linker port? FWIW, GHA linux-x86 currently fail tests, since it is not being built with `--enable-fallback-linker`. I think this could be easily [resolved](https://github.com/JornVernee/jdk/commit/6577c3725f79375c1df8c4af70925d8ac8dec9a2), but attempting this currently [fails](https://github.com/JornVernee/jdk/actions/runs/5726155097/job/15516044665) when trying to install GCC: Package gcc-10-multilib is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source This error occurs even on a plain master branch, so it doesn't seem to be caused by this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1660052156 PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1660353141 From duke at openjdk.org Tue Aug 1 15:46:21 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 1 Aug 2023 15:46:21 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 299: > 297: @Override > 298: public Map canonicalLayouts() { > 299: return CANONICAL_LAYOUTS; `CANONICAL_LAYOUTS` is?set to?a?`HashMap`, which?is?not?unmodifiable. Suggestion: return Collections.unmodifiableMap(CANONICAL_LAYOUTS); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1280480570 From jvernee at openjdk.org Tue Aug 1 15:46:21 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 1 Aug 2023 15:46:21 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 11:17:57 GMT, ExE Boss wrote: >> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: >> >> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. >> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. >> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. >> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. >> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. >> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) >> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. >> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. >> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO... > > src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 299: > >> 297: @Override >> 298: public Map canonicalLayouts() { >> 299: return CANONICAL_LAYOUTS; > > `CANONICAL_LAYOUTS` is?set to?a?`HashMap`, which?is?not?unmodifiable. > Suggestion: > > return Collections.unmodifiableMap(CANONICAL_LAYOUTS); Good catch. I think the right fix is to update FallbackLinker though. The other ports already use `Map.of`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1280665030 From coleenp at openjdk.org Tue Aug 1 16:31:49 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Aug 2023 16:31:49 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Tue, 1 Aug 2023 13:16:17 GMT, Kim Barrett wrote: >> src/hotspot/os/windows/os_windows.cpp line 3382: >> >>> 3380: if (Verbose && PrintMiscellaneous) { >>> 3381: reserveTimer.stop(); >>> 3382: tty->print_cr("reserve_memory of %zx bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes, >> >> SIZE_FORMAT. > > Regarding SIZE_FORMAT - https://bugs.openjdk.org/browse/JDK-8256379. Some people have been replacing > uses of SIZE_FORMAT when touching the relevant code for other reasons. Yes, I think it might be best if people started using %zd rather than adding new SIZE_FORMAT to the code. I haven't figured out the best way to change the rest. If using %zx, I suggest adding 0x%zx. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1280885515 From thomas.stuefe at gmail.com Tue Aug 1 17:01:36 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 1 Aug 2023 19:01:36 +0200 Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Tue 1. Aug 2023 at 18:32, Coleen Phillimore wrote: > On Tue, 1 Aug 2023 13:16:17 GMT, Kim Barrett wrote: > > >> src/hotspot/os/windows/os_windows.cpp line 3382: > >> > >>> 3380: if (Verbose && PrintMiscellaneous) { > >>> 3381: reserveTimer.stop(); > >>> 3382: tty->print_cr("reserve_memory of %zx bytes took " > JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes, > >> > >> SIZE_FORMAT. > > > > Regarding SIZE_FORMAT - https://bugs.openjdk.org/browse/JDK-8256379. > Some people have been replacing > > uses of SIZE_FORMAT when touching the relevant code for other reasons. > > Yes, I think it might be best if people started using %zd rather than > adding new SIZE_FORMAT to the code. I haven't figured out the best way to > change the rest. If using %zx, I suggest adding 0x%zx. Pity, I liked those macros. We also lose the ability to compile with older compilers, e.g. vs2013. But I really dislike wholesale replacements of X with X prime (newer, shinier) for aesthetic reasons. I much rather have those replacements we agree upon be done when code is touched for other reasons. That causes much less overhead for update maintainers. ------------- > > PR Review Comment: > https://git.openjdk.org/jdk/pull/15063#discussion_r1280885515 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccheung at openjdk.org Tue Aug 1 17:05:43 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 1 Aug 2023 17:05:43 GMT Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump() [v4] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 19:09:00 GMT, Matias Saavedra Silva wrote: >> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. >> >> >> // We have finished dumping the static archive. At this point, there may be pending VM >> // operations. We have changed some global states (such as vmClasses::_klasses) that >> // may cause these VM operations to fail. For safety, forget these operations and >> // exit the VM directly. >> void MetaspaceShared::exit_after_static_dump() { >> os::_exit(0); >> } >> >> >> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change: >> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead >> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals. >> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0. >> >> Verified with tier 1-9 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Ioi comments Looks good overall. I have one question. src/hotspot/share/oops/constantPool.cpp line 308: > 306: assert(java_lang_String::is_instance(obj), "must be"); > 307: if (!ArchiveHeapWriter::is_string_too_large_to_archive(obj)) { > 308: scratch_rr->obj_at_put(i, nullptr); Should the above be the following? `scratch_rr->obj_at_put(i, obj);` ------------- PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1557454731 PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1280919862 From egahlin at openjdk.org Tue Aug 1 17:25:49 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 1 Aug 2023 17:25:49 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v3] In-Reply-To: <1Oo8TxEUN6YJPGSaS6uyIYIO4KwS4zsTCVGbJyDUyhU=.5a5b24dd-6d2c-4613-a006-05a1b2b16816@github.com> References: <1Oo8TxEUN6YJPGSaS6uyIYIO4KwS4zsTCVGbJyDUyhU=.5a5b24dd-6d2c-4613-a006-05a1b2b16816@github.com> Message-ID: On Tue, 1 Aug 2023 13:02:42 GMT, Matthias Baesken wrote: > Hi Johannes, thanks for the review ! > > May I get a second review please? I can review, but I like replies to my comments first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15065#issuecomment-1660778090 From coleenp at openjdk.org Tue Aug 1 17:51:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Aug 2023 17:51:58 GMT Subject: RFR: 8313202: MutexLocker should disallow null Mutexes [v3] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 13:23:15 GMT, Aleksey Shipilev wrote: >> As seen in [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081), it is fairly easy to pass nullptr `Mutex` to `MutexLocker` by accident, which would just silently avoid the lock. >> >> There are a few places in Hotspot where we pass `nullptr` to simulate re-entrancy and/or conditionally take the lock. Those places can be more explicit, and the default `MutexLocker` can disallow nullptrs for extra safety. >> >> Open for some bikeshedding on the names of the new `MutexLockers`. Particularly `ReentrantMutexLocker` might lull readers into believing it does safepoint checks on re-entrant "lock", which it actually does not do. >> >> More thorough testing with different GC/JIT combinations is running now, we might find more issues there. Meanwhile, please comment on the approach. >> >> Additional testing: >> - [x] `grep -R "MutexLocker " src/hotspot | grep -i null`, no hits >> - [x] `grep -R "MutexLocker " src/hotspot | grep -i ?`, no hits >> - [x] Linux AArch64 fastdebug, `tier1 tier2 tier3` (re-run in progress) > > Aleksey Shipilev 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 six additional commits since the last revision: > > - Accept one more potentially nullptr mutex > - Merge branch 'master' into JDK-8313202-mutexlocker-nulls > - Replace ReentrantMutexLocker with ConditionalMutexLocker > - Workaround for JDK-8313210 > - Fixing CodeCache analytics > - Initial work This still looks like an improvement to me. src/hotspot/share/oops/instanceKlass.cpp line 3409: > 3407: bool InstanceKlass::remove_osr_nmethod(nmethod* n) { > 3408: // This is a short non-blocking critical region, so the no safepoint check is ok. > 3409: ConditionalMutexLocker ml(CompiledMethod_lock, !CompiledMethod_lock->owned_by_self(), Mutex::_no_safepoint_check_flag); This is sort of an unfortunate pattern. It's too bad we don't have a better name for this MutexLocker, but on the other hand maybe this should be fixed to take the lock at a higher place in this call stack and these conditional mutexLockers should be asserts. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15043#pullrequestreview-1557523791 PR Review Comment: https://git.openjdk.org/jdk/pull/15043#discussion_r1280962806 From shade at openjdk.org Tue Aug 1 17:58:44 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 1 Aug 2023 17:58:44 GMT Subject: RFR: 8313202: MutexLocker should disallow null Mutexes [v3] In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 17:48:04 GMT, Coleen Phillimore wrote: >> Aleksey Shipilev 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 six additional commits since the last revision: >> >> - Accept one more potentially nullptr mutex >> - Merge branch 'master' into JDK-8313202-mutexlocker-nulls >> - Replace ReentrantMutexLocker with ConditionalMutexLocker >> - Workaround for JDK-8313210 >> - Fixing CodeCache analytics >> - Initial work > > src/hotspot/share/oops/instanceKlass.cpp line 3409: > >> 3407: bool InstanceKlass::remove_osr_nmethod(nmethod* n) { >> 3408: // This is a short non-blocking critical region, so the no safepoint check is ok. >> 3409: ConditionalMutexLocker ml(CompiledMethod_lock, !CompiledMethod_lock->owned_by_self(), Mutex::_no_safepoint_check_flag); > > This is sort of an unfortunate pattern. It's too bad we don't have a better name for this MutexLocker, but on the other hand maybe this should be fixed to take the lock at a higher place in this call stack and these conditional mutexLockers should be asserts. Yes, it might even be _didactically correct_ to make sure that questionable uses are clunky to write :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15043#discussion_r1280970891 From coleenp at openjdk.org Tue Aug 1 18:32:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Aug 2023 18:32:50 GMT Subject: RFR: 8313202: MutexLocker should disallow null Mutexes [v3] In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 17:56:19 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 3409: >> >>> 3407: bool InstanceKlass::remove_osr_nmethod(nmethod* n) { >>> 3408: // This is a short non-blocking critical region, so the no safepoint check is ok. >>> 3409: ConditionalMutexLocker ml(CompiledMethod_lock, !CompiledMethod_lock->owned_by_self(), Mutex::_no_safepoint_check_flag); >> >> This is sort of an unfortunate pattern. It's too bad we don't have a better name for this MutexLocker, but on the other hand maybe this should be fixed to take the lock at a higher place in this call stack and these conditional mutexLockers should be asserts. > > Yes, it might even be _didactically correct_ to make sure that questionable uses are clunky to write :) I agree. one should be punished for not getting their locks straight. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15043#discussion_r1281001302 From tonyp at openjdk.org Tue Aug 1 19:29:38 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Tue, 1 Aug 2023 19:29:38 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v5] In-Reply-To: References: Message-ID: > What the title says. I started with the aarch64 version but changed it quite heavily. > > I haven't done anything with the macro assembler before, so detailed / picky feedback is very welcome! Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: Removed tmp3 as it was unused. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15090/files - new: https://git.openjdk.org/jdk/pull/15090/files/32232492..233726a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15090&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15090&range=03-04 Stats: 81 lines in 1 file changed: 0 ins; 1 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/15090.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15090/head:pull/15090 PR: https://git.openjdk.org/jdk/pull/15090 From coleenp at openjdk.org Tue Aug 1 19:57:43 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Aug 2023 19:57:43 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code Message-ID: This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. Tested with tier1-4. ------------- Commit messages: - unset Wconversion - Fix compactHashtable.cpp - Fix loaderConstraints.cpp, altHashing.cpp, classLoaderExt.cpp - Fix fieldLayoutBuilder.cpp by fixing Contended command line parameter. - Fix klassFactory.cpp - Fix systemDictionaryShared.cpp - Fix classLoader.cpp - Fix vmIntrinsics.cpp - Fix -Wconversion warnings in classfile code. Changes: https://git.openjdk.org/jdk/pull/15111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313564 Stats: 47 lines in 17 files changed: 2 ins; 0 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/15111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15111/head:pull/15111 PR: https://git.openjdk.org/jdk/pull/15111 From duke at openjdk.org Tue Aug 1 20:56:51 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 1 Aug 2023 20:56:51 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 08:33:24 GMT, David Holmes wrote: >> @dholmes-ora I confirmed there is no nest-host or nest-members attributes generated by this patch for a top level class which doesn't have any nest-members. Is that what you wanted to verify? > > @ashu-mehra That was one case. I also want to know that you have tested deeply nested classes; and hidden classes (if applicable). Thanks. @dholmes-ora I verified the case for hidden dynamically injected classes. The dumped class data for a hidden dynamically injected class does not have any Nest-Host attribute. When generating these classes dynamically the VM does not expose nest-host information in the class data, but sets the nest-host directly in the InstanceKlass. Also verified the case for deeply nested classes by creating chain of nested classes as: class DeepNest { class NestLvl1 { class NestLvl2 { class NestLvl3 { } } } } Only `DeepNest` has the `NestMembers` attribute which lists all the NestLvl[1-3] classes. Rest all have `DeepNest` as the `NestHost` attribute. Does this cover all the cases you flagged? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15005#issuecomment-1661077708 From matsaave at openjdk.org Tue Aug 1 21:08:05 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 1 Aug 2023 21:08:05 GMT Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump() [v5] In-Reply-To: References: Message-ID: > Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. > > > // We have finished dumping the static archive. At this point, there may be pending VM > // operations. We have changed some global states (such as vmClasses::_klasses) that > // may cause these VM operations to fail. For safety, forget these operations and > // exit the VM directly. > void MetaspaceShared::exit_after_static_dump() { > os::_exit(0); > } > > > As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change: > 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead > 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals. > 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0. > > Verified with tier 1-9 tests. Matias Saavedra Silva 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 ten additional commits since the last revision: - Merge branch 'master' into remove_exit_after_dump_8306582 - Calvin comment - Ioi comments - Refactored KlassToOopHandleTable, Ioi and Alan comments - Merge fix - Restores java loaders - Ioi and David comments - Windows fix - 8306582: Remove MetaspaceShared::exit_after_static_dump() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14879/files - new: https://git.openjdk.org/jdk/pull/14879/files/64d8c638..f4f9091a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=03-04 Stats: 9132 lines in 289 files changed: 4715 ins; 2001 del; 2416 mod Patch: https://git.openjdk.org/jdk/pull/14879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14879/head:pull/14879 PR: https://git.openjdk.org/jdk/pull/14879 From matsaave at openjdk.org Tue Aug 1 21:08:05 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 1 Aug 2023 21:08:05 GMT Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump() [v4] In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 17:02:46 GMT, Calvin Cheung wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Ioi comments > > src/hotspot/share/oops/constantPool.cpp line 308: > >> 306: assert(java_lang_String::is_instance(obj), "must be"); >> 307: if (!ArchiveHeapWriter::is_string_too_large_to_archive(obj)) { >> 308: scratch_rr->obj_at_put(i, nullptr); > > Should the above be the following? > `scratch_rr->obj_at_put(i, obj);` Yes it should! Thank you for catching this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1281150300 From ccheung at openjdk.org Tue Aug 1 21:54:52 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 1 Aug 2023 21:54:52 GMT Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump() [v5] In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 21:08:05 GMT, Matias Saavedra Silva wrote: >> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. >> >> >> // We have finished dumping the static archive. At this point, there may be pending VM >> // operations. We have changed some global states (such as vmClasses::_klasses) that >> // may cause these VM operations to fail. For safety, forget these operations and >> // exit the VM directly. >> void MetaspaceShared::exit_after_static_dump() { >> os::_exit(0); >> } >> >> >> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change: >> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead >> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals. >> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0. >> >> Verified with tier 1-9 tests. > > Matias Saavedra Silva 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 ten additional commits since the last revision: > > - Merge branch 'master' into remove_exit_after_dump_8306582 > - Calvin comment > - Ioi comments > - Refactored KlassToOopHandleTable, Ioi and Alan comments > - Merge fix > - Restores java loaders > - Ioi and David comments > - Windows fix > - 8306582: Remove MetaspaceShared::exit_after_static_dump() Marked as reviewed by ccheung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1557891129 From dholmes at openjdk.org Wed Aug 2 04:04:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Aug 2023 04:04:58 GMT Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump() [v4] In-Reply-To: References: Message-ID: <92hduxZ6vbxgkiYkbGWtKw9E_EezThT-5VeVo9vFACg=.ecdddcbc-5a0d-4fec-bdcb-44252a35957f@github.com> On Tue, 1 Aug 2023 21:02:36 GMT, Matias Saavedra Silva wrote: >> src/hotspot/share/oops/constantPool.cpp line 308: >> >>> 306: assert(java_lang_String::is_instance(obj), "must be"); >>> 307: if (!ArchiveHeapWriter::is_string_too_large_to_archive(obj)) { >>> 308: scratch_rr->obj_at_put(i, nullptr); >> >> Should the above be the following? >> `scratch_rr->obj_at_put(i, obj);` > > Yes it should! Thank you for catching this. This suggests we don't have test coverage for this case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1281362007 From dholmes at openjdk.org Wed Aug 2 05:11:02 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Aug 2023 05:11:02 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: References: Message-ID: <5RAZrov0Ss7Is1OMYjzZ78srasN_9rGQcoq-KaYu2aE=.ae10565f-fb5c-4def-b145-22363ec0fc7d@github.com> On Tue, 1 Aug 2023 20:53:45 GMT, Ashutosh Mehra wrote: >> @ashu-mehra That was one case. I also want to know that you have tested deeply nested classes; and hidden classes (if applicable). Thanks. > > @dholmes-ora I verified the case for hidden dynamically injected classes. The dumped class data for a hidden dynamically injected class does not have any Nest-Host attribute. When generating these classes dynamically the VM does not expose nest-host information in the class data, but sets the nest-host directly in the InstanceKlass. > > Also verified the case for deeply nested classes by creating chain of nested classes as: > > class DeepNest { > class NestLvl1 { > class NestLvl2 { > class NestLvl3 { > } > } > } > } > > > Only `DeepNest` has the `NestMembers` attribute which lists all the NestLvl[1-3] classes. Rest all have `DeepNest` as the `NestHost` attribute. > > Does this cover all the cases you flagged? @ashu-mehra thanks for doing the additional testing. Pity there is no regression/functional test for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15005#issuecomment-1661502815 From mbaesken at openjdk.org Wed Aug 2 07:14:42 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 07:14:42 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v3] In-Reply-To: References: <1Oo8TxEUN6YJPGSaS6uyIYIO4KwS4zsTCVGbJyDUyhU=.5a5b24dd-6d2c-4613-a006-05a1b2b16816@github.com> Message-ID: <0iIH2r_bsdglL31vlqbN-sBYfQ2gGFMRdRQg1Fu1Dds=.d89876ad-64f5-4dfc-9dfb-a4ff681d5ea2@github.com> On Tue, 1 Aug 2023 17:23:17 GMT, Erik Gahlin wrote: > > Hi Johannes, thanks for the review ! > > May I get a second review please? > > I can review, but I like replies to my comments first. Hi Erik , maybe I miss something? What comment(s) are you referring to ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15065#issuecomment-1661631349 From egahlin at openjdk.org Wed Aug 2 08:21:54 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 2 Aug 2023 08:21:54 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v3] In-Reply-To: <0iIH2r_bsdglL31vlqbN-sBYfQ2gGFMRdRQg1Fu1Dds=.d89876ad-64f5-4dfc-9dfb-a4ff681d5ea2@github.com> References: <1Oo8TxEUN6YJPGSaS6uyIYIO4KwS4zsTCVGbJyDUyhU=.5a5b24dd-6d2c-4613-a006-05a1b2b16816@github.com> <0iIH2r_bsdglL31vlqbN-sBYfQ2gGFMRdRQg1Fu1Dds=.d89876ad-64f5-4dfc-9dfb-a4ff681d5ea2@github.com> Message-ID: On Wed, 2 Aug 2023 07:11:33 GMT, Matthias Baesken wrote: > > > Hi Johannes, thanks for the review ! > > > May I get a second review please? > > > > > > I can review, but I like replies to my comments first. > > Hi Erik , maybe I miss something? What comment(s) are you referring to ? Hi Matthias. Sorry, I forgot to press submit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15065#issuecomment-1661729383 From egahlin at openjdk.org Wed Aug 2 08:21:59 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 2 Aug 2023 08:21:59 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v2] In-Reply-To: References: Message-ID: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> On Fri, 28 Jul 2023 09:38:13 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > add macro guards because the build errors in zero build src/hotspot/os/bsd/os_bsd.cpp line 1027: > 1025: log_info(os)("attempting shared library load of %s", filename); > 1026: > 1027: #if INCLUDE_JFR We typically skip INCLUDE_JFR for events and rely on empty stubs in the code generation. This to make the code more easy to read. src/hotspot/os/linux/os_linux.cpp line 1825: > 1823: #if INCLUDE_JFR > 1824: event.set_success(true); > 1825: event.set_errorDescription(""); Use null if there is no error message src/hotspot/share/jfr/metadata/metadata.xml line 942: > 940: > 941: > 942: 49: > 50: public static void main(String[] args) throws Throwable { > 51: Recording recording = new Recording(); Use try-with-resources. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1277527396 PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1277523771 PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1277522273 PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1277528974 From luhenry at openjdk.org Wed Aug 2 08:36:42 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 2 Aug 2023 08:36:42 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v5] In-Reply-To: References: Message-ID: <833aKWvjjRInyx4WXVEQor1Aq_LeEBQG5YeBp5j2a44=.6de9b872-772d-4444-a865-1e8191dc0cbd@github.com> On Tue, 1 Aug 2023 19:29:38 GMT, Antonios Printezis wrote: >> What the title says. I started with the aarch64 version but changed it quite heavily. >> >> I haven't done anything with the macro assembler before, so detailed / picky feedback is very welcome! > > Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: > > Removed tmp3 as it was unused. Marked as reviewed by luhenry (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15090#pullrequestreview-1558490496 From luhenry at openjdk.org Wed Aug 2 09:56:40 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 2 Aug 2023 09:56:40 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 08:22:52 GMT, Ilya Gavrilin wrote: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Marked as reviewed by luhenry (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14991#pullrequestreview-1558642043 From luhenry at openjdk.org Wed Aug 2 09:56:42 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 2 Aug 2023 09:56:42 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 09:56:03 GMT, Ilya Gavrilin wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4283: >> >>> 4281: // generating constant (tmp2) >>> 4282: // tmp2 = 100...0000 >>> 4283: addi(mask, zr, 1); >> >> There are other ways to [implement these functions with less instructions](https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1AB9U8lJL6yAngGVG6AMKpaAVxYM9DgDJ4GmADl3ACNMYhAAVgBmUgAHVAVCWwZnNw89eMSbAV9/IJZQ8OiLTCtshiECJmICVPdPLhKy5MrqglzAkLDImIUqmrr0xr62jvzCnoBKC1RXYmR2DgBSACYov2Q3LABqJajHPvxBADoEPewljQBBVfWGTdcdvccWJgIEU/PLm%2BuCAE9YpgsFRtolgP50NtkAhqttgqgXHsAELfb7oWbBejfMyYOjbCDo1yYzDbVSTVEAdhR12220JxO2r2AuyiABFtlQmMEFPiycjUTTtngQRAmSzHPiuHJvN5xc9tqZWUjvMYALJXAIAFWMrIAkgBxUyTcmC2lLKnfWlWoWCABskmMBCF/NNVvp9G2/gA7sZVC6fldrbSmAoWNsAG4uN50EkQVYrKjIcMEY60Y6Q1YRDSkXYrCKNbbEVyxePbEC5lZ7VnEUsQPCTMsVqi1snkqLUwNBkNhyMGGweuMrBNJlPoVO5rM5zMFosloeN%2BNV5vziDe30N8vxmsr%2BttjuWoMAegAVFDcbQIABaDQNqtV7bXnOGSF%2BbbARhhMTbL2YMAcWi0NsYhekwfw8jC4Yku8JIKKwmACgAnKCeDgkBPKzMQNqxK4Ka0seh4HtaqgsuyaCxGBKEMPia6qDmfLtoRuwUqyAqdsQmAEHMVF%2Bgx1zmixfHXO68HXKYVC0AimEEhiHp8nxFqCsJjJMMy96ctyvJ7qxtLCviYryhAUoynK%2BwKjqypqhq2p6oaxjGox5odkGN oEPajrOrxnbWkpNH%2BoxwahhGUb9rG8aJsmqbphO2YTjO6AMKWm5DlW24rPi9YLkOy5pRArb%2Bs53ZBX2Mb4mFI7puOmYxdOObEPFiUVkutY0RuFapel9mef52wnhyEkkFeN4kfej5AQwL5Ue%2B/jEF%2BP5/gBQG0CBYHbBBUEIDBcGIchqEhtsGFYThxx4QRrq0sR95kRRqGrpgPq0aSWmuvx2mFhxXGkn5zGsWiMkiVcpjELM434kpck3ApnZKfpbIclyPK5U9AY6SKMMSoZ0qys88qKhZ6pajqBpGiaXlMU5QZ%2BK5DpOng%2BVBj5d2%2Bn5Z1oT2wUlYOw4RWmGZ5tVeYziwLANYubLtXWrVhS2nXk9ahW9tGA5lRFY6AVVU4C7VQsi8lbLZdRjNkplKzi7uzOk7SvVA6442DbebIjTFz42m%2BH4zYBc3/oBwGgeBTCQds0GgltglIWCVF7QdfjYbh2z4d1F2w1d4cG/ddFI9aL2CWx73ENxX0CVcHDTLQnARLwngcFopCoJwEoKBhCy5lEPCkAQmjF9MADWkTZqXHCSLwLASBo2aV9XtccLwCggNm7dV8XpBwLASBoCwsQxmQFAQGvG/0OExDhval7IJshjAKQWDhngCwAGp4HdADygKV63NC0AQYQzxAwQd6QwR%2BGqH8TgrcAHMGIH8R%2BwRtCYGsCA3ga82CCEfgwWgwCF6X0wMEVwwBHBiFoDPbgvAsCvCMOIDB%2BB2LWDwJBQh1dMCqFgThRYrdKalD/rQPAwQZoQOcFgP%2BBBiB4GHkQ6Y4kVIKHvk/F%2B8CZCCBEGIdgUg5HyCUGoP%2BuhGgGCMCAUwxhzCcO5PAaYqBYjlEIZeR%2BUReCoEgsQIRWAZ6QGmJYWB5R7DjUGJ4KI2YfB%2BE6AUboXAVhxASEkAQXiMhhPKGMLoRQmhuJaP0WoLh6ggB8Qk6hAhWg1FiYE8IwSLDJMicMZJe SJgRBcY3JRJcy4Vz/pPbYAAlXUQhHCXlvoWI%2BkhgDIChNo5kEBBE2y7g2CAuBCAkGblwSYvB55aGNKQDaTAsDhAgN3Xu%2BhOCD1IOPGxnBp6zzbh3RZ/cVj1IwZPOZJzph2MSHYSQQA). Also, given you're not checking for NaN (and neither is it done for other architectures), I assume that this is done before this is called? > > Hi, thanks for your review. > > - About NaN, INF and other special values: > > According to RISC-V ISA paragraph 8.7 for fcvt.l instruction (Table 8.4) we have some special return values: > 1) if we exceed minimum input value, or got -INF it returns (-2^63) > 2) if we exceed maximum input value, or got +INF or NaN it returns (2^63-1) > > (Also, if we exceed maximum/minimum input values on input we have already integer value, > because according to IEEE754 double-precision f.p. format all doubles more +/- 2^52 are already integer values) > > So we need to check if we got -2^63 or 2^63-1 after double->long int conversion, > comment lines from [src/hotspot/cpu/riscv/macroAssembler_riscv.cpp:4288](https://github.com/openjdk/jdk/pull/14991/files#diff-7a5c3ed05b6f3f06ed1c59f5fc2a14ec566a6a5bd1d09606115767daa99115bdR4288-R4291) describes how do we change result (converted_dbl -> converted_dbl_masked) and constant (mask) to check this values. I have tried to check for NaN and +-inf with just one conditional branch. > If we got -2^63 or 2^63-1 we return input value, therefore NaN -> NaN; +/- INF -> +/- INF; double that is already integer stays same as required by the ceil/floor/rint function descriptions. > > - About case when we can use less instructions: > > Of course, we can use a bit less instructions, but the main goal during intrinsic writing was minimizing count of expensive instructions (so instead of flt.d was used integer instructions on converted_dbl etc.) > We already have some cases when less expensive instructions were chosen instead of reducing their number. For example: https://bugs.openjdk.org/browse/JDK-8297359 Generally speaking, I'm a bit concerned we are over-optimizing for HiFive Unmatched (or equivalent "small" boards). I understand this is what we have today, and that there is no great way to project performance otherwise (maybe [llvm-mca](https://www.llvm.org/docs/CommandGuide/llvm-mca.html) but I haven't played with it), I just wish there were already broadly available high-performance RISC-V board (soon...) Happy to go with that approach for now, and we can revisit the specific instruction sequence when we have more powerful boards to benchmark with. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1281677022 From vkempik at openjdk.org Wed Aug 2 10:26:51 2023 From: vkempik at openjdk.org (Vladimir Kempik) Date: Wed, 2 Aug 2023 10:26:51 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 09:52:55 GMT, Ludovic Henry wrote: >> Hi, thanks for your review. >> >> - About NaN, INF and other special values: >> >> According to RISC-V ISA paragraph 8.7 for fcvt.l instruction (Table 8.4) we have some special return values: >> 1) if we exceed minimum input value, or got -INF it returns (-2^63) >> 2) if we exceed maximum input value, or got +INF or NaN it returns (2^63-1) >> >> (Also, if we exceed maximum/minimum input values on input we have already integer value, >> because according to IEEE754 double-precision f.p. format all doubles more +/- 2^52 are already integer values) >> >> So we need to check if we got -2^63 or 2^63-1 after double->long int conversion, >> comment lines from [src/hotspot/cpu/riscv/macroAssembler_riscv.cpp:4288](https://github.com/openjdk/jdk/pull/14991/files#diff-7a5c3ed05b6f3f06ed1c59f5fc2a14ec566a6a5bd1d09606115767daa99115bdR4288-R4291) describes how do we change result (converted_dbl -> converted_dbl_masked) and constant (mask) to check this values. I have tried to check for NaN and +-inf with just one conditional branch. >> If we got -2^63 or 2^63-1 we return input value, therefore NaN -> NaN; +/- INF -> +/- INF; double that is already integer stays same as required by the ceil/floor/rint function descriptions. >> >> - About case when we can use less instructions: >> >> Of course, we can use a bit less instructions, but the main goal during intrinsic writing was minimizing count of expensive instructions (so instead of flt.d was used integer instructions on converted_dbl etc.) >> We already have some cases when less expensive instructions were chosen instead of reducing their number. For example: https://bugs.openjdk.org/browse/JDK-8297359 > > Generally speaking, I'm a bit concerned we are over-optimizing for HiFive Unmatched (or equivalent "small" boards). I understand this is what we have today, and that there is no great way to project performance otherwise (maybe [llvm-mca](https://www.llvm.org/docs/CommandGuide/llvm-mca.html) but I haven't played with it), I just wish there were already broadly available high-performance RISC-V board (soon...) > > Happy to go with that approach for now, and we can revisit the specific instruction sequence when we have more powerful boards to benchmark with. It also should be available on public market, so anyone can reproduce results claimed in PR so far it's only hifive u74 and thead c910, hence we mostly mention results from these two ( but testing a bit more) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1281712339 From mbaesken at openjdk.org Wed Aug 2 10:36:55 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 10:36:55 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v2] In-Reply-To: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> References: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> Message-ID: <6hISPOUbmmgtxA_LZpLndhzDhGZdO5Yb9YCLLvNtLdk=.faf375dd-130c-4ce2-8812-1e8364483626@github.com> On Fri, 28 Jul 2023 13:09:56 GMT, Erik Gahlin wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> add macro guards because the build errors in zero build > > src/hotspot/os/bsd/os_bsd.cpp line 1027: > >> 1025: log_info(os)("attempting shared library load of %s", filename); >> 1026: >> 1027: #if INCLUDE_JFR > > We typically skip INCLUDE_JFR for events and rely on empty stubs in the code generation. This to make the code more easy to read. Hi Erik , I removed the JFR with configure and attempted this (however on Linux) but for some reason I got build errors. So I better added the macros. (not sure why this happened, with some other JFR event living without INCLUDE_JFR seemed to work as expected) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1281721182 From mbaesken at openjdk.org Wed Aug 2 10:42:53 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 10:42:53 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v2] In-Reply-To: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> References: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> Message-ID: On Fri, 28 Jul 2023 13:04:21 GMT, Erik Gahlin wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> add macro guards because the build errors in zero build > > src/hotspot/share/jfr/metadata/metadata.xml line 942: > >> 940: >> 941: >> 942: > I think "Native Library Load" is sufficient as an event label and "Success" for the success field. > > I think "error" is sufficient for the error field. We could use "errorMessage", if you believe there are other error related information we may want to add in the future. > > The "name" label could changed to "Name", similar to the NativeLibrary event, Hi Erik, I will adjust. I will use errorMessage because on some platforms we have already coding to describe shared lib load error situations in more detail (see for example os_linux.cpp). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1281727323 From yzheng at openjdk.org Wed Aug 2 11:05:12 2023 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 2 Aug 2023 11:05:12 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11] In-Reply-To: References: Message-ID: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com> On Wed, 21 Oct 2020 23:42:33 GMT, Fei Yang wrote: >> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com >> >> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. >> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 >> >> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. >> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. >> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. >> >> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. >> Patch passed jtreg tier1-3 tests with QEMU system emulator. >> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression. >> >> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java >> We measured the performance benefit with an aarch64 cycle-accurate simulator. >> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. >> >> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected. > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473: > 3471: __ bcax(v24, __ T16B, v24, v8, v31); > 3472: > 3473: __ ld1r(v31, __ T2D, __ post(rscratch1, 8)); is it intentional to load 16 bytes and post-increment by 8? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281749663 From mbaesken at openjdk.org Wed Aug 2 11:31:52 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 11:31:52 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v2] In-Reply-To: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> References: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> Message-ID: On Fri, 28 Jul 2023 13:11:35 GMT, Erik Gahlin wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> add macro guards because the build errors in zero build > > test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java line 51: > >> 49: >> 50: public static void main(String[] args) throws Throwable { >> 51: Recording recording = new Recording(); > > Use try-with-resources. Hi Erik, this was taken from test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java , I do not see in main there a try with resources. What do you want to put in the try block exactly ? The new Recording() ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1281774188 From egahlin at openjdk.org Wed Aug 2 12:26:53 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 2 Aug 2023 12:26:53 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v2] In-Reply-To: <6hISPOUbmmgtxA_LZpLndhzDhGZdO5Yb9YCLLvNtLdk=.faf375dd-130c-4ce2-8812-1e8364483626@github.com> References: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> <6hISPOUbmmgtxA_LZpLndhzDhGZdO5Yb9YCLLvNtLdk=.faf375dd-130c-4ce2-8812-1e8364483626@github.com> Message-ID: <1nTNPYNbdYVP7rGcCoJPm9v6s4attBLU6dsicrzQ4P8=.419237ed-18cd-403f-82df-8cc6c3ece814@github.com> On Wed, 2 Aug 2023 10:33:26 GMT, Matthias Baesken wrote: >> src/hotspot/os/bsd/os_bsd.cpp line 1027: >> >>> 1025: log_info(os)("attempting shared library load of %s", filename); >>> 1026: >>> 1027: #if INCLUDE_JFR >> >> We typically skip INCLUDE_JFR for events and rely on empty stubs in the code generation. This to make the code more easy to read. > > Hi Erik , I removed the JFR with configure and attempted this (however on Linux) but for some reason I got build errors. So I better added the macros. (not sure why this happened, with some other JFR event living without INCLUDE_JFR seemed to work as expected) OK ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1281829833 From egahlin at openjdk.org Wed Aug 2 12:31:52 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 2 Aug 2023 12:31:52 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v2] In-Reply-To: References: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> Message-ID: On Wed, 2 Aug 2023 11:28:45 GMT, Matthias Baesken wrote: >> test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java line 51: >> >>> 49: >>> 50: public static void main(String[] args) throws Throwable { >>> 51: Recording recording = new Recording(); >> >> Use try-with-resources. > > Hi Erik, this was taken from test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java , I do not see in main there a try with resources. What do you want to put in the try block exactly ? The new Recording() ? Yes. try (Recording r = new Recording()) { ... } It's not used everywhere, but it seems proper to release chunk resources when the test is finished. (I should probably go over all tests and change to avoid the pattern being copied.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1281834616 From duke at openjdk.org Wed Aug 2 12:37:13 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Wed, 2 Aug 2023 12:37:13 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11] In-Reply-To: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com> References: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com> Message-ID: On Wed, 2 Aug 2023 11:02:07 GMT, Yudi Zheng wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473: > >> 3471: __ bcax(v24, __ T16B, v24, v8, v31); >> 3472: >> 3473: __ ld1r(v31, __ T2D, __ post(rscratch1, 8)); > > is it intentional to load 16 bytes and post-increment by 8? Actually, with the ld1r instruction the post increment should be the same as the size of the memory accessed. So T2D requires 8 as it reads 8 bytes(and duplicates it into both halves of the SIMD register). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281840355 From mbaesken at openjdk.org Wed Aug 2 12:39:37 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 12:39:37 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v4] In-Reply-To: References: Message-ID: > Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Small event adjustments and use nullptr in case we have no message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15065/files - new: https://git.openjdk.org/jdk/pull/15065/files/da6b9861..628336ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15065&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15065&range=02-03 Stats: 18 lines in 5 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/15065.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15065/head:pull/15065 PR: https://git.openjdk.org/jdk/pull/15065 From mbaesken at openjdk.org Wed Aug 2 13:00:20 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 13:00:20 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: > Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: use try with resources in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15065/files - new: https://git.openjdk.org/jdk/pull/15065/files/628336ce..045f2832 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15065&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15065&range=03-04 Stats: 16 lines in 1 file changed: 2 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/15065.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15065/head:pull/15065 PR: https://git.openjdk.org/jdk/pull/15065 From mbaesken at openjdk.org Wed Aug 2 13:08:52 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 13:08:52 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v2] In-Reply-To: References: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> Message-ID: On Wed, 2 Aug 2023 12:28:33 GMT, Erik Gahlin wrote: >> Hi Erik, this was taken from test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java , I do not see in main there a try with resources. What do you want to put in the try block exactly ? The new Recording() ? > > Yes. > try (Recording r = new Recording()) { > ... > } > It's not used everywhere, but it seems proper to release chunk resources when the test is finished. > > (I should probably go over all tests and change to avoid the pattern being copied.) HI Erik, I adjusted the test as recommended . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1281878884 From tonyp at openjdk.org Wed Aug 2 13:19:58 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Wed, 2 Aug 2023 13:19:58 GMT Subject: RFR: 8313322: RISC-V: implement MD5 intrinsic [v2] In-Reply-To: References: <6zXzQDEH7fxazbf7vwFL4AebesePv4uPofa62bcpQDU=.91c008b8-d743-4a08-a5e3-c89259756023@github.com> Message-ID: <6s2kCKs3adXbeECg3R1ous5l_eb6oen2b-pEfJgF2oY=.e171ce83-5280-430e-bba7-4b8663aab966@github.com> On Tue, 1 Aug 2023 08:00:12 GMT, Robbin Ehn wrote: >> Thanks, looks good to me! >> >> You also have some tests here: >> test/hotspot/jtreg/compiler/intrinsics/sha/sanity/TestMD5xxx >> >> I'll take it for a spin. > >> Thanks, looks good to me! >> >> You also have some tests here: test/hotspot/jtreg/compiler/intrinsics/sha/sanity/TestMD5xxx >> >> I'll take it for a spin. > > Thumbs up! Thanks to @robehn for doing a performance evaluation with the jmh md5 microbenchmarks on his VisionFive2 board! -UseMD5Intrinsic: MessageDigests.digest md5 64 DEFAULT avgt 6 2568.244 ? 842.423 ns/op MessageDigests.digest md5 16384 DEFAULT avgt 6 217455.589 ? 30984.729 ns/op MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 3181.132 ? 677.752 ns/op MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 230630.983 ? 34108.072 ns/op +UseMD5Intrinsic: MessageDigests.digest md5 64 DEFAULT avgt 6 1930.057 ? 106.178 ns/op MessageDigests.digest md5 16384 DEFAULT avgt 6 162308.240 ? 2042.715 ns/op MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2721.418 ? 567.045 ns/op MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 164660.082 ? 1976.401 ns/op +UseMD5Intrinsic +UseZbb: MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/15090#issuecomment-1662195266 From tonyp at openjdk.org Wed Aug 2 13:20:00 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Wed, 2 Aug 2023 13:20:00 GMT Subject: Integrated: 8313322: RISC-V: implement MD5 intrinsic In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 13:50:10 GMT, Antonios Printezis wrote: > What the title says. I started with the aarch64 version but changed it quite heavily. > > I haven't done anything with the macro assembler before, so detailed / picky feedback is very welcome! This pull request has now been integrated. Changeset: b093880a Author: Antonios Printezis URL: https://git.openjdk.org/jdk/commit/b093880acd89d8d0bccd4b8b260b721f4dcfc161 Stats: 395 lines in 4 files changed: 391 ins; 1 del; 3 mod 8313322: RISC-V: implement MD5 intrinsic Reviewed-by: luhenry, rehn ------------- PR: https://git.openjdk.org/jdk/pull/15090 From coleenp at openjdk.org Wed Aug 2 13:40:12 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Aug 2023 13:40:12 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: > This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15111/files - new: https://git.openjdk.org/jdk/pull/15111/files/3fa12be0..0e97905c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15111/head:pull/15111 PR: https://git.openjdk.org/jdk/pull/15111 From fjiang at openjdk.org Wed Aug 2 13:41:50 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 2 Aug 2023 13:41:50 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 08:22:52 GMT, Ilya Gavrilin wrote: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Thanks for the work! With one comment: src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4286: > 4284: slli(mask, mask, 63); > 4285: // conversion from double to long > 4286: fcvt_l_d(converted_dbl, src, rm_direct); How about using `fclass` [1] to check the special cases of input, then we can just do `fcvt.l.d` and `fcvt.d.l` for normal inputs? We can check the result of `fclass`. If the input contains NaN/infinity/+0/-0, we could return the value without conversion. 1. https://github.com/riscv/riscv-isa-manual/blob/3a6edf7ebf6af9e6ad92ace865c0069090870c20/src/f-st-ext.adoc?plain=1#L487-L500 ------------- PR Review: https://git.openjdk.org/jdk/pull/14991#pullrequestreview-1559023432 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1281913449 From egahlin at openjdk.org Wed Aug 2 14:07:52 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 2 Aug 2023 14:07:52 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: <8QcW7RdO_GfpLJRI00Ho71v-CoPqF8P6SnkH70XI-bs=.e19be892-0dee-43d2-ae2c-b37224abbed9@github.com> On Wed, 2 Aug 2023 13:00:20 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > use try with resources in test Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15065#pullrequestreview-1559094036 From yzheng at openjdk.org Wed Aug 2 14:10:13 2023 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 2 Aug 2023 14:10:13 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11] In-Reply-To: References: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com> Message-ID: On Wed, 2 Aug 2023 12:33:43 GMT, Ferenc Rakoczi wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473: >> >>> 3471: __ bcax(v24, __ T16B, v24, v8, v31); >>> 3472: >>> 3473: __ ld1r(v31, __ T2D, __ post(rscratch1, 8)); >> >> is it intentional to load 16 bytes and post-increment by 8? > > Actually, with the ld1r instruction the post increment should be the same as the size of the memory accessed. So T2D requires 8 as it reads 8 bytes(and duplicates it into both halves of the SIMD register). Thanks for the clarification! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281961206 From mbaesken at openjdk.org Wed Aug 2 14:32:46 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 2 Aug 2023 14:32:46 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 13:00:20 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > use try with resources in test Hi Erik, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15065#issuecomment-1662320244 From iklam at openjdk.org Wed Aug 2 16:03:50 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Aug 2023 16:03:50 GMT Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump() [v4] In-Reply-To: <92hduxZ6vbxgkiYkbGWtKw9E_EezThT-5VeVo9vFACg=.ecdddcbc-5a0d-4fec-bdcb-44252a35957f@github.com> References: <92hduxZ6vbxgkiYkbGWtKw9E_EezThT-5VeVo9vFACg=.ecdddcbc-5a0d-4fec-bdcb-44252a35957f@github.com> Message-ID: On Wed, 2 Aug 2023 04:01:46 GMT, David Holmes wrote: >> Yes it should! Thank you for catching this. > > This suggests we don't have test coverage for this case. If we want to add a test case, I would suggest adding a WhiteBox method like: public native Object[] getResolvedReferences(Class c); This would return the `resolved_references` array for this class. The test class would look like this: class TestApp { static String foo = "fooString"; static String bar = "barString"; public void main(String args[]) { Object[] resolvedReferences = wb.getResolvedReferences(TestApp.class); ... resolvedReferences must be non null for classes in the static archive ... the test needs to have @requires vm.cds.write.archived.java.heap bool foundFoo = false; bool foundBar = false; for (Object o : resolvedReferences) { foundFoo |= (o == foo); foundBar |= (o == bar); } ... foo and bar must have been found ... CDS resolves all of the string literals used by the TestApp and stores ... them inside the resolvedReferences array. } The new test can live under test/hotspot/jtreg/runtime/cds/appcds/sharedStrings ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1282115165 From matsaave at openjdk.org Wed Aug 2 17:14:02 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 2 Aug 2023 17:14:02 GMT Subject: Integrated: 8306582: Remove MetaspaceShared::exit_after_static_dump() In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 21:25:17 GMT, Matias Saavedra Silva wrote: > Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. > > > // We have finished dumping the static archive. At this point, there may be pending VM > // operations. We have changed some global states (such as vmClasses::_klasses) that > // may cause these VM operations to fail. For safety, forget these operations and > // exit the VM directly. > void MetaspaceShared::exit_after_static_dump() { > os::_exit(0); > } > > > As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change: > 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead > 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals. > 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0. > > Verified with tier 1-9 tests. This pull request has now been integrated. Changeset: cff25dd5 Author: Matias Saavedra Silva URL: https://git.openjdk.org/jdk/commit/cff25dd574203d0840d11ce083a5b825fb26d61d Stats: 121 lines in 9 files changed: 77 ins; 27 del; 17 mod 8306582: Remove MetaspaceShared::exit_after_static_dump() Reviewed-by: iklam, alanb, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/14879 From matsaave at openjdk.org Wed Aug 2 17:14:01 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 2 Aug 2023 17:14:01 GMT Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump() [v3] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 18:07:12 GMT, Ioi Lam wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactored KlassToOopHandleTable, Ioi and Alan comments > > Looks good. Just a couple of nits. Thank you for the reviews @iklam, @calvinccheung, @dholmes-ora, and @AlanBateman! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14879#issuecomment-1662624259 From matsaave at openjdk.org Wed Aug 2 19:02:57 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 2 Aug 2023 19:02:57 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. Thanks for this! I have a few questions and potential improvements overall this looks good! src/hotspot/share/classfile/altHashing.cpp line 111: > 109: } > 110: > 111: static void halfsiphash_init32(uint32_t v[4], uint64_t seed) { I believe all the bitwise operators here will promote the result to int. Will this cause further conversion issues with uint32_t? src/hotspot/share/classfile/classFileParser.cpp line 5244: > 5242: // that changes, then InstanceKlass::idnum_can_increment() > 5243: // has to be changed accordingly. > 5244: ik->set_initial_method_idnum(checked_cast(ik->methods()->length())); Here you are setting a field inside an instance klass to a field acquired from within the same instance klass. Maybe it would be better for this to be a method internal to InstanceKlass? src/hotspot/share/classfile/symbolTable.cpp line 240: > 238: > 239: double SymbolTable::get_load_factor() { > 240: return (double)_items_count/(double)_current_size; Is this redundant? Both operands are `size_t` so you can cast the result as opposed to both operands. src/hotspot/share/classfile/symbolTable.cpp line 926: > 924: if (_symbols_counted > 0) { > 925: tty->print_cr(" Percent removed %3.2f", > 926: ((float)_symbols_removed / (float)_symbols_counted) * 100); I think you can also just cast once here. src/hotspot/share/classfile/symbolTable.cpp line 933: > 931: tty->print_cr(" Total symbol length " SIZE_FORMAT_W(7), hi.total_length); > 932: tty->print_cr(" Maximum symbol length " SIZE_FORMAT_W(7), hi.max_length); > 933: tty->print_cr(" Average symbol length %7.2f", ((float)hi.total_length / (float)hi.total_count)); Same here ------------- PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559621098 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282284397 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282289794 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282302648 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282303865 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282304084 From coleenp at openjdk.org Wed Aug 2 19:25:42 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Aug 2023 19:25:42 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. Thanks for looking at this in detail Matias and for asking questions. I hope I've answered them sufficiently. ------------- PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559677392 From coleenp at openjdk.org Wed Aug 2 19:25:46 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Aug 2023 19:25:46 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 18:35:14 GMT, Matias Saavedra Silva wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. > > src/hotspot/share/classfile/altHashing.cpp line 111: > >> 109: } >> 110: >> 111: static void halfsiphash_init32(uint32_t v[4], uint64_t seed) { > > I believe all the bitwise operators here will promote the result to int. Will this cause further conversion issues with uint32_t? Since uint32_t is wider, I don't think so (at least I don't get a warning for it with -Wconversion). > src/hotspot/share/classfile/classFileParser.cpp line 5244: > >> 5242: // that changes, then InstanceKlass::idnum_can_increment() >> 5243: // has to be changed accordingly. >> 5244: ik->set_initial_method_idnum(checked_cast(ik->methods()->length())); > > Here you are setting a field inside an instance klass to a field acquired from within the same instance klass. Maybe it would be better for this to be a method internal to InstanceKlass? There are a few calls like this here, that should be in instanceKlass. I'd rather not move it with this change. > src/hotspot/share/classfile/symbolTable.cpp line 240: > >> 238: >> 239: double SymbolTable::get_load_factor() { >> 240: return (double)_items_count/(double)_current_size; > > Is this redundant? Both operands are `size_t` so you can cast the result as opposed to both operands. If I cast the result, I'll lose the remainder. I had to cast current_size because otherwise the compiler complained about it. > src/hotspot/share/classfile/symbolTable.cpp line 933: > >> 931: tty->print_cr(" Total symbol length " SIZE_FORMAT_W(7), hi.total_length); >> 932: tty->print_cr(" Maximum symbol length " SIZE_FORMAT_W(7), hi.max_length); >> 933: tty->print_cr(" Average symbol length %7.2f", ((float)hi.total_length / (float)hi.total_count)); > > Same here I think each value needs to be cast to get the correct result. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282319686 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282322968 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282321857 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282322221 From matsaave at openjdk.org Wed Aug 2 19:51:42 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 2 Aug 2023 19:51:42 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. Thank you for addressing my questions, it looks like everything is good then! ------------- Marked as reviewed by matsaave (Committer). PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559737926 From matsaave at openjdk.org Wed Aug 2 20:19:06 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 2 Aug 2023 20:19:06 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry Message-ID: The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. ------------- Commit messages: - 8313554: Fix -Wconversion warnings for ResolvedFieldEntry Changes: https://git.openjdk.org/jdk/pull/15126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313554 Stats: 9 lines in 3 files changed: 2 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15126.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15126/head:pull/15126 PR: https://git.openjdk.org/jdk/pull/15126 From duke at openjdk.org Wed Aug 2 20:48:51 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Wed, 2 Aug 2023 20:48:51 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 13:32:36 GMT, Feilong Jiang wrote: >> Please review this changes into risc-v double rounding intrinsic. >> >> On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). >> >> Also, we should provide some rounding mode to fcvt.x.x instruction. >> >> Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: >> >>> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). >> >> For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. >> For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. >> >> For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). >> As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). >> >> We have observed significant improvement on hifive and thead boards. >> >> testing: tier1, tier2 and hotspot:tier3 on hifive >> >> Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): >> >> Without intrinsic: >> >> Benchmark (TESTSIZE) Mode Cnt Score Error Units >> FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms >> FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms >> FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms >> >> With intrinsic: >> >> Benchmark (TESTSIZE) Mode Cnt Score Error Units >> FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms >> FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms >> FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4286: > >> 4284: slli(mask, mask, 63); >> 4285: // conversion from double to long >> 4286: fcvt_l_d(converted_dbl, src, rm_direct); > > How about using `fclass` [1] to check the special cases of input, then we can just do `fcvt.l.d` and `fcvt.d.l` for normal inputs? We can check the result of `fclass`. If the input contains NaN/infinity/+0/-0, we could return the value without conversion. > > 1. https://github.com/riscv/riscv-isa-manual/blob/3a6edf7ebf6af9e6ad92ace865c0069090870c20/src/f-st-ext.adoc?plain=1#L487-L500 Hi, thanks for your review. Also, we can use `fclass` to check cases NaN/+(-)INF/+(-)0.0 but we still need to check if value exeed `2^63 - 1 `(for positive input value) and `-2^63` (for negative one). So, we should leave check of converted value and we can add branch with a result of `fclass`. It will give an additional branch on regular values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1282402592 From dholmes at openjdk.org Wed Aug 2 23:29:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Aug 2023 23:29:00 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 19:18:47 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/symbolTable.cpp line 240: >> >>> 238: >>> 239: double SymbolTable::get_load_factor() { >>> 240: return (double)_items_count/(double)_current_size; >> >> Is this redundant? Both operands are `size_t` so you can cast the result as opposed to both operands. > > If I cast the result, I'll lose the remainder. I had to cast current_size because otherwise the compiler complained about it. Yep an unsigned 64-bit type can't be implicitly converted to double without risking a loss of value ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282500923 From dholmes at openjdk.org Wed Aug 2 23:34:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Aug 2023 23:34:15 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 19:19:15 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/symbolTable.cpp line 933: >> >>> 931: tty->print_cr(" Total symbol length " SIZE_FORMAT_W(7), hi.total_length); >>> 932: tty->print_cr(" Maximum symbol length " SIZE_FORMAT_W(7), hi.max_length); >>> 933: tty->print_cr(" Average symbol length %7.2f", ((float)hi.total_length / (float)hi.total_count)); >> >> Same here > > I think each value needs to be cast to get the correct result. Yes size_t values must be cast to float/double. Again I think double should be used here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282503088 From dholmes at openjdk.org Wed Aug 2 23:34:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Aug 2023 23:34:11 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 18:57:46 GMT, Matias Saavedra Silva wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. > > src/hotspot/share/classfile/symbolTable.cpp line 926: > >> 924: if (_symbols_counted > 0) { >> 925: tty->print_cr(" Percent removed %3.2f", >> 926: ((float)_symbols_removed / (float)_symbols_counted) * 100); > > I think you can also just cast once here. These should probably be double rather than float - the float result will be promoted to double to be passed as an argument anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282502783 From dholmes at openjdk.org Wed Aug 2 23:42:21 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Aug 2023 23:42:21 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. A couple of queries/comments but overall seems reasonable. Thanbks. src/hotspot/share/classfile/loaderConstraints.cpp line 498: > 496: for (int i = 0; i < len; i++) { > 497: LoaderConstraint* probe = set.constraint_at(i); > 498: sum += (int)sizeof(*probe) + (probe->num_loaders() * (int)sizeof(ClassLoaderData*)); Can't you just cast the final result to int? src/hotspot/share/classfile/stringTable.cpp line 891: > 889: > 890: _shared_table.reset(); > 891: CompactHashtableWriter writer((int)_items_count, ArchiveBuilder::string_stats()); This makes me question why `Items_count` Is a size_t, when we treat it as an int. src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 59: > 57: if ((value % BytesPerLong) != 0) { > 58: JVMFlag::printError(verbose, > 59: "ContendedPaddingWidth (%u) must be " Why %u when it is an int? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559971126 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282505262 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282505740 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282506266 From coleenp at openjdk.org Thu Aug 3 00:13:52 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 00:13:52 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 19:15:24 GMT, Matias Saavedra Silva wrote: > The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. Looks good to me, thank you for fixing these. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15126#pullrequestreview-1559990891 From coleenp at openjdk.org Thu Aug 3 00:16:05 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 00:16:05 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v3] In-Reply-To: References: Message-ID: > This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: David's suggestions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15111/files - new: https://git.openjdk.org/jdk/pull/15111/files/0e97905c..864a80f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=01-02 Stats: 14 lines in 4 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/15111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15111/head:pull/15111 PR: https://git.openjdk.org/jdk/pull/15111 From coleenp at openjdk.org Thu Aug 3 00:16:06 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 00:16:06 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 13:40:12 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. Thanks for reviewing, David. Reran with -Wconversion and now tier1 on your suggestions. ------------- PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1559985858 From coleenp at openjdk.org Thu Aug 3 00:16:11 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 00:16:11 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: <81KnSfIwLtCaxX-0GqLcCMH2gBtq7ZmRHJz7RjOLpIE=.79851543-8c0c-48da-8f3d-cae1cdd612a0@github.com> On Wed, 2 Aug 2023 23:36:42 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed a case that gets -Wconversion warning for ContendedPaddingWidth. prefetch_data_size() returns uint, so added a checked_cast<> to catch the case where it would return greater than signed int max. > > src/hotspot/share/classfile/loaderConstraints.cpp line 498: > >> 496: for (int i = 0; i < len; i++) { >> 497: LoaderConstraint* probe = set.constraint_at(i); >> 498: sum += (int)sizeof(*probe) + (probe->num_loaders() * (int)sizeof(ClassLoaderData*)); > > Can't you just cast the final result to int? I suppose I could. > src/hotspot/share/classfile/stringTable.cpp line 891: > >> 889: >> 890: _shared_table.reset(); >> 891: CompactHashtableWriter writer((int)_items_count, ArchiveBuilder::string_stats()); > > This makes me question why `Items_count` Is a size_t, when we treat it as an int. Good question. I see no reason why it needs to be. Also _items_count in StringTable is the same. > src/hotspot/share/runtime/flags/jvmFlagConstraintsRuntime.cpp line 59: > >> 57: if ((value % BytesPerLong) != 0) { >> 58: JVMFlag::printError(verbose, >> 59: "ContendedPaddingWidth (%u) must be " > > Why %u when it is an int? I had a temporary version where it was uint that didn't do the range check message correctly. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282515731 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282517308 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282517830 From coleenp at openjdk.org Thu Aug 3 00:16:12 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 00:16:12 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 23:30:36 GMT, David Holmes wrote: >> src/hotspot/share/classfile/symbolTable.cpp line 926: >> >>> 924: if (_symbols_counted > 0) { >>> 925: tty->print_cr(" Percent removed %3.2f", >>> 926: ((float)_symbols_removed / (float)_symbols_counted) * 100); >> >> I think you can also just cast once here. > > These should probably be double rather than float - the float result will be promoted to double to be passed as an argument anyway. Changed to double. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282517473 From coleenp at openjdk.org Thu Aug 3 00:16:13 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 00:16:13 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v2] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 23:31:17 GMT, David Holmes wrote: >> I think each value needs to be cast to get the correct result. > > Yes size_t values must be cast to float/double. Again I think double should be used here. Also changed to double. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282517582 From coleenp at openjdk.org Thu Aug 3 00:18:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 00:18:20 GMT Subject: RFR: 8256379: Replace SIZE_FORMAT with 'z' length modifier Message-ID: Replace SIZE_FORMAT with %zu and SIZE_FORMAT_X with 0x%zx using a 4 line sed script: sed -e 's/" SIZE_FORMAT "/%zu/g' -e 's/" SIZE_FORMAT,/%zu",/' \ -e 's/print(SIZE_FORMAT "/print("%zu/g' \ -e 's/" SIZE_FORMAT_X "/0x%zx/g' -e 's/" SIZE_FORMAT_X,/0x%zx",/g' \ -e 's/" SIZE_FORMAT$/%zu"/' \ $f >$f.new Minor fixups afterwards. I didn't change SIZE_FORMAT_W(number) because it would have required a better sed script. The definitions in globalDefinitions.hpp can be removed with a later PR, once all instances are cleaned out. This is partial so that people start using %zu instead. Tested with tier1 on Oracle supported platforms. ------------- Commit messages: - Fix Shenandoah file. - Hand fixups. - More conversions. - Fixed SSIZE_FORMAT (now there are none), also more SIZE_FORMAT in os and cpu directories. - Sed the gc code too. - Fix SIZE_FORMAT, SIZE_FORMAT_X in all but gc. - Update gtest Changes: https://git.openjdk.org/jdk/pull/15115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8256379 Stats: 1161 lines in 257 files changed: 5 ins; 2 del; 1154 mod Patch: https://git.openjdk.org/jdk/pull/15115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15115/head:pull/15115 PR: https://git.openjdk.org/jdk/pull/15115 From coleenp at openjdk.org Thu Aug 3 00:18:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 00:18:20 GMT Subject: RFR: 8256379: Replace SIZE_FORMAT with 'z' length modifier In-Reply-To: References: Message-ID: <9P2cMpIjMkf9iIGF-yO79kGuumwD5WA7YsjQBqEZw9g=.abea4112-603d-460d-bfd4-3199ea2f45c7@github.com> On Wed, 2 Aug 2023 01:31:43 GMT, Coleen Phillimore wrote: > Replace SIZE_FORMAT with %zu and SIZE_FORMAT_X with 0x%zx using a 4 line sed script: > > sed -e 's/" SIZE_FORMAT "/%zu/g' -e 's/" SIZE_FORMAT,/%zu",/' \ > -e 's/print(SIZE_FORMAT "/print("%zu/g' \ > -e 's/" SIZE_FORMAT_X "/0x%zx/g' -e 's/" SIZE_FORMAT_X,/0x%zx",/g' \ > -e 's/" SIZE_FORMAT$/%zu"/' \ > $f >$f.new > > Minor fixups afterwards. I didn't change SIZE_FORMAT_W(number) because it would have required a better sed script. > > The definitions in globalDefinitions.hpp can be removed with a later PR, once all instances are cleaned out. This is partial so that people start using %zu instead. > > Tested with tier1 on Oracle supported platforms. Do we want this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15115#issuecomment-1663120451 From fjiang at openjdk.org Thu Aug 3 01:11:42 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 3 Aug 2023 01:11:42 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: Message-ID: <19WAdFX2lqYf-Hka7-pw2r5Um6sjztL1JVx8lfFyKu4=.12997dbc-506b-4470-ba2c-a5275c587ff2@github.com> On Mon, 24 Jul 2023 08:22:52 GMT, Ilya Gavrilin wrote: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4302: > 4300: // if got conversion overflow return src > 4301: bind(bad_val); > 4302: fsgnj_d(dst, src, src); We can use `fmv_d(dst, src)` here for better understanding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1282541489 From coleenp at openjdk.org Thu Aug 3 01:37:08 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 01:37:08 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: References: Message-ID: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> > This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix Atomic items_added code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15111/files - new: https://git.openjdk.org/jdk/pull/15111/files/864a80f7..4019e4ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15111/head:pull/15111 PR: https://git.openjdk.org/jdk/pull/15111 From lmesnik at openjdk.org Thu Aug 3 02:49:47 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 3 Aug 2023 02:49:47 GMT Subject: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects Message-ID: The fix adds posting VmObjectAlloc events by Unsafe.allocateInstance(Class cls). The previous attempt to post event directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance regression even if jvmti event is not enabled. Some optimizations have been disabled just because possible usage and escaping of newly allocated object. So event posting is doing by returning to interpreter if events are enabled. I verified that that performance (run locally only) of org.renaissance.jdk.streams.JmhScrabble.runOperation doesn't change if events are not enabled. There might be other intrinsics like 'LibraryCallKit::inline_unsafe_newArray()' where VM allocate memory. I'm going to file separate issue to find and fix them. Many thanks to Tobias H. for proposed solution. Testing with all tiers. ------------- Commit messages: - fixed comments and problemlist - fixed - 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects Changes: https://git.openjdk.org/jdk/pull/15110/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15110&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307462 Stats: 39 lines in 6 files changed: 35 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15110/head:pull/15110 PR: https://git.openjdk.org/jdk/pull/15110 From dholmes at openjdk.org Thu Aug 3 06:36:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Aug 2023 06:36:31 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry In-Reply-To: References: Message-ID: <29n-55EX7mppMHbjlFN3EuvqlS4IsJ_-0lNIJWsbHSA=.a783d054-c73e-4c9d-a027-9bd363cff867@github.com> On Wed, 2 Aug 2023 19:15:24 GMT, Matias Saavedra Silva wrote: > The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. I'm still not seeing the pattern, in these Wconversion changes, of when to use checked_cast, when to use static_cast and when to use a raw C-style cast?? ------------- PR Review: https://git.openjdk.org/jdk/pull/15126#pullrequestreview-1560325246 From stuefe at openjdk.org Thu Aug 3 06:40:32 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 3 Aug 2023 06:40:32 GMT Subject: RFR: 8256379: Replace SIZE_FORMAT with 'z' length modifier In-Reply-To: <9P2cMpIjMkf9iIGF-yO79kGuumwD5WA7YsjQBqEZw9g=.abea4112-603d-460d-bfd4-3199ea2f45c7@github.com> References: <9P2cMpIjMkf9iIGF-yO79kGuumwD5WA7YsjQBqEZw9g=.abea4112-603d-460d-bfd4-3199ea2f45c7@github.com> Message-ID: On Thu, 3 Aug 2023 00:12:09 GMT, Coleen Phillimore wrote: > Do we want this? It won't surprise you that I'm not a fan. This will cause many otherwise painless backports across this commit not to be cleanly mergeable. I'm warming to the %z notion, provided all our compilers can do that. But my vote would be for doing this when writing new code or changing code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15115#issuecomment-1663376189 From dholmes at openjdk.org Thu Aug 3 06:45:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Aug 2023 06:45:33 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Atomic items_added code. Changes requested by dholmes (Reviewer). src/hotspot/share/classfile/stringTable.cpp line 804: > 802: void StringTable::allocate_shared_strings_array(TRAPS) { > 803: assert(DumpSharedSpaces, "must be"); > 804: if (_items_count > max_jint) { This is impossible given `_items_count_` is now an int src/hotspot/share/classfile/symbolTable.cpp line 91: > 89: > 90: static volatile int _items_count = 0; > 91: static volatile bool _has_items_to_clean = false; Nit: the extra spaces are not needed now we use a shorter type name src/hotspot/share/classfile/symbolTable.cpp line 240: > 238: > 239: double SymbolTable::get_load_factor() { > 240: return (double)_items_count/(double)_current_size; You shouldn't need the cast to double now `_items_count` is an int. ------------- PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1560333725 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282715657 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282717016 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1282719265 From yzheng at openjdk.org Thu Aug 3 06:57:52 2023 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 3 Aug 2023 06:57:52 GMT Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available results to JVMCI compilers. Message-ID: This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`. This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments. ------------- Commit messages: - Allow jvmci compiler to query if an intrinsic is disabled by the HotSpot runtime. Changes: https://git.openjdk.org/jdk/pull/15133/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313372 Stats: 109 lines in 12 files changed: 93 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/15133.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15133/head:pull/15133 PR: https://git.openjdk.org/jdk/pull/15133 From yzheng at openjdk.org Thu Aug 3 07:12:08 2023 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 3 Aug 2023 07:12:08 GMT Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available results to JVMCI compilers. [v2] In-Reply-To: References: Message-ID: > This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`. > This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments. Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: update is_intrinsic_supported for _dcopySign,_fcopySign. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15133/files - new: https://git.openjdk.org/jdk/pull/15133/files/7328edcb..fba23164 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15133&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15133&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15133.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15133/head:pull/15133 PR: https://git.openjdk.org/jdk/pull/15133 From yzheng at openjdk.org Thu Aug 3 07:12:31 2023 From: yzheng at openjdk.org (Yudi Zheng) Date: Thu, 3 Aug 2023 07:12:31 GMT Subject: RFR: 8313372: [JVMCI] Export vmIntrinsics::is_intrinsic_available results to JVMCI compilers. [v2] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 07:12:08 GMT, Yudi Zheng wrote: >> This PR exports `vmIntrinsic::is_intrinsic_available`, `Compiler::is_intrinsic_supported`, and `C2Compiler::is_intrinsic_supported` results to JVMCI compiler. This allows JVMCI compiler to comply with `-XX:DisableIntrinsic`, `-XX:ControlIntrinsic`, `-XX:-UseXXXIntrinsic`, and is essential for running test that depends on these flags, e.g., `java/lang/Float/Binary16ConversionNaN` that returns different result in the interpreter with `-XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16`. >> This PR also attempts to fix some of the `is_intrinsic_available` results. Please see the inlined comments. > > Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: > > update is_intrinsic_supported for _dcopySign,_fcopySign. src/hotspot/cpu/x86/vm_version_x86.cpp line 3229: > 3227: case vmIntrinsics::_electronicCodeBook_encryptAESCrypt: > 3228: case vmIntrinsics::_electronicCodeBook_decryptAESCrypt: > 3229: case vmIntrinsics::_galoisCounterMode_AESCrypt: Stubs for these intrinsics are generated with the following CPU features. See https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp#L159-L166 src/hotspot/cpu/x86/vm_version_x86.cpp line 3235: > 3233: break; > 3234: case vmIntrinsics::_bigIntegerRightShiftWorker: > 3235: case vmIntrinsics::_bigIntegerLeftShiftWorker: See https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L4169-L4172 src/hotspot/cpu/x86/vm_version_x86.cpp line 3247: > 3245: break; > 3246: case vmIntrinsics::_dcopySign: > 3247: case vmIntrinsics::_fcopySign: See https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/x86.ad#L1601-L1609 src/hotspot/cpu/x86/vm_version_x86.cpp line 3260: > 3258: case vmIntrinsics::_minF_strict: > 3259: case vmIntrinsics::_maxD_strict: > 3260: case vmIntrinsics::_minD_strict: See https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/x86.ad#L1534-L1543 src/hotspot/cpu/x86/vm_version_x86.hpp line 689: > 687: static bool supports_avxonly() { return ((supports_avx2() || supports_avx()) && !supports_evex()); } > 688: static bool supports_sha() { return (_features & CPU_SHA) != 0; } > 689: static bool supports_fma() { return (_features & CPU_FMA) != 0 && supports_avx(); } https://github.com/openjdk/jdk/blob/53ca75b18ea419d469758475fac8352bf915b484/src/hotspot/cpu/x86/vm_version_x86.cpp#L1154-L1158 implies fma intrinsic can be used without AVX src/hotspot/share/opto/c2compiler.cpp line 237: > 235: case vmIntrinsics::_electronicCodeBook_decryptAESCrypt: > 236: if (StubRoutines::electronicCodeBook_decryptAESCrypt() == nullptr) return false; > 237: break; These two intrinsics were marked as supported on non-x86 platforms where the underlying stubs are not generated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282729047 PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282730887 PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282736834 PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282737285 PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282747067 PR Review Comment: https://git.openjdk.org/jdk/pull/15133#discussion_r1282744793 From dholmes at openjdk.org Thu Aug 3 07:24:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Aug 2023 07:24:34 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 13:00:20 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > use try with resources in test Overall looks okay but I have a request for the test. Thanks. test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java line 54: > 52: recording.enable(EVENT_NAME); > 53: recording.start(); > 54: System.loadLibrary("awt"); I don't think loading libawt is a good choice - maybe libnet or libnio? Headless builds may not have libawt and I'd be concerned about loading it directly and running the OnLoad hooks. test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java line 77: > 75: libTemplate = "%s.dll"; > 76: } else if (Platform.isOSX()) { > 77: libTemplate = "lib%s.dylib"; We have `Platform.sharedLibraryExt()` to simplify this a bit. Unfortunately we don't have a `sharedLibraryPrefix()` to reduce it to one line. :( ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15065#pullrequestreview-1560383181 PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1282758846 PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1282754561 From dholmes at openjdk.org Thu Aug 3 07:24:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Aug 2023 07:24:37 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v2] In-Reply-To: <1nTNPYNbdYVP7rGcCoJPm9v6s4attBLU6dsicrzQ4P8=.419237ed-18cd-403f-82df-8cc6c3ece814@github.com> References: <4_Lts1-ejCc4haerOnycZ6Z9BW4sNZIEmPhOlsYts_M=.d084837a-7fd7-490a-8b85-910cc2cb30eb@github.com> <6hISPOUbmmgtxA_LZpLndhzDhGZdO5Yb9YCLLvNtLdk=.faf375dd-130c-4ce2-8812-1e8364483626@github.com> <1nTNPYNbdYVP7rGcCoJPm9v6s4attBLU6dsicrzQ4P8=.419237ed-18cd-403f-82df-8cc6c3ece814@github.com> Message-ID: <-RaJ1c3Nk7-gneOjl2YqXowwBsUS4I0775Djy0422II=.309761f8-c28a-48a3-8b4b-3efcc095de78@github.com> On Wed, 2 Aug 2023 12:24:10 GMT, Erik Gahlin wrote: >> Hi Erik , I removed the JFR with configure and attempted this (however on Linux) but for some reason I got build errors. So I better added the macros. (not sure why this happened, with some other JFR event living without INCLUDE_JFR seemed to work as expected) > > OK Just for completeness the various os_xxx.cpp files all use INCLUDE_JFR around event code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1282748997 From mbaesken at openjdk.org Thu Aug 3 07:33:33 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 3 Aug 2023 07:33:33 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 07:16:40 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> use try with resources in test > > test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java line 77: > >> 75: libTemplate = "%s.dll"; >> 76: } else if (Platform.isOSX()) { >> 77: libTemplate = "lib%s.dylib"; > > We have `Platform.sharedLibraryExt()` to simplify this a bit. Unfortunately we don't have a `sharedLibraryPrefix()` to reduce it to one line. :( Hi David, that coding can indeed be improved. But let's do it in a follow-up. And in the follow-up also for existing https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java where the same/similar code is present. The follow-up should also introduce 'sharedLibraryPrefix' . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1282770754 From dholmes at openjdk.org Thu Aug 3 07:41:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Aug 2023 07:41:37 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 07:30:47 GMT, Matthias Baesken wrote: >> test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java line 77: >> >>> 75: libTemplate = "%s.dll"; >>> 76: } else if (Platform.isOSX()) { >>> 77: libTemplate = "lib%s.dylib"; >> >> We have `Platform.sharedLibraryExt()` to simplify this a bit. Unfortunately we don't have a `sharedLibraryPrefix()` to reduce it to one line. :( > > Hi David, that coding can indeed be improved. But let's do it in a follow-up. And in the follow-up also for existing https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java where the same/similar code is present. The follow-up should also introduce 'sharedLibraryPrefix' . Okay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1282779923 From mbaesken at openjdk.org Thu Aug 3 07:45:36 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 3 Aug 2023 07:45:36 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 07:20:17 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> use try with resources in test > > test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java line 54: > >> 52: recording.enable(EVENT_NAME); >> 53: recording.start(); >> 54: System.loadLibrary("awt"); > > I don't think loading libawt is a good choice - maybe libnet or libnio? Headless builds may not have libawt and I'd be concerned about loading it directly and running the OnLoad hooks. libnet does not work, it gives us the error 'Native Library /testdir/images/jdk/lib/libnet.so already loaded in another classloader' . So we have to load something that is not there already. But I agree, awt might not be the best choice. What about libinstrument ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1282784258 From dholmes at openjdk.org Thu Aug 3 07:52:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Aug 2023 07:52:31 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 07:42:38 GMT, Matthias Baesken wrote: >> test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java line 54: >> >>> 52: recording.enable(EVENT_NAME); >>> 53: recording.start(); >>> 54: System.loadLibrary("awt"); >> >> I don't think loading libawt is a good choice - maybe libnet or libnio? Headless builds may not have libawt and I'd be concerned about loading it directly and running the OnLoad hooks. > > libnet does not work, it gives us the error 'Native Library /testdir/images/jdk/lib/libnet.so already loaded in another classloader' . So we have to load something that is not there already. But I agree, awt might not be the best choice. What about libinstrument ? Yeah that might work. If worse comes to worst, you could create a trivial library just or the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1282792645 From mbaesken at openjdk.org Thu Aug 3 07:59:56 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 3 Aug 2023 07:59:56 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v6] In-Reply-To: References: Message-ID: > Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: better check for libinstrument not awt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15065/files - new: https://git.openjdk.org/jdk/pull/15065/files/045f2832..40263d1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15065&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15065&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15065.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15065/head:pull/15065 PR: https://git.openjdk.org/jdk/pull/15065 From mbaesken at openjdk.org Thu Aug 3 08:01:34 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 3 Aug 2023 08:01:34 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v5] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 07:38:46 GMT, David Holmes wrote: >> Hi David, that coding can indeed be improved. But let's do it in a follow-up. And in the follow-up also for existing https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java where the same/similar code is present. The follow-up should also introduce 'sharedLibraryPrefix' . > > Okay I created https://bugs.openjdk.org/browse/JDK-8313670 . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15065#discussion_r1282803178 From jpbempel at openjdk.org Thu Aug 3 08:03:19 2023 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Thu, 3 Aug 2023 08:03:19 GMT Subject: RFR: 8308762: Metaspace leak with Instrumentation.retransform [v5] In-Reply-To: References: Message-ID: > Fix a small leak in constant pool merging during retransformation of a class. If this class has a catch block with `Throwable`, the class `Throwable` is pre-resolved in the constant pool, while all the other classes are in a unresolved state. So the constant pool merging process was considering the entry with pre-resolved class as different compared to the destination and create a new entry. We now try to consider it as equal specially for Methodref/Fieldref. Jean-Philippe Bempel has updated the pull request incrementally with two additional commits since the last revision: - remove now useless comment - Rewrite unit test unresolved t2 too, cleanup JVM_CONSTANT_Class useless case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14780/files - new: https://git.openjdk.org/jdk/pull/14780/files/c1a2d7c7..3784e653 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14780&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14780&range=03-04 Stats: 110 lines in 3 files changed: 7 ins; 80 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/14780.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14780/head:pull/14780 PR: https://git.openjdk.org/jdk/pull/14780 From jpbempel at openjdk.org Thu Aug 3 08:43:12 2023 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Thu, 3 Aug 2023 08:43:12 GMT Subject: RFR: 8308762: Metaspace leak with Instrumentation.retransform [v6] In-Reply-To: References: Message-ID: > Fix a small leak in constant pool merging during retransformation of a class. If this class has a catch block with `Throwable`, the class `Throwable` is pre-resolved in the constant pool, while all the other classes are in a unresolved state. So the constant pool merging process was considering the entry with pre-resolved class as different compared to the destination and create a new entry. We now try to consider it as equal specially for Methodref/Fieldref. Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: remove trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14780/files - new: https://git.openjdk.org/jdk/pull/14780/files/3784e653..26cb41b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14780&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14780&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14780.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14780/head:pull/14780 PR: https://git.openjdk.org/jdk/pull/14780 From dlong at openjdk.org Thu Aug 3 08:58:30 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 08:58:30 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 19:15:24 GMT, Matias Saavedra Silva wrote: > The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. src/hotspot/share/oops/resolvedFieldEntry.hpp line 106: > 104: void set_flags(bool is_final, bool is_volatile) { > 105: int new_flags = (is_final << is_final_shift) | static_cast(is_volatile); > 106: _flags = (u1)new_flags; Why isn't this using checked_cast? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15126#discussion_r1282875385 From dlong at openjdk.org Thu Aug 3 09:07:29 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 09:07:29 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 19:15:24 GMT, Matias Saavedra Silva wrote: > The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. src/hotspot/share/interpreter/rewriter.cpp line 192: > 190: int field_entry_index = Bytes::get_native_u2(p); > 191: int pool_index = _initialized_field_entries.at(field_entry_index).constant_pool_index(); > 192: Bytes::put_Java_u2(p, (u2)pool_index); I guess this isn't using checked_cast because similar code elsewhere in this file uses this style, but it means we can silently do the wrong thing. Is there a separate RFE to remove as many of these unchecked casts as possible? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15126#discussion_r1282886338 From jpbempel at openjdk.org Thu Aug 3 09:43:37 2023 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Thu, 3 Aug 2023 09:43:37 GMT Subject: RFR: 8308762: Metaspace leak with Instrumentation.retransform In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 14:34:38 GMT, Coleen Phillimore wrote: >> Fix a small leak in constant pool merging during retransformation of a class. If this class has a catch block with `Throwable`, the class `Throwable` is pre-resolved in the constant pool, while all the other classes are in a unresolved state. So the constant pool merging process was considering the entry with pre-resolved class as different compared to the destination and create a new entry. We now try to consider it as equal specially for Methodref/Fieldref. > > Also there is a nice test harness for class redefinition in the test/hotspot/jtreg/serviceability/jvmti/RedefineClasses tests that you might be able to use to add a test for this. @coleenp I have made the changes: cleanup code and rewrite the unit test ------------- PR Comment: https://git.openjdk.org/jdk/pull/14780#issuecomment-1663642898 From dlong at openjdk.org Thu Aug 3 10:30:36 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 10:30:36 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Atomic items_added code. src/hotspot/cpu/x86/vm_version_x86.cpp line 1808: > 1806: > 1807: // Allocation prefetch settings > 1808: int cache_line_size = checked_cast(prefetch_data_size()); I don't see why the old code would produce a warning, except with -Wsign-conversion on 32-bit platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283000602 From dlong at openjdk.org Thu Aug 3 10:39:35 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 10:39:35 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: <6r732e6rR30hGvg1N4Ai3wxFqS_b2YBUl7R3k7QmiqA=.5731621e-9f0a-4888-bd90-cbdee8d2b0d9@github.com> On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Atomic items_added code. src/hotspot/share/classfile/classFileParser.cpp line 973: > 971: void remove_annotation(ID id) { > 972: assert((int)id >= 0 && (int)id < (int)_annotation_LIMIT, "oob"); > 973: _annotations_present &= (int)~nth_bit((int)id); This silences the warning but without a runtime check. It would be nice to have a constexpr template version of nth_bit that return the desire type and also do a range check on the input, unlike this macro version always returns intx and returns 0 if the shift is out of range. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283009813 From dlong at openjdk.org Thu Aug 3 10:55:37 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 10:55:37 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: <5is4L3oJSgutFejiS62EDxKd_l1KnRsgZgWJ25FkupA=.659ab838-bf6e-4f23-ab09-5e7a7f23b1ac@github.com> On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Atomic items_added code. src/hotspot/share/classfile/symbolTable.cpp line 90: > 88: static size_t _current_size = 0; > 89: > 90: static volatile int _items_count = 0; Shouldn't there be a check somewhere that this value doesn't overflow? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283026840 From dlong at openjdk.org Thu Aug 3 11:00:36 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 11:00:36 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Atomic items_added code. src/hotspot/share/classfile/stringTable.cpp line 245: > 243: > 244: void StringTable::item_added() { > 245: Atomic::inc(&_items_count); Can this overflow? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283031367 From ogillespie at openjdk.org Thu Aug 3 11:29:49 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 3 Aug 2023 11:29:49 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup Message-ID: Fix leak in SymbolTable during cleanup. 1. symbol1 inserted in bucket, refcount 1 2. Decrement refcount for this symbol, refcount is now 0 3. symbol2 inserted in same bucket 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. Thanks @shipilev for help debugging and fixing this :) ------------- Commit messages: - 8313678 - SymbolTable can leak Symbols during cleanup Changes: https://git.openjdk.org/jdk/pull/15137/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313678 Stats: 30 lines in 10 files changed: 16 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/15137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15137/head:pull/15137 PR: https://git.openjdk.org/jdk/pull/15137 From mbaesken at openjdk.org Thu Aug 3 11:30:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 3 Aug 2023 11:30:32 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v6] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 07:59:56 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > better check for libinstrument not awt David are you fine with the latest version? I checked the GHA build errors and they are not related. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15065#issuecomment-1663813598 From coleenp at openjdk.org Thu Aug 3 11:53:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 11:53:31 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 09:05:12 GMT, Dean Long wrote: >> The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. > > src/hotspot/share/interpreter/rewriter.cpp line 192: > >> 190: int field_entry_index = Bytes::get_native_u2(p); >> 191: int pool_index = _initialized_field_entries.at(field_entry_index).constant_pool_index(); >> 192: Bytes::put_Java_u2(p, (u2)pool_index); > > I guess this isn't using checked_cast because similar code elsewhere in this file uses this style, but it means we can silently do the wrong thing. Is there a separate RFE to remove as many of these unchecked casts as possible? We could rewrite _initialized_field_entries to be an array of u2 and not need the cast, but that changed felt out of scope for this fix. > src/hotspot/share/oops/resolvedFieldEntry.hpp line 106: > >> 104: void set_flags(bool is_final, bool is_volatile) { >> 105: int new_flags = (is_final << is_final_shift) | static_cast(is_volatile); >> 106: _flags = (u1)new_flags; > > Why isn't this using checked_cast? I still don't see the point of using checked_cast if we know that this is only two bits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15126#discussion_r1283090793 PR Review Comment: https://git.openjdk.org/jdk/pull/15126#discussion_r1283084054 From coleenp at openjdk.org Thu Aug 3 12:01:35 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 12:01:35 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: <0Pl5etzO5Rc2jTPuTmVEeBQ7A5PEpeAAYVqpvxm8brM=.bf79af3a-f91c-4238-9237-4302228a840f@github.com> On Thu, 3 Aug 2023 06:37:34 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Atomic items_added code. > > src/hotspot/share/classfile/stringTable.cpp line 804: > >> 802: void StringTable::allocate_shared_strings_array(TRAPS) { >> 803: assert(DumpSharedSpaces, "must be"); >> 804: if (_items_count > max_jint) { > > This is impossible given `_items_count_` is now an int Maybe we still want items_count to be a size_t then so we can detect this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283099990 From coleenp at openjdk.org Thu Aug 3 12:19:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 12:19:56 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v5] In-Reply-To: References: Message-ID: > This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Revert items_count change to int. Add check for items_count overflow in SymbolTable. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15111/files - new: https://git.openjdk.org/jdk/pull/15111/files/4019e4ed..a092d427 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=03-04 Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/15111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15111/head:pull/15111 PR: https://git.openjdk.org/jdk/pull/15111 From coleenp at openjdk.org Thu Aug 3 12:19:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 12:19:56 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: <2Nk0F_L4pfkDn4phbWydP66deZ2-yihLx_6cUYUnZgo=.abb90ce3-3932-455b-93e4-68799b638f6d@github.com> On Thu, 3 Aug 2023 01:37:08 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Atomic items_added code. I reverted the items_count change. ------------- PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1560950292 From coleenp at openjdk.org Thu Aug 3 12:19:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 12:19:57 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: On Thu, 3 Aug 2023 10:27:57 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Atomic items_added code. > > src/hotspot/cpu/x86/vm_version_x86.cpp line 1808: > >> 1806: >> 1807: // Allocation prefetch settings >> 1808: int cache_line_size = checked_cast(prefetch_data_size()); > > I don't see why the old code would produce a warning, except with -Wsign-conversion on 32-bit platforms. I put the cast in because prefetch_data_size() returns uint and I'm narrowing it to int which has a lower positive range. I assume checked_cast would find that. > src/hotspot/share/classfile/classFileParser.cpp line 973: > >> 971: void remove_annotation(ID id) { >> 972: assert((int)id >= 0 && (int)id < (int)_annotation_LIMIT, "oob"); >> 973: _annotations_present &= (int)~nth_bit((int)id); > > This silences the warning but without a runtime check. It would be nice to have a constexpr template version of nth_bit that return the desire type and also do a range check on the input, unlike this macro version always returns intx and returns 0 if the shift is out of range. Let's fine a separate RFE for nth_bit and fix all of these at once. This appears a lot. > src/hotspot/share/classfile/stringTable.cpp line 245: > >> 243: >> 244: void StringTable::item_added() { >> 245: Atomic::inc(&_items_count); > > Can this overflow? Yes, I'm going to revert the _items_count change. > src/hotspot/share/classfile/symbolTable.cpp line 90: > >> 88: static size_t _current_size = 0; >> 89: >> 90: static volatile int _items_count = 0; > > Shouldn't there be a check somewhere that this value doesn't overflow? Yes, there should be here too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283108957 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283109704 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283110162 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283113986 From coleenp at openjdk.org Thu Aug 3 12:19:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 12:19:57 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: On Thu, 3 Aug 2023 06:39:19 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Atomic items_added code. > > src/hotspot/share/classfile/symbolTable.cpp line 91: > >> 89: >> 90: static volatile int _items_count = 0; >> 91: static volatile bool _has_items_to_clean = false; > > Nit: the extra spaces are not needed now we use a shorter type name Since I'm reverting the change, it can have extra spaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283110902 From tschatzl at openjdk.org Thu Aug 3 13:21:48 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 3 Aug 2023 13:21:48 GMT Subject: RFR: 8310031: Parallel: Implement better work distribution for large object arrays in old gen [v3] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 16:20:13 GMT, Richard Reingruber wrote: >> This pr introduces parallel scanning of large object arrays in the old generation containing roots for young collections of Parallel GC. This allows for better distribution of the actual work (following the array references) as opposed to "stealing" from other task queues which can lead to inverse scaling demonstrated by small tests (attached to JDK-8310031) and also observed in gerrit production systems. >> >> The algorithm to share scanning large arrays is supposed to be a straight >> forward extension of the scheme implemented in >> `PSCardTable::scavenge_contents_parallel`. >> >> - A worker scans the part of a large array located in its stripe >> >> - Except for the end of the large array reaching into a stripe which is scanned by the thread owning the previous stripe. This is just what the current implementation does: it skips objects crossing into the stripe. >> >> - For this it is necessary that large arrays cover at least 3 stripes (see `PSCardTable::large_obj_arr_min_words`) >> >> The implementation also makes use of the precise card marks for arrays. Only dirty regions are actually scanned. >> >> #### Performance testing >> >> ##### BigArrayInOldGenRR.java >> >> [BigArrayInOldGenRR.java](https://bugs.openjdk.org/secure/attachment/104422/BigArrayInOldGenRR.java) is a micro benchmark that assigns new objects to a large array in a loop. Creating new array elements triggers young collections. In each collection the large array is scanned because of its references to the new elements in the young generation. The benchmark score is the geometric mean of the duration of the last 5 young collections (lower is better). >> >> [BigArrayInOldGenRR.pdf](https://cr.openjdk.org/~rrich/webrevs/8310031/BigArrayInOldGenRR.pdf)([BigArrayInOldGenRR.ods](https://cr.openjdk.org/~rrich/webrevs/8310031/BigArrayInOldGenRR.ods)) presents the benchmark results with 1 to 64 gc threads. >> >> Observations >> >> * JDK22 scales inversely. Adding gc threads prolongues young collections. With 32 threads young collections take ~15x longer than single threaded. >> >> * Fixed JDK22 scales well. Adding gc theads reduces the duration of young collections. With 32 threads young collections are 5x shorter than single threaded. >> >> * With just 1 gc thread there is a regression. Young collections are 1.5x longer with the fix. I assume the reason is that the iteration over the array elements is interrupted at the end of a stripe which makes it less efficient. The prize for parallelization is paid ... > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Limit effect of previous commit to large array handling Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/parallel/psCardTable.cpp line 140: > 138: // Note: if a part of an object is on a dirty card, all cards this object > 139: // resides on are considered dirty except for large object arrays. The card marks > 140: // of object arrays are precise which allows scanning of just the dirty regions. Suggestion: // of objArrays are precise which allows scanning of just the dirty parts. src/hotspot/share/gc/parallel/psCardTable.cpp line 159: > 157: HeapWord* obj_addr = start_array->object_start(addr_for(i_card)-1); > 158: if (large_obj_array == cast_to_oop(obj_addr)) { > 159: // we scan only dirty regions of large arrays Suggestion: // We scan dirty parts of large objArrays precisely, so return immediately. Maybe "chunks"? src/hotspot/share/gc/parallel/psCardTable.cpp line 239: > 237: // > 238: // Parallel scanning of large arrays is also based on stripes with the exception > 239: // of the last 2 stripes: the chunks defined by them are scanned together. Suggestion: // // Large objArrays are also distributed across threads by stripes, except for // the last 2 stripes which are scanned by the thread owning the second-to-last stripe. A "chunk" seems to be not defined here. src/hotspot/share/gc/parallel/psCardTable.cpp line 257: > 255: space_top); > 256: > 257: // Process a stripe iff it contains any obj-start or large array chunk Suggestion: // Stripes without an object start may either contain a large object, or a part of a large objArray; the latter must be handled specially, the former is handled by the owner of the stripe where that large object starts. I think the original comment referred to the not-taken path of the next `if`; sind the taken path now also potentially processes an object (looking for a part of a large objArray) I reformulated it. src/hotspot/share/gc/parallel/psCardTable.cpp line 259: > 257: // Process a stripe iff it contains any obj-start or large array chunk > 258: if (!start_array->object_starts_in_range(cur_stripe_addr, cur_stripe_end_addr)) { > 259: // Scan middle and end of large arrays That is not true. We may also get here if this is a large non-objArray (or non-Array). src/hotspot/share/gc/parallel/psCardTable.cpp line 268: > 266: // 2. range of cards can be cleared: [clear_limit_l, clear_limit_r) > 267: // 3. range of objs (obj-start) can be scanned: [first_obj_addr, cur_stripe_end_addr) > 268: // 4. range of large array elements to be scanned: [first_obj_addr, cur_stripe_end_addr) Suggestion: // 4. range of large objArray elements to be scanned: [first_obj_addr, cur_stripe_end_addr) src/hotspot/share/gc/parallel/psCardTable.cpp line 269: > 267: // 3. range of objs (obj-start) can be scanned: [first_obj_addr, cur_stripe_end_addr) > 268: // 4. range of large array elements to be scanned: [first_obj_addr, cur_stripe_end_addr) > 269: // limited to dirty regions The term "dirty regions" is new here (from what I can see). Other code uses "dirty cards", or use "dirty areas". Please do not add new nomenclature that may be confused with something else elsewhere. Or maybe this refers to "dirty chunks" defined only below. src/hotspot/share/gc/parallel/psCardTable.cpp line 311: > 309: } > 310: // Reaching here we know that the large array starts in this stripe. > 311: // If it starts here then its end has to be in a following stripe. ... but not the next. src/hotspot/share/gc/parallel/psCardTable.cpp line 315: > 313: obj_end_addr >= cur_stripe_end_addr, "overlapping work"); > 314: obj_end_addr = cur_stripe_end_addr; > 315: large_arr = objArrayOop(cast_to_oop(obj_addr)); I would almost prefer that the code, on detection of a large objArray that covers the rest of the stripe, just called the "handle-large-object" method in some way. The remaining code is rather complicated to follow, and if that remaining code had the precondition of not being about handling large objArrays, would be easier to understand. src/hotspot/share/gc/parallel/psCardTable.cpp line 380: > 378: > 379: // Partially scan a large object array in the given stripe. > 380: // Scan to end if it is in the next stripe. That comment (which is wrong, it processes any large object covering a complete stripe) should be placed in the `.hpp` file. src/hotspot/share/gc/parallel/psCardTable.cpp line 386: > 384: HeapWord* stripe_end_addr, > 385: HeapWord* space_top) { > 386: const size_t stripe_size_in_words = num_cards_in_stripe * _card_size_in_words; This is not used until after the first `if`, please define there. src/hotspot/share/gc/parallel/psCardTable.cpp line 391: > 389: > 390: size_t arr_sz; > 391: if (large_arr_addr == nullptr || How can `large_arr_addr` be null? src/hotspot/share/gc/parallel/psCardTable.cpp line 393: > 391: if (large_arr_addr == nullptr || > 392: !cast_to_oop(large_arr_addr)->is_objArray() || > 393: (arr_sz = cast_to_oop(large_arr_addr)->size()) < large_obj_arr_min_words()) I do not like the assignment in the condition, but if you really want it, keep it. src/hotspot/share/gc/parallel/psCardTable.cpp line 394: > 392: !cast_to_oop(large_arr_addr)->is_objArray() || > 393: (arr_sz = cast_to_oop(large_arr_addr)->size()) < large_obj_arr_min_words()) > 394: return; Missing `{}` surrounding the `return`. src/hotspot/share/gc/parallel/psCardTable.cpp line 400: > 398: > 399: if (arr_end_addr <= stripe_end_addr) { > 400: // the end chunk is scanned together with the chunk in the previous stripe Suggestion: // The end chunk is scanned together with the chunk in the previous stripe. src/hotspot/share/gc/parallel/psCardTable.cpp line 414: > 412: HeapWord* next_stripe_end = MIN2(next_stripe + stripe_size_in_words, space_top); > 413: > 414: // scan to end if it is in the following stripe Suggestion: // Scan to end if it is in the following stripe. *What* is in the following stripe? Maybe "The object ends in the next stripe"? src/hotspot/share/gc/parallel/psCardTable.hpp line 46: > 44: > 45: static const size_t num_cards_in_stripe = 128; > 46: static size_t large_obj_arr_min_words() { return 2 * num_cards_in_stripe * _card_size_in_words + 1; } given that the term `num_cards_in_stripe * _card_size_in_words` is calculated 3 times, it may be worth factoring it out; also maybe, instead of repeated checks `obj_size < large_obj_arr_min_words()` a predicate like `is_large_array` or something may be nicer. src/hotspot/share/gc/parallel/psCardTable.hpp line 75: > 73: uint stripe_index, > 74: uint n_stripes); > 75: void scavenge_large_array_stripe(ObjectStartArray* start_array, Suggestion: void scavenge_large_obj_stripe(ObjectStartArray* start_array, This method is called in contexts where we only know that whatever is in the stripe, is large, and it does not start in that stripe. It may be a regular large object, a `typeArray` object or an `objArray` object, hence the rename. src/hotspot/share/gc/parallel/psPromotionManager.hpp line 180: > 178: > 179: void push_contents(oop obj); > 180: void push_array_region(objArrayOop arr, HeapWord* left, HeapWord* right); Suggestion: void push_objArray_contents(objArrayOop arr, HeapWord* left, HeapWord* right); ------------- PR Review: https://git.openjdk.org/jdk/pull/14846#pullrequestreview-1560900692 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283078836 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283078250 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283131791 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283082107 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283133993 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283077035 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283083587 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283192324 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283187135 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283162462 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283166372 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283164367 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283169690 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283166747 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283170391 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283175809 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283173739 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283134912 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1283135811 From duke at openjdk.org Thu Aug 3 13:47:31 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Thu, 3 Aug 2023 13:47:31 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: <5RAZrov0Ss7Is1OMYjzZ78srasN_9rGQcoq-KaYu2aE=.ae10565f-fb5c-4def-b145-22363ec0fc7d@github.com> References: <5RAZrov0Ss7Is1OMYjzZ78srasN_9rGQcoq-KaYu2aE=.ae10565f-fb5c-4def-b145-22363ec0fc7d@github.com> Message-ID: On Wed, 2 Aug 2023 05:07:31 GMT, David Holmes wrote: > Pity there is no regression/functional test for this. @dholmes-ora @plummercj I have improved [dumpclass tests](https://github.com/openjdk/jdk/commit/97618cc9bbadce4b51fc0fbee93557f4dcc8d26a) to cover up some cases for this PR and [JDK-8311971](https://bugs.openjdk.org/browse/JDK-8311971). If the tests makes sense I would like to include it in this PR. Is that okay? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15005#issuecomment-1664011833 From tschatzl at openjdk.org Thu Aug 3 14:02:32 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 3 Aug 2023 14:02:32 GMT Subject: RFR: 8310031: Parallel: Implement better work distribution for large object arrays in old gen [v3] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 16:20:13 GMT, Richard Reingruber wrote: >> This pr introduces parallel scanning of large object arrays in the old generation containing roots for young collections of Parallel GC. This allows for better distribution of the actual work (following the array references) as opposed to "stealing" from other task queues which can lead to inverse scaling demonstrated by small tests (attached to JDK-8310031) and also observed in gerrit production systems. >> >> The algorithm to share scanning large arrays is supposed to be a straight >> forward extension of the scheme implemented in >> `PSCardTable::scavenge_contents_parallel`. >> >> - A worker scans the part of a large array located in its stripe >> >> - Except for the end of the large array reaching into a stripe which is scanned by the thread owning the previous stripe. This is just what the current implementation does: it skips objects crossing into the stripe. >> >> - For this it is necessary that large arrays cover at least 3 stripes (see `PSCardTable::large_obj_arr_min_words`) >> >> The implementation also makes use of the precise card marks for arrays. Only dirty regions are actually scanned. >> >> #### Performance testing >> >> ##### BigArrayInOldGenRR.java >> >> [BigArrayInOldGenRR.java](https://bugs.openjdk.org/secure/attachment/104422/BigArrayInOldGenRR.java) is a micro benchmark that assigns new objects to a large array in a loop. Creating new array elements triggers young collections. In each collection the large array is scanned because of its references to the new elements in the young generation. The benchmark score is the geometric mean of the duration of the last 5 young collections (lower is better). >> >> [BigArrayInOldGenRR.pdf](https://cr.openjdk.org/~rrich/webrevs/8310031/BigArrayInOldGenRR.pdf)([BigArrayInOldGenRR.ods](https://cr.openjdk.org/~rrich/webrevs/8310031/BigArrayInOldGenRR.ods)) presents the benchmark results with 1 to 64 gc threads. >> >> Observations >> >> * JDK22 scales inversely. Adding gc threads prolongues young collections. With 32 threads young collections take ~15x longer than single threaded. >> >> * Fixed JDK22 scales well. Adding gc theads reduces the duration of young collections. With 32 threads young collections are 5x shorter than single threaded. >> >> * With just 1 gc thread there is a regression. Young collections are 1.5x longer with the fix. I assume the reason is that the iteration over the array elements is interrupted at the end of a stripe which makes it less efficient. The prize for parallelization is paid ... > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Limit effect of previous commit to large array handling Another option that is likely more readable is putting the distinction between iterating over a large objArray and regular object into `PSCardTable::scan_objects_in_range` instead of trying to split these two. I.e. So that this inner loop looks like g1/serial in `HeapRegion::oops_on_memregion_iterate()`. I am not sure where the requirement implemented that the last part of a large objArray must be scanned by the thread working on the second-to-last stripe comes from too. The performance sensitive part of this scanning code is typically not finding the dirty cards but actually scanning the corresponding objects and doing the per-reference work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14846#issuecomment-1664037176 From mbaesken at openjdk.org Thu Aug 3 14:09:35 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 3 Aug 2023 14:09:35 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError Message-ID: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. ------------- Commit messages: - JDK-8313691 Changes: https://git.openjdk.org/jdk/pull/15139/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313691 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15139/head:pull/15139 PR: https://git.openjdk.org/jdk/pull/15139 From cjplummer at openjdk.org Thu Aug 3 16:02:32 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 3 Aug 2023 16:02:32 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: <5RAZrov0Ss7Is1OMYjzZ78srasN_9rGQcoq-KaYu2aE=.ae10565f-fb5c-4def-b145-22363ec0fc7d@github.com> References: <5RAZrov0Ss7Is1OMYjzZ78srasN_9rGQcoq-KaYu2aE=.ae10565f-fb5c-4def-b145-22363ec0fc7d@github.com> Message-ID: On Wed, 2 Aug 2023 05:07:31 GMT, David Holmes wrote: >> @dholmes-ora I verified the case for hidden dynamically injected classes. The dumped class data for a hidden dynamically injected class does not have any Nest-Host attribute. When generating these classes dynamically the VM does not expose nest-host information in the class data, but sets the nest-host directly in the InstanceKlass. >> >> Also verified the case for deeply nested classes by creating chain of nested classes as: >> >> class DeepNest { >> class NestLvl1 { >> class NestLvl2 { >> class NestLvl3 { >> } >> } >> } >> } >> >> >> Only `DeepNest` has the `NestMembers` attribute which lists all the NestLvl[1-3] classes. Rest all have `DeepNest` as the `NestHost` attribute. >> >> Does this cover all the cases you flagged? > > @ashu-mehra thanks for doing the additional testing. Pity there is no regression/functional test for this. > @dholmes-ora @plummercj I have improved [dumpclass tests](https://github.com/openjdk/jdk/commit/97618cc9bbadce4b51fc0fbee93557f4dcc8d26a) to cover up some cases for this PR and [JDK-8311971](https://bugs.openjdk.org/browse/JDK-8311971). If the tests makes sense I would like to include it in this PR. Is that okay? I think given the scope of the changes it would be better to do this with a "Improve SA dumpclass testing" CR/PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15005#issuecomment-1664244491 From duke at openjdk.org Thu Aug 3 16:09:33 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Thu, 3 Aug 2023 16:09:33 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: References: <5RAZrov0Ss7Is1OMYjzZ78srasN_9rGQcoq-KaYu2aE=.ae10565f-fb5c-4def-b145-22363ec0fc7d@github.com> Message-ID: On Thu, 3 Aug 2023 15:59:14 GMT, Chris Plummer wrote: >> @ashu-mehra thanks for doing the additional testing. Pity there is no regression/functional test for this. > >> @dholmes-ora @plummercj I have improved [dumpclass tests](https://github.com/openjdk/jdk/commit/97618cc9bbadce4b51fc0fbee93557f4dcc8d26a) to cover up some cases for this PR and [JDK-8311971](https://bugs.openjdk.org/browse/JDK-8311971). If the tests makes sense I would like to include it in this PR. Is that okay? > > I think given the scope of the changes it would be better to do this with a "Improve SA dumpclass testing" CR/PR. @plummercj > I think given the scope of the changes it would be better to do this with a "Improve SA dumpclass testing" CR/PR. Okay. I guess this can then be integrated as is. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15005#issuecomment-1664254792 From matsaave at openjdk.org Thu Aug 3 16:18:31 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 3 Aug 2023 16:18:31 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 11:48:43 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/resolvedFieldEntry.hpp line 106: >> >>> 104: void set_flags(bool is_final, bool is_volatile) { >>> 105: int new_flags = (is_final << is_final_shift) | static_cast(is_volatile); >>> 106: _flags = (u1)new_flags; >> >> Why isn't this using checked_cast? > > I still don't see the point of using checked_cast if we know that this is only two bits. As far as I've designed it, only the last two bits of the flags are ever set or used. C++ booleans are either 0 or 1 so the higher bits should never be set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15126#discussion_r1283432290 From rrich at openjdk.org Thu Aug 3 16:51:34 2023 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 3 Aug 2023 16:51:34 GMT Subject: RFR: 8310031: Parallel: Implement better work distribution for large object arrays in old gen [v3] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 16:20:13 GMT, Richard Reingruber wrote: >> This pr introduces parallel scanning of large object arrays in the old generation containing roots for young collections of Parallel GC. This allows for better distribution of the actual work (following the array references) as opposed to "stealing" from other task queues which can lead to inverse scaling demonstrated by small tests (attached to JDK-8310031) and also observed in gerrit production systems. >> >> The algorithm to share scanning large arrays is supposed to be a straight >> forward extension of the scheme implemented in >> `PSCardTable::scavenge_contents_parallel`. >> >> - A worker scans the part of a large array located in its stripe >> >> - Except for the end of the large array reaching into a stripe which is scanned by the thread owning the previous stripe. This is just what the current implementation does: it skips objects crossing into the stripe. >> >> - For this it is necessary that large arrays cover at least 3 stripes (see `PSCardTable::large_obj_arr_min_words`) >> >> The implementation also makes use of the precise card marks for arrays. Only dirty regions are actually scanned. >> >> #### Performance testing >> >> ##### BigArrayInOldGenRR.java >> >> [BigArrayInOldGenRR.java](https://bugs.openjdk.org/secure/attachment/104422/BigArrayInOldGenRR.java) is a micro benchmark that assigns new objects to a large array in a loop. Creating new array elements triggers young collections. In each collection the large array is scanned because of its references to the new elements in the young generation. The benchmark score is the geometric mean of the duration of the last 5 young collections (lower is better). >> >> [BigArrayInOldGenRR.pdf](https://cr.openjdk.org/~rrich/webrevs/8310031/BigArrayInOldGenRR.pdf)([BigArrayInOldGenRR.ods](https://cr.openjdk.org/~rrich/webrevs/8310031/BigArrayInOldGenRR.ods)) presents the benchmark results with 1 to 64 gc threads. >> >> Observations >> >> * JDK22 scales inversely. Adding gc threads prolongues young collections. With 32 threads young collections take ~15x longer than single threaded. >> >> * Fixed JDK22 scales well. Adding gc theads reduces the duration of young collections. With 32 threads young collections are 5x shorter than single threaded. >> >> * With just 1 gc thread there is a regression. Young collections are 1.5x longer with the fix. I assume the reason is that the iteration over the array elements is interrupted at the end of a stripe which makes it less efficient. The prize for parallelization is paid ... > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Limit effect of previous commit to large array handling Thanks a lot for the feedback. I'm very keen to go through it but currently (and for the rest of summer holidays) I'm out of office. I'll get to it asap when back. Thanks, Richard. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14846#issuecomment-1664313826 From coleenp at openjdk.org Thu Aug 3 19:13:38 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 19:13:38 GMT Subject: RFR: 8256379: Replace SIZE_FORMAT with 'z' length modifier In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 01:31:43 GMT, Coleen Phillimore wrote: > Replace SIZE_FORMAT with %zu and SIZE_FORMAT_X with 0x%zx using a 4 line sed script: > > sed -e 's/" SIZE_FORMAT "/%zu/g' -e 's/" SIZE_FORMAT,/%zu",/' \ > -e 's/print(SIZE_FORMAT "/print("%zu/g' \ > -e 's/" SIZE_FORMAT_X "/0x%zx/g' -e 's/" SIZE_FORMAT_X,/0x%zx",/g' \ > -e 's/" SIZE_FORMAT$/%zu"/' \ > $f >$f.new > > Minor fixups afterwards. I didn't change SIZE_FORMAT_W(number) because it would have required a better sed script. > > The definitions in globalDefinitions.hpp can be removed with a later PR, once all instances are cleaned out. This is partial so that people start using %zu instead. > > Tested with tier1 on Oracle supported platforms. The %zu format looks much nicer than " SIZE_FORMAT " but I don't think we should do this either. We can start using them with new code, or code we modify. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15115#issuecomment-1664492414 From coleenp at openjdk.org Thu Aug 3 19:13:39 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 19:13:39 GMT Subject: Withdrawn: 8256379: Replace SIZE_FORMAT with 'z' length modifier In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 01:31:43 GMT, Coleen Phillimore wrote: > Replace SIZE_FORMAT with %zu and SIZE_FORMAT_X with 0x%zx using a 4 line sed script: > > sed -e 's/" SIZE_FORMAT "/%zu/g' -e 's/" SIZE_FORMAT,/%zu",/' \ > -e 's/print(SIZE_FORMAT "/print("%zu/g' \ > -e 's/" SIZE_FORMAT_X "/0x%zx/g' -e 's/" SIZE_FORMAT_X,/0x%zx",/g' \ > -e 's/" SIZE_FORMAT$/%zu"/' \ > $f >$f.new > > Minor fixups afterwards. I didn't change SIZE_FORMAT_W(number) because it would have required a better sed script. > > The definitions in globalDefinitions.hpp can be removed with a later PR, once all instances are cleaned out. This is partial so that people start using %zu instead. > > Tested with tier1 on Oracle supported platforms. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15115 From coleenp at openjdk.org Thu Aug 3 19:18:30 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 19:18:30 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry In-Reply-To: References: Message-ID: <7SLhEk7o9nw7ZfKR63ONj5uGWkVubzPuFnIvU9jzZMA=.989622ab-4120-452d-8689-50c4162c98a5@github.com> On Thu, 3 Aug 2023 16:16:12 GMT, Matias Saavedra Silva wrote: >> I still don't see the point of using checked_cast if we know that this is only two bits. > > As far as I've designed it, only the last two bits of the flags are ever set or used. C++ booleans are either 0 or 1 so the higher bits should never be set. It is only two bits and the only variable here "is_final_shift" is 1. This could use 1 to make it obvious but the variable is used in the templateInterpreter code. Again, I think this is good. This is never going to be a bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15126#discussion_r1283618989 From dlong at openjdk.org Thu Aug 3 19:50:47 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 19:50:47 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: On Thu, 3 Aug 2023 12:07:27 GMT, Coleen Phillimore wrote: >> src/hotspot/cpu/x86/vm_version_x86.cpp line 1808: >> >>> 1806: >>> 1807: // Allocation prefetch settings >>> 1808: int cache_line_size = checked_cast(prefetch_data_size()); >> >> I don't see why the old code would produce a warning, except with -Wsign-conversion on 32-bit platforms. > > I put the cast in because prefetch_data_size() returns uint and I'm narrowing it to int which has a lower positive range. I assume checked_cast would find that. OK, so you caught it by inspection and are fixing it proactively :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283649276 From matsaave at openjdk.org Thu Aug 3 20:53:56 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 3 Aug 2023 20:53:56 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v2] In-Reply-To: References: Message-ID: > The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Change to checked_cast ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15126/files - new: https://git.openjdk.org/jdk/pull/15126/files/962d0e18..da649530 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15126&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15126&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15126.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15126/head:pull/15126 PR: https://git.openjdk.org/jdk/pull/15126 From coleenp at openjdk.org Thu Aug 3 21:23:41 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 21:23:41 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v2] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:53:56 GMT, Matias Saavedra Silva wrote: >> The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Change to checked_cast The checked_cast<> change is fine. Hopefully appeases other reviewers. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15126#pullrequestreview-1561877850 From coleenp at openjdk.org Thu Aug 3 21:26:33 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Aug 2023 21:26:33 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v4] In-Reply-To: References: <8XNzqQ0zpV5YncglessS5CNYLr4flnM6Q-1umUZTcxw=.8660051e-8e3d-494f-86b9-cbf577895d50@github.com> Message-ID: On Thu, 3 Aug 2023 19:47:42 GMT, Dean Long wrote: >> I put the cast in because prefetch_data_size() returns uint and I'm narrowing it to int which has a lower positive range. I assume checked_cast would find that. > > OK, so you caught it by inspection and are fixing it proactively :-) Yeah heading off these -Wsign-conversion warnings :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283734384 From dlong at openjdk.org Thu Aug 3 22:45:31 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 22:45:31 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v2] In-Reply-To: <7SLhEk7o9nw7ZfKR63ONj5uGWkVubzPuFnIvU9jzZMA=.989622ab-4120-452d-8689-50c4162c98a5@github.com> References: <7SLhEk7o9nw7ZfKR63ONj5uGWkVubzPuFnIvU9jzZMA=.989622ab-4120-452d-8689-50c4162c98a5@github.com> Message-ID: <2OJhT5MVhBDP9dJHvcWtL2r4K0v7U1Rq8JEcd3qhJPs=.9366db7e-ab4b-4d64-8ed1-282ee00b1266@github.com> On Thu, 3 Aug 2023 19:15:30 GMT, Coleen Phillimore wrote: >> As far as I've designed it, only the last two bits of the flags are ever set or used. C++ booleans are either 0 or 1 so the higher bits should never be set. > > It is only two bits and the only variable here "is_final_shift" is 1. This could use 1 to make it obvious but the variable is used in the templateInterpreter code. Again, I think this is good. This is never going to be a bug. It's fine unless the shift values get changed so the value no longer fits in u1. Then it fails silently. As an alternative to checked_cast, how about something like: assert(is_final() == is_final, ""); assert(is_volatile() == is_volatile, ""); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15126#discussion_r1283787162 From dlong at openjdk.org Thu Aug 3 22:49:33 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 3 Aug 2023 22:49:33 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v2] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:53:56 GMT, Matias Saavedra Silva wrote: >> The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Change to checked_cast src/hotspot/share/interpreter/rewriter.cpp line 188: > 186: int cp_index = Bytes::get_Java_u2(p); > 187: int field_entry_index = _cp_map.at(cp_index); > 188: Bytes::put_native_u2(p, checked_cast(field_entry_index)); I would have put the checked_cast on the initialization and not the use, but this is OK too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15126#discussion_r1283789662 From andrew at openjdk.org Thu Aug 3 23:41:38 2023 From: andrew at openjdk.org (Andrew John Hughes) Date: Thu, 3 Aug 2023 23:41:38 GMT Subject: RFR: 8256379: Replace SIZE_FORMAT with 'z' length modifier In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 01:31:43 GMT, Coleen Phillimore wrote: > Replace SIZE_FORMAT with %zu and SIZE_FORMAT_X with 0x%zx using a 4 line sed script: > > sed -e 's/" SIZE_FORMAT "/%zu/g' -e 's/" SIZE_FORMAT,/%zu",/' \ > -e 's/print(SIZE_FORMAT "/print("%zu/g' \ > -e 's/" SIZE_FORMAT_X "/0x%zx/g' -e 's/" SIZE_FORMAT_X,/0x%zx",/g' \ > -e 's/" SIZE_FORMAT$/%zu"/' \ > $f >$f.new > > Minor fixups afterwards. I didn't change SIZE_FORMAT_W(number) because it would have required a better sed script. > > The definitions in globalDefinitions.hpp can be removed with a later PR, once all instances are cleaned out. This is partial so that people start using %zu instead. > > Tested with tier1 on Oracle supported platforms. I actually agree with using `%z` for this, but this seems an unusual way to approach it. The `SIZE_FORMAT` is an abstraction which allows the actual format specifier to be anything defined in `globalDefinitions.hpp`. Removing it to hardcode a format thus seems like a bit of a backward step to me. I've actually had a patch hanging around for the best part of a decade that uses `%z` as the format specifier, but only on s390 (31-bit). As you may know, `size_t` and `int` aren't interchangeable on s390, which used to throw up all sorts of errors with the casts in HotSpot. On that platform, it really is necessary to use `%z` for the size format. The patch pretty much got dropped on the floor as we didn't build on s390 on newer JDKs and obviously we'd need to start there to get it upstream and then backport. The actual patch was pretty simple though: ~~~ diff --git openjdk.orig/hotspot/src/share/vm/utilities/globalDefinitions.hpp openjdk/hotspot/src/share/vm/utilities/globalDefinitions.hpp --- openjdk.orig/hotspot/src/share/vm/utilities/globalDefinitions.hpp +++ openjdk/hotspot/src/share/vm/utilities/globalDefinitions.hpp @@ -1389,12 +1389,21 @@ #define INTPTR_FORMAT_W(width) "%" #width PRIxPTR +#if defined(S390) && !defined(_LP64) +#define SSIZE_FORMAT "%z" PRIdPTR +#define SIZE_FORMAT "%z" PRIuPTR +#define SIZE_FORMAT_HEX "0x%z" PRIxPTR +#define SSIZE_FORMAT_W(width) "%" #width "z" PRIdPTR +#define SIZE_FORMAT_W(width) "%" #width "z" PRIuPTR +#define SIZE_FORMAT_HEX_W(width) "0x%" #width "z" PRIxPTR +#else // !S390 #define SSIZE_FORMAT "%" PRIdPTR #define SIZE_FORMAT "%" PRIuPTR #define SIZE_FORMAT_HEX "0x%" PRIxPTR #define SSIZE_FORMAT_W(width) "%" #width PRIdPTR #define SIZE_FORMAT_W(width) "%" #width PRIuPTR #define SIZE_FORMAT_HEX_W(width) "0x%" #width PRIxPTR +#endif // S390 #define INTX_FORMAT "%" PRIdPTR #define UINTX_FORMAT "%" PRIuPTR ~~~ plus a bunch of cases where the wrong format was being used in the `printf` statements (likely resolved now anyway; this was against 8u) I think you could do something similar and include backwards compatibility by detecting whether `%z` is usable during `configure` and then adding a similar `#ifdef` but based on something defined by `configure`. I'd be happy to propose something if you don't already have an alternate solution in the works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15115#issuecomment-1664765034 From dlong at openjdk.org Fri Aug 4 01:33:47 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 01:33:47 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v2] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 20:53:56 GMT, Matias Saavedra Silva wrote: >> The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Change to checked_cast Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15126#pullrequestreview-1562056121 From egahlin at openjdk.org Fri Aug 4 04:01:46 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 4 Aug 2023 04:01:46 GMT Subject: RFR: 8313722: JFR: Avoid unnecessary calls to Events.from(Recording) Message-ID: Could I have a review of PR that removes unnecessary calls to Events.from(Recording). With each call a new dump file is created. A better approach is store the events in a List that can be reused, Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/15147/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313722 Stats: 48 lines in 11 files changed: 14 ins; 1 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/15147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15147/head:pull/15147 PR: https://git.openjdk.org/jdk/pull/15147 From dholmes at openjdk.org Fri Aug 4 05:21:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 4 Aug 2023 05:21:35 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v5] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 12:19:56 GMT, Coleen Phillimore wrote: >> This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Revert items_count change to int. Add check for items_count overflow in SymbolTable. Okay on reverting the `item_count` changes - but we should look at a follow up RFE to get these types sorted out. Thanks src/hotspot/share/classfile/stringTable.cpp line 805: > 803: assert(DumpSharedSpaces, "must be"); > 804: if (_items_count > (size_t)max_jint) { > 805: fatal("Too many strings to be archived: " SIZE_FORMAT, _items_count); An opportunity for `%zu`? :) src/hotspot/share/classfile/stringTable.cpp line 828: > 826: // refer to more than 16384 * 16384 = 26M interned strings! Not a practical concern > 827: // but bail out for safety. > 828: log_error(cds)("Too many strings to be archived: " SIZE_FORMAT, _items_count); Ditto `%zu`? src/hotspot/share/classfile/symbolTable.cpp line 661: > 659: size_t SymbolTable::estimate_size_for_archive() { > 660: if (_items_count > (size_t)max_jint) { > 661: fatal("Too many symbols to be archived: " SIZE_FORMAT, _items_count); Ditto `%zu`? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15111#pullrequestreview-1562184513 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283988934 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283989728 PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1283990078 From dholmes at openjdk.org Fri Aug 4 05:48:30 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 4 Aug 2023 05:48:30 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v6] In-Reply-To: References: Message-ID: <9sLh6RIxlLpthjN5UOkMnu1muTw9s5L3GbZfOFxeeT0=.298b055b-bc3b-4f69-82e4-01e8987b4196@github.com> On Thu, 3 Aug 2023 07:59:56 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > better check for libinstrument not awt Looks okay. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15065#pullrequestreview-1562208060 From dholmes at openjdk.org Fri Aug 4 05:57:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 4 Aug 2023 05:57:29 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError In-Reply-To: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: On Thu, 3 Aug 2023 14:02:22 GMT, Matthias Baesken wrote: > In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. > The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). > > However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. Functional fix is fine but the comment change is not needed IMO and becomes inconsistent with similar uses in ciEnv.cpp Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15139#pullrequestreview-1562217671 From dholmes at openjdk.org Fri Aug 4 06:05:41 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 4 Aug 2023 06:05:41 GMT Subject: RFR: 8256379: Replace SIZE_FORMAT with 'z' length modifier In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 23:39:11 GMT, Andrew John Hughes wrote: > Removing it to hardcode a format thus seems like a bit of a backward step to me. But we only defined abstract things like `SIZE_FORMAT` because there was no single specifier accepted by all C runtimes and which behaves in the same (or similar enough) way. Once we have use of `%zu` or %zd` available everywhere then we no longer need the abstraction. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15115#issuecomment-1665059059 From thartmann at openjdk.org Fri Aug 4 06:43:28 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 4 Aug 2023 06:43:28 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError In-Reply-To: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: <5DBsTPsGI2ayiT288zV7MvcQRJDtsqj3JW4TXQG4qQw=.670aa894-1d7e-4f51-a78a-ca9f33987e91@github.com> On Thu, 3 Aug 2023 14:02:22 GMT, Matthias Baesken wrote: > In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. > The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). > > However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. Should we re-add the close in the failing case that we backed out with https://github.com/openjdk/jdk/commit/4577147993c2f87e6ba298a664acad5decc968f0? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15139#issuecomment-1665090569 From lmesnik at openjdk.org Fri Aug 4 06:44:05 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 4 Aug 2023 06:44:05 GMT Subject: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v2] In-Reply-To: References: Message-ID: > The fix adds posting VmObjectAlloc events by Unsafe.allocateInstance(Class cls). The previous attempt to post event directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance regression even if jvmti event is not enabled. Some optimizations have been disabled just because possible usage and escaping of newly allocated object. > So event posting is doing by returning to interpreter if events are enabled. > > I verified that that performance (run locally only) of > org.renaissance.jdk.streams.JmhScrabble.runOperation > doesn't change if events are not enabled. > > There might be other intrinsics like 'LibraryCallKit::inline_unsafe_newArray()' where VM allocate memory. I'm going to file separate issue to find and fix them. > > Many thanks to Tobias H. for proposed solution. > > Testing with all tiers. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: combined jvmti code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15110/files - new: https://git.openjdk.org/jdk/pull/15110/files/07499679..5095114f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15110&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15110&range=00-01 Stats: 38 lines in 1 file changed: 17 ins; 21 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15110/head:pull/15110 PR: https://git.openjdk.org/jdk/pull/15110 From mbaesken at openjdk.org Fri Aug 4 07:02:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Aug 2023 07:02:02 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError and ciEnv [v2] In-Reply-To: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: > In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. > The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). > > However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. Matthias Baesken 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: - Adjust ciEnv.cpp and comment - Merge remote-tracking branch 'origin/master' into JDK-8313691 - JDK-8313691 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15139/files - new: https://git.openjdk.org/jdk/pull/15139/files/e5fb6d69..6b870bce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15139&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15139&range=00-01 Stats: 127 lines in 14 files changed: 111 ins; 12 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15139.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15139/head:pull/15139 PR: https://git.openjdk.org/jdk/pull/15139 From mbaesken at openjdk.org Fri Aug 4 07:02:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Aug 2023 07:02:02 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError and ciEnv In-Reply-To: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: <_2PHJk0k6gcKNYDvcjMFzN6Sq_zxJN75E8MshSfGQi4=.1e26c0ff-cdad-4ea4-b32f-06ab6374ee6f@github.com> On Thu, 3 Aug 2023 14:02:22 GMT, Matthias Baesken wrote: > In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. > The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). > > However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. > Should we re-add the close in the failing case that we backed out with [4577147](https://github.com/openjdk/jdk/commit/4577147993c2f87e6ba298a664acad5decc968f0)? I re-added them and adjusted the comment. (and thanks for doing the backout, doing fclose twice was not a good thing ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15139#issuecomment-1665102552 From mbaesken at openjdk.org Fri Aug 4 07:05:45 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Aug 2023 07:05:45 GMT Subject: RFR: JDK-8313251: Add NativeLibraryLoad event [v6] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 07:59:56 GMT, Matthias Baesken wrote: >> Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > better check for libinstrument not awt Hi David , thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15065#issuecomment-1665110733 From mbaesken at openjdk.org Fri Aug 4 07:05:47 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Aug 2023 07:05:47 GMT Subject: Integrated: JDK-8313251: Add NativeLibraryLoad event In-Reply-To: References: Message-ID: On Fri, 28 Jul 2023 08:10:24 GMT, Matthias Baesken wrote: > Add a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. This gives a time stamp and success + error details of the load operation. It enhances the already existing information we get from the existing NativeLibrary event (that periodically samples the native modules of the jvm process). This pull request has now been integrated. Changeset: 5d232959 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/5d232959c2d98b632a5c48c89f369f7e80c8b68f Stats: 218 lines in 9 files changed: 216 ins; 0 del; 2 mod 8313251: Add NativeLibraryLoad event Reviewed-by: jbechberger, egahlin, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/15065 From mbaesken at openjdk.org Fri Aug 4 10:06:43 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 4 Aug 2023 10:06:43 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests Message-ID: There is coding e.g. in https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 that deals with shared lib naming on different OS. This code should be simplified. ------------- Commit messages: - JDK-8313670 Changes: https://git.openjdk.org/jdk/pull/15151/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313670 Stats: 77 lines in 6 files changed: 13 ins; 59 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151 PR: https://git.openjdk.org/jdk/pull/15151 From shade at openjdk.org Fri Aug 4 10:10:07 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 4 Aug 2023 10:10:07 GMT Subject: RFR: 8313202: MutexLocker should disallow null Mutexes [v4] In-Reply-To: References: Message-ID: <500Sw-ywqMYUF2_-A5x8XoeTm7R8t-dJIM0FspyKSOk=.5347111c-26f3-4058-ae06-8c35c6c705b3@github.com> > As seen in [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081), it is fairly easy to pass nullptr `Mutex` to `MutexLocker` by accident, which would just silently avoid the lock. > > There are a few places in Hotspot where we pass `nullptr` to simulate re-entrancy and/or conditionally take the lock. Those places can be more explicit, and the default `MutexLocker` can disallow nullptrs for extra safety. > > Open for some bikeshedding on the names of the new `MutexLockers`. Particularly `ReentrantMutexLocker` might lull readers into believing it does safepoint checks on re-entrant "lock", which it actually does not do. > > More thorough testing with different GC/JIT combinations is running now, we might find more issues there. Meanwhile, please comment on the approach. > > Additional testing: > - [x] `grep -R "MutexLocker " src/hotspot | grep -i null`, no hits > - [x] `grep -R "MutexLocker " src/hotspot | grep -i ?`, no hits > - [x] Linux AArch64 fastdebug, `tier1 tier2 tier3` (re-run in progress) Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into JDK-8313202-mutexlocker-nulls - Accept one more potentially nullptr mutex - Merge branch 'master' into JDK-8313202-mutexlocker-nulls - Replace ReentrantMutexLocker with ConditionalMutexLocker - Workaround for JDK-8313210 - Fixing CodeCache analytics - Initial work ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15043/files - new: https://git.openjdk.org/jdk/pull/15043/files/770c95af..9eb3e1ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15043&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15043&range=02-03 Stats: 8269 lines in 292 files changed: 4601 ins; 1730 del; 1938 mod Patch: https://git.openjdk.org/jdk/pull/15043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15043/head:pull/15043 PR: https://git.openjdk.org/jdk/pull/15043 From mgronlun at openjdk.org Fri Aug 4 11:01:42 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 4 Aug 2023 11:01:42 GMT Subject: RFR: 8313552: Fix -Wconversion warnings in JFR code Message-ID: Greetings, this change set removes -Wconversion warnings in the JFR code. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8313552 Changes: https://git.openjdk.org/jdk/pull/15152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313552 Stats: 248 lines in 28 files changed: 21 ins; 11 del; 216 mod Patch: https://git.openjdk.org/jdk/pull/15152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15152/head:pull/15152 PR: https://git.openjdk.org/jdk/pull/15152 From stefank at openjdk.org Fri Aug 4 11:34:43 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 4 Aug 2023 11:34:43 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names Message-ID: I've found that our misc flags printing is broken. This can be seen in our hs_err files: RCX=0x00007f86bf0073c8 is a pointer to class: java.lang.Class {0x00007f86bf0073c8} - instance size: 22 - klass size: 97 - access: public final synchronized - flags: ##name ##name ##name ##name ##name ##name With this fix the flags are now printed as expected: java.util.Hashtable {0x00007f5fff00e8c0} - instance size: 8 - klass size: 123 - access: public synchronized - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. ------------- Commit messages: - 8313752: InstanceKlassFlags::print_on doesn't print the flag names Changes: https://git.openjdk.org/jdk/pull/15153/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313752 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15153/head:pull/15153 PR: https://git.openjdk.org/jdk/pull/15153 From stuefe at openjdk.org Fri Aug 4 11:51:29 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 4 Aug 2023 11:51:29 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 11:28:50 GMT, Stefan Karlsson wrote: > I've found that our misc flags printing is broken. This can be seen in our hs_err files: > > RCX=0x00007f86bf0073c8 is a pointer to class: > java.lang.Class {0x00007f86bf0073c8} > - instance size: 22 > - klass size: 97 > - access: public final synchronized > - flags: ##name ##name ##name ##name ##name ##name > > > With this fix the flags are now printed as expected: > > java.util.Hashtable {0x00007f5fff00e8c0} > - instance size: 8 > - klass size: 123 > - access: public synchronized > - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method > > > The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. Good! And thanks for the test. I'm unemotional about the indentation. Up to you. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15153#pullrequestreview-1562717893 From shade at openjdk.org Fri Aug 4 11:54:29 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 4 Aug 2023 11:54:29 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names In-Reply-To: References: Message-ID: <8iVc_FBGMCTAvDNVIMWlYiFqk3N1-moT_Tgn9plSRmg=.5a36ba6b-909a-48be-8360-18dee7695faf@github.com> On Fri, 4 Aug 2023 11:28:50 GMT, Stefan Karlsson wrote: > I've found that our misc flags printing is broken. This can be seen in our hs_err files: > > RCX=0x00007f86bf0073c8 is a pointer to class: > java.lang.Class {0x00007f86bf0073c8} > - instance size: 22 > - klass size: 97 > - access: public final synchronized > - flags: ##name ##name ##name ##name ##name ##name > > > With this fix the flags are now printed as expected: > > java.util.Hashtable {0x00007f5fff00e8c0} > - instance size: 8 > - klass size: 123 > - access: public synchronized > - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method > > > The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. Whoops. Yes, just drop the leading space, if you can? ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15153#pullrequestreview-1562722482 From shade at openjdk.org Fri Aug 4 11:57:32 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 4 Aug 2023 11:57:32 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names In-Reply-To: References: Message-ID: <16sMYVXhU6UEgLB91EdZta9hZ0MfnOpwJmbBuN9VrgE=.ad82da01-559a-4a1e-b4ee-ac9bcd4704bc@github.com> On Fri, 4 Aug 2023 11:28:50 GMT, Stefan Karlsson wrote: > I've found that our misc flags printing is broken. This can be seen in our hs_err files: > > RCX=0x00007f86bf0073c8 is a pointer to class: > java.lang.Class {0x00007f86bf0073c8} > - instance size: 22 > - klass size: 97 > - access: public final synchronized > - flags: ##name ##name ##name ##name ##name ##name > > > With this fix the flags are now printed as expected: > > java.util.Hashtable {0x00007f5fff00e8c0} > - instance size: 8 > - klass size: 123 > - access: public synchronized > - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method > > > The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. Seems like introduced by https://github.com/openjdk/jdk/commit/316d303c1da550c9589c9be56b65650964e3886b#diff-1986c820f9f6ad5652414e734fa6d18cde5808bf943e220bcd99f8cd6e1c9eedR57 If we change the spaces, then `ConstMethodFlags::print_on` might need a change too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15153#issuecomment-1665491284 From thartmann at openjdk.org Fri Aug 4 12:03:32 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 4 Aug 2023 12:03:32 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError and ciEnv [v2] In-Reply-To: References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: On Fri, 4 Aug 2023 07:02:02 GMT, Matthias Baesken wrote: >> In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. >> The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). >> >> However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. > > Matthias Baesken 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: > > - Adjust ciEnv.cpp and comment > - Merge remote-tracking branch 'origin/master' into JDK-8313691 > - JDK-8313691 Looks good to me. I'll run some testing and report back once it passed. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15139#pullrequestreview-1562733954 From stefank at openjdk.org Fri Aug 4 13:01:33 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 4 Aug 2023 13:01:33 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 11:28:50 GMT, Stefan Karlsson wrote: > I've found that our misc flags printing is broken. This can be seen in our hs_err files: > > RCX=0x00007f86bf0073c8 is a pointer to class: > java.lang.Class {0x00007f86bf0073c8} > - instance size: 22 > - klass size: 97 > - access: public final synchronized > - flags: ##name ##name ##name ##name ##name ##name > > > With this fix the flags are now printed as expected: > > java.util.Hashtable {0x00007f5fff00e8c0} > - instance size: 8 > - klass size: 123 > - access: public synchronized > - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method > > > The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. OK. Thanks for reviewing! I'll wait for @coleenp to chime in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15153#issuecomment-1665568418 From tonyp at openjdk.org Fri Aug 4 13:17:34 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Fri, 4 Aug 2023 13:17:34 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic Message-ID: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): before: MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op after: MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op (only line 3 is not an improvement, but it has higher variation) It seems to save around 5% of executed instructions. ------------- Commit messages: - 8313779: RISC-V: use andn / orn in the MD5 instrinsic Changes: https://git.openjdk.org/jdk/pull/15156/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15156&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313779 Stats: 34 lines in 3 files changed: 26 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15156.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15156/head:pull/15156 PR: https://git.openjdk.org/jdk/pull/15156 From coleenp at openjdk.org Fri Aug 4 13:34:34 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 13:34:34 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v5] In-Reply-To: References: Message-ID: <1ETL8sKtJoR9kAD-YhnNP2Q7_aF0vZEbqZptm7F31N4=.a0064110-2e3f-47c2-b863-a12a8ad40e59@github.com> On Fri, 4 Aug 2023 05:14:16 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert items_count change to int. Add check for items_count overflow in SymbolTable. > > src/hotspot/share/classfile/stringTable.cpp line 805: > >> 803: assert(DumpSharedSpaces, "must be"); >> 804: if (_items_count > (size_t)max_jint) { >> 805: fatal("Too many strings to be archived: " SIZE_FORMAT, _items_count); > > An opportunity for `%zu`? :) Ok, yes! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15111#discussion_r1284431061 From coleenp at openjdk.org Fri Aug 4 13:45:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 13:45:29 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 11:28:50 GMT, Stefan Karlsson wrote: > I've found that our misc flags printing is broken. This can be seen in our hs_err files: > > RCX=0x00007f86bf0073c8 is a pointer to class: > java.lang.Class {0x00007f86bf0073c8} > - instance size: 22 > - klass size: 97 > - access: public final synchronized > - flags: ##name ##name ##name ##name ##name ##name > > > With this fix the flags are now printed as expected: > > java.util.Hashtable {0x00007f5fff00e8c0} > - instance size: 8 > - klass size: 123 > - access: public synchronized > - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method > > > The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. Thank you for finding and fixing this also can be considered trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15153#pullrequestreview-1562900751 From coleenp at openjdk.org Fri Aug 4 13:56:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 13:56:58 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v6] In-Reply-To: References: Message-ID: <0_xD69hxE5gv5yV_rrwe-4BrcSq7s9yH3ylT5Rvbaag=.2b460632-c05c-4b35-bf2d-b55184dc3bcb@github.com> > This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add %zu ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15111/files - new: https://git.openjdk.org/jdk/pull/15111/files/a092d427..9cfa3f32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15111&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15111/head:pull/15111 PR: https://git.openjdk.org/jdk/pull/15111 From coleenp at openjdk.org Fri Aug 4 14:06:33 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 14:06:33 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 11:21:27 GMT, Oli Gillespie wrote: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) I'm looking at this right now, and seems reasonable, but trying to think of another way other than adding this is_used_after parameter. ------------- PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1562942546 From coleenp at openjdk.org Fri Aug 4 14:09:45 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 14:09:45 GMT Subject: RFR: 8313564: Fix -Wconversion warnings in classfile code [v5] In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 05:18:35 GMT, David Holmes wrote: > Okay on reverting the item_count changes - but we should look at a follow up RFE to get these types sorted out. In this case, I think we need items_count to be size_t so that we can do an explicit bounds check for CDS, so this type is correct. Thanks for reviewing, Matias, Dean and David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15111#issuecomment-1665665640 From coleenp at openjdk.org Fri Aug 4 14:09:47 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 14:09:47 GMT Subject: Integrated: 8313564: Fix -Wconversion warnings in classfile code In-Reply-To: References: Message-ID: <2Pi0tWjOs5RTftP0IA2-VaSHw0RhAj3mjbbIMkCq5S8=.e1093551-c6fc-4990-a443-c2a9bd3c70be@github.com> On Tue, 1 Aug 2023 19:50:37 GMT, Coleen Phillimore wrote: > This patch fixes various -Wconversion warnings in classfile code. I broke the change into commits so the changes are easier to see. > Tested with tier1-4. This pull request has now been integrated. Changeset: f66cd500 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/f66cd5008d155e52a20a351ecd10469286517bf4 Stats: 57 lines in 19 files changed: 5 ins; 0 del; 52 mod 8313564: Fix -Wconversion warnings in classfile code Reviewed-by: matsaave, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/15111 From tonyp at openjdk.org Fri Aug 4 14:13:38 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Fri, 4 Aug 2023 14:13:38 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic In-Reply-To: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: On Fri, 4 Aug 2023 13:10:06 GMT, Antonios Printezis wrote: > Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): > > before: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op > > > after: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op > > > (only line 3 is not an improvement, but it has higher variation) > > It seems to save around 5% of executed instructions. Was not sure how to differentiate between the `andn` and `orn` in the assembler and the macro assembler. I added an `r` suffix. If there's a better way, let me know! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15156#issuecomment-1665673427 From tonyp at openjdk.org Fri Aug 4 14:22:32 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Fri, 4 Aug 2023 14:22:32 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic In-Reply-To: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: On Fri, 4 Aug 2023 13:10:06 GMT, Antonios Printezis wrote: > Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): > > before: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op > > > after: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op > > > (only line 3 is not an improvement, but it has higher variation) > > It seems to save around 5% of executed instructions. correctness testing: test/jdk/java/security/MessageDigest test/hotspot/jtreg/compiler/intrinsics/sha/sanity with `-UseZbb` and `+UseZbb` ------------- PR Comment: https://git.openjdk.org/jdk/pull/15156#issuecomment-1665689676 From luhenry at openjdk.org Fri Aug 4 14:35:37 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Fri, 4 Aug 2023 14:35:37 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic In-Reply-To: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: On Fri, 4 Aug 2023 13:10:06 GMT, Antonios Printezis wrote: > Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): > > before: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op > > > after: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op > > > (only line 3 is not an improvement, but it has higher variation) > > It seems to save around 5% of executed instructions. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1658: > 1656: > 1657: // Rd = Rs1 & (~Rd2) > 1658: void MacroAssembler::andnr(Register Rd, Register Rs1, Register Rs2) { Keep the name `andn` here, and at https://github.com/openjdk/jdk/pull/15156/files#diff-7a5c3ed05b6f3f06ed1c59f5fc2a14ec566a6a5bd1d09606115767daa99115bdR1660 use `Assembler::andn`. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1671: > 1669: void MacroAssembler::ornr(Register Rd, Register Rs1, Register Rs2) { > 1670: if (UseZbb) { > 1671: orn(Rd, Rs1, Rs2); Same as above. src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4033: > 4031: Register rtmp1, Register rtmp2, Register rmask32) { > 4032: // rtmp1 = c ^ (b | (~d)) > 4033: __ ornr(rtmp2, b, d); Nit: You could use `rtmp1` here, the dependency for the next instruction will block the CPU from executing OOO anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15156#discussion_r1284499778 PR Review Comment: https://git.openjdk.org/jdk/pull/15156#discussion_r1284502509 PR Review Comment: https://git.openjdk.org/jdk/pull/15156#discussion_r1284504036 From bulasevich at openjdk.org Fri Aug 4 14:38:14 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 4 Aug 2023 14:38:14 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v3] In-Reply-To: References: Message-ID: > This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 > > The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. > > InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: > > > Cortex-A53 (Pi 3 Model B Rev 1.2) > > test1stInt2Types 37.5 37.358 0.38 > test1stInt3Types 160.166 148.04 8.19 > test1stInt5Types 158.131 147.955 6.88 > test2ndInt2Types 52.634 53.291 -1.23 > test2ndInt3Types 201.39 181.603 10.90 > test2ndInt5Types 195.722 176.707 10.76 > testIfaceCall 157.453 140.498 12.07 > testIfaceExtCall 175.46 154.351 13.68 > testMonomorphic 32.052 32.039 0.04 > AVG: 6.85 > > Cortex-A72 (Pi 4 Model B Rev 1.2) > > test1stInt2Types 27.4796 27.4738 0.02 > test1stInt3Types 66.0085 64.9374 1.65 > test1stInt5Types 67.9812 66.2316 2.64 > test2ndInt2Types 32.0581 32.062 -0.01 > test2ndInt3Types 68.2715 65.6643 3.97 > test2ndInt5Types 68.1012 65.8024 3.49 > testIfaceCall 64.0684 64.1811 -0.18 > testIfaceExtCall 91.6226 81.5867 12.30 > testMonomorphic 26.7161 26.7142 0.01 > AVG: 2.66 > > Neoverse N1 (m6g.metal) > > test1stInt2Types 2.9104 2.9086 0.06 > test1stInt3Types 10.9642 10.2909 6.54 > test1stInt5Types 10.9607 10.2856 6.56 > test2ndInt2Types 3.3410 3.3478 -0.20 > test2ndInt3Types 12.3291 11.3089 9.02 > test2ndInt5Types 12.328 11.2704 9.38 > testIfaceCall 11.0598 10.3657 6.70 > testIfaceExtCall 13.0692 11.2826 15.84 > testMonomorphic 2.2354 2.2341 0.06 > AVG: 6.00 > > Neoverse V1 (c7g.2xlarge) > > test1stInt2Types 2.2317 2.2320 -0.01 > test1stInt3Types 6.6884 6.1911 8.03 > test1stInt5Types 6.7334 6.2193 8.27 > test2ndInt2Types 2.4002 2.4013 -0.04 > test2ndInt3Types 7.9603 7.0372 13.12 > test2ndInt5Types 7.9532 7.0474 12.85 > testIfaceCall 6.7028 6.3272 5.94 > testIfaceExtCall 8.3253 6.9416 19.93 > testMonomorphic 1.2446 1.2544 -0.79 > AVG: 7.48 > > > Testing... Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: rework loop_scan_resolved_entry cycle as proposed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13792/files - new: https://git.openjdk.org/jdk/pull/13792/files/16f6826a..7aa3f45f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=01-02 Stats: 18 lines in 1 file changed: 6 ins; 11 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13792/head:pull/13792 PR: https://git.openjdk.org/jdk/pull/13792 From matsaave at openjdk.org Fri Aug 4 14:39:55 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 4 Aug 2023 14:39:55 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v3] In-Reply-To: References: Message-ID: > The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Added asserts for flags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15126/files - new: https://git.openjdk.org/jdk/pull/15126/files/da649530..3a0ae21d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15126&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15126&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15126.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15126/head:pull/15126 PR: https://git.openjdk.org/jdk/pull/15126 From coleenp at openjdk.org Fri Aug 4 14:44:40 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 14:44:40 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code Message-ID: This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). int field_offset (int index) const { return field(index).offset(); } So when we get the field offset back, it's an int. Also stackwalker passes jlong, so made that consistent. Tested with tier1 on Oracle supported platforms. ------------- Commit messages: - Fix -Wconversion warnings in prims Changes: https://git.openjdk.org/jdk/pull/15160/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313785 Stats: 38 lines in 11 files changed: 6 ins; 0 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/15160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15160/head:pull/15160 PR: https://git.openjdk.org/jdk/pull/15160 From tonyp at openjdk.org Fri Aug 4 15:15:06 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Fri, 4 Aug 2023 15:15:06 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic [v2] In-Reply-To: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: > Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): > > before: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op > > > after: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op > > > (only line 3 is not an improvement, but it has higher variation) > > It seems to save around 5% of executed instructions. Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: changes based on code review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15156/files - new: https://git.openjdk.org/jdk/pull/15156/files/a15aaaac..d7d1cfee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15156&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15156&range=00-01 Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/15156.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15156/head:pull/15156 PR: https://git.openjdk.org/jdk/pull/15156 From tonyp at openjdk.org Fri Aug 4 15:15:06 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Fri, 4 Aug 2023 15:15:06 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic [v2] In-Reply-To: References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: On Fri, 4 Aug 2023 14:29:19 GMT, Ludovic Henry wrote: >> Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: >> >> changes based on code review feedback > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1658: > >> 1656: >> 1657: // Rd = Rs1 & (~Rd2) >> 1658: void MacroAssembler::andnr(Register Rd, Register Rs1, Register Rs2) { > > Keep the name `andn` here, and at https://github.com/openjdk/jdk/pull/15156/files#diff-7a5c3ed05b6f3f06ed1c59f5fc2a14ec566a6a5bd1d09606115767daa99115bdR1660 use `Assembler::andn`. Thanks. See updated patch. > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1671: > >> 1669: void MacroAssembler::ornr(Register Rd, Register Rs1, Register Rs2) { >> 1670: if (UseZbb) { >> 1671: orn(Rd, Rs1, Rs2); > > Same as above. Ditto. > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 4033: > >> 4031: Register rtmp1, Register rtmp2, Register rmask32) { >> 4032: // rtmp1 = c ^ (b | (~d)) >> 4033: __ ornr(rtmp2, b, d); > > Nit: You could use `rtmp1` here, the dependency for the next instruction will block the CPU from executing OOO anyway. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15156#discussion_r1284543374 PR Review Comment: https://git.openjdk.org/jdk/pull/15156#discussion_r1284543452 PR Review Comment: https://git.openjdk.org/jdk/pull/15156#discussion_r1284543541 From stuefe at openjdk.org Fri Aug 4 16:07:33 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 4 Aug 2023 16:07:33 GMT Subject: RFR: JDK-8310388: Shenandoah: Auxiliary bitmap is not madvised for THP [v2] In-Reply-To: References: <2KUO9EbhXSV-XrJFWWAY8KvDCDvkdQE7w8ew_MMzUEk=.3fc29a02-fa49-4b6a-8800-aab84525ba43@github.com> Message-ID: On Thu, 20 Jul 2023 16:39:47 GMT, Thomas Stuefe wrote: >> See details in JBS isse. >> >> Note that there is no actual functional difference. AUX bitmap did not use THPs before this patch and does not now either. The only difference is that before, the JVM *thought* the AUX bitmap uses THPs when in fact it did not. That caused confusion. >> >> (All this illuminates how badly thought out the ReservedSpace API really is. We pass in page size to the constructor, but then need to commit manually; THPs actually use madvise on commit, not on reservation, so we need to pass page size in *again* to commit. Ideally, ReservedSpace should handle committing for us with the page size it saved from reservation.) >> >> Note that this only takes care of preventing THP formation in "madvise" mode. In "always" mode, the kernel will do THP coalescation always. We could prevent it from doing so by advising against it via madvise, but that would require extension of the platform generic reservation APIs and is left for a different RFE. Ideally, nobody should use THP "always" mode. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Alekseys feedback Friendly ping... still need a second review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14953#issuecomment-1665854118 From duke at openjdk.org Fri Aug 4 16:27:50 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Fri, 4 Aug 2023 16:27:50 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v2] In-Reply-To: References: Message-ID: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: Change fsgnj_d(dst, src, src) to fmv_d(dst, src) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/ba609de3..1c43b040 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From matsaave at openjdk.org Fri Aug 4 17:05:55 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 4 Aug 2023 17:05:55 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v4] In-Reply-To: References: Message-ID: > The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: Changed field namnes to resolve error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15126/files - new: https://git.openjdk.org/jdk/pull/15126/files/3a0ae21d..143389e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15126&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15126&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15126.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15126/head:pull/15126 PR: https://git.openjdk.org/jdk/pull/15126 From ogillespie at openjdk.org Fri Aug 4 17:14:29 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Fri, 4 Aug 2023 17:14:29 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup In-Reply-To: References: Message-ID: <4goKdThu-NvMcJucaj0IFvXs68j4x2fJIH05kasRuCw=.1129cee0-1138-4b4c-b718-0f3328c6edc8@github.com> On Thu, 3 Aug 2023 11:21:27 GMT, Oli Gillespie wrote: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Thanks :) I'll be interested to hear what you think - I'm open to any suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1665936836 From coleenp at openjdk.org Fri Aug 4 17:32:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 17:32:31 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v4] In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:05:55 GMT, Matias Saavedra Silva wrote: >> The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Changed field namnes to resolve error This looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15126#pullrequestreview-1563298572 From sspitsyn at openjdk.org Fri Aug 4 18:13:30 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 4 Aug 2023 18:13:30 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: Message-ID: <4KZv-vY4ljZFSr8K6dQihGCAX6Jq72pITjTfXBCSWo0=.54ef5264-c92b-4da2-a3b4-9b2f5324ada3@github.com> On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. Looks good. Thanks, Serguei src/hotspot/share/prims/unsafe.cpp line 111: > 109: } > 110: > 111: static inline int field_offset_from_byte_offset(int byte_offset) { Nit: I wonder if the same fix is needed for the previous function at line 107 to make it consistent. But I guess there is no warning related to it. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15160#pullrequestreview-1563348546 PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284714469 From duke at openjdk.org Fri Aug 4 18:33:36 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Fri, 4 Aug 2023 18:33:36 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: References: <5RAZrov0Ss7Is1OMYjzZ78srasN_9rGQcoq-KaYu2aE=.ae10565f-fb5c-4def-b145-22363ec0fc7d@github.com> Message-ID: On Thu, 3 Aug 2023 15:59:14 GMT, Chris Plummer wrote: >> @ashu-mehra thanks for doing the additional testing. Pity there is no regression/functional test for this. > >> @dholmes-ora @plummercj I have improved [dumpclass tests](https://github.com/openjdk/jdk/commit/97618cc9bbadce4b51fc0fbee93557f4dcc8d26a) to cover up some cases for this PR and [JDK-8311971](https://bugs.openjdk.org/browse/JDK-8311971). If the tests makes sense I would like to include it in this PR. Is that okay? > > I think given the scope of the changes it would be better to do this with a "Improve SA dumpclass testing" CR/PR. @plummercj can you please sponsor it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15005#issuecomment-1666023204 From kdnilsen at openjdk.org Fri Aug 4 18:38:32 2023 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 4 Aug 2023 18:38:32 GMT Subject: RFR: JDK-8310388: Shenandoah: Auxiliary bitmap is not madvised for THP [v2] In-Reply-To: References: <2KUO9EbhXSV-XrJFWWAY8KvDCDvkdQE7w8ew_MMzUEk=.3fc29a02-fa49-4b6a-8800-aab84525ba43@github.com> Message-ID: On Thu, 20 Jul 2023 16:39:47 GMT, Thomas Stuefe wrote: >> See details in JBS isse. >> >> Note that there is no actual functional difference. AUX bitmap did not use THPs before this patch and does not now either. The only difference is that before, the JVM *thought* the AUX bitmap uses THPs when in fact it did not. That caused confusion. >> >> (All this illuminates how badly thought out the ReservedSpace API really is. We pass in page size to the constructor, but then need to commit manually; THPs actually use madvise on commit, not on reservation, so we need to pass page size in *again* to commit. Ideally, ReservedSpace should handle committing for us with the page size it saved from reservation.) >> >> Note that this only takes care of preventing THP formation in "madvise" mode. In "always" mode, the kernel will do THP coalescation always. We could prevent it from doing so by advising against it via madvise, but that would require extension of the platform generic reservation APIs and is left for a different RFE. Ideally, nobody should use THP "always" mode. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Alekseys feedback Looks good to me. ------------- Marked as reviewed by kdnilsen (no project role). PR Review: https://git.openjdk.org/jdk/pull/14953#pullrequestreview-1563376599 From cjplummer at openjdk.org Fri Aug 4 18:39:32 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 4 Aug 2023 18:39:32 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 09:59:41 GMT, Matthias Baesken wrote: > There is coding e.g. in > https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 > that deals with shared lib naming on different OS. > This code should be simplified. Changes requested by cjplummer (Reviewer). test/lib/jdk/test/lib/Platform.java line 376: > 374: } > 375: } > 376: The following tests could leverage this new API. Just look for calls to `Platform.sharedLibraryExt()`: test/hotspot/jtreg/runtime/signal/SigTestDriver.java test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeLibraryCopier.java test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java Perhaps a `Platform.buildSharedLibraryName()` API is worth considering. ------------- PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1563375724 PR Review Comment: https://git.openjdk.org/jdk/pull/15151#discussion_r1284731606 From stuefe at openjdk.org Fri Aug 4 18:42:43 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 4 Aug 2023 18:42:43 GMT Subject: RFR: JDK-8310388: Shenandoah: Auxiliary bitmap is not madvised for THP [v2] In-Reply-To: References: <2KUO9EbhXSV-XrJFWWAY8KvDCDvkdQE7w8ew_MMzUEk=.3fc29a02-fa49-4b6a-8800-aab84525ba43@github.com> Message-ID: On Thu, 20 Jul 2023 16:39:47 GMT, Thomas Stuefe wrote: >> See details in JBS isse. >> >> Note that there is no actual functional difference. AUX bitmap did not use THPs before this patch and does not now either. The only difference is that before, the JVM *thought* the AUX bitmap uses THPs when in fact it did not. That caused confusion. >> >> (All this illuminates how badly thought out the ReservedSpace API really is. We pass in page size to the constructor, but then need to commit manually; THPs actually use madvise on commit, not on reservation, so we need to pass page size in *again* to commit. Ideally, ReservedSpace should handle committing for us with the page size it saved from reservation.) >> >> Note that this only takes care of preventing THP formation in "madvise" mode. In "always" mode, the kernel will do THP coalescation always. We could prevent it from doing so by advising against it via madvise, but that would require extension of the platform generic reservation APIs and is left for a different RFE. Ideally, nobody should use THP "always" mode. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Alekseys feedback Thanks Kelvin! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14953#issuecomment-1666031278 From stuefe at openjdk.org Fri Aug 4 18:42:44 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 4 Aug 2023 18:42:44 GMT Subject: Integrated: JDK-8310388: Shenandoah: Auxiliary bitmap is not madvised for THP In-Reply-To: <2KUO9EbhXSV-XrJFWWAY8KvDCDvkdQE7w8ew_MMzUEk=.3fc29a02-fa49-4b6a-8800-aab84525ba43@github.com> References: <2KUO9EbhXSV-XrJFWWAY8KvDCDvkdQE7w8ew_MMzUEk=.3fc29a02-fa49-4b6a-8800-aab84525ba43@github.com> Message-ID: On Thu, 20 Jul 2023 11:19:53 GMT, Thomas Stuefe wrote: > See details in JBS isse. > > Note that there is no actual functional difference. AUX bitmap did not use THPs before this patch and does not now either. The only difference is that before, the JVM *thought* the AUX bitmap uses THPs when in fact it did not. That caused confusion. > > (All this illuminates how badly thought out the ReservedSpace API really is. We pass in page size to the constructor, but then need to commit manually; THPs actually use madvise on commit, not on reservation, so we need to pass page size in *again* to commit. Ideally, ReservedSpace should handle committing for us with the page size it saved from reservation.) > > Note that this only takes care of preventing THP formation in "madvise" mode. In "always" mode, the kernel will do THP coalescation always. We could prevent it from doing so by advising against it via madvise, but that would require extension of the platform generic reservation APIs and is left for a different RFE. Ideally, nobody should use THP "always" mode. This pull request has now been integrated. Changeset: 017e0c78 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/017e0c7850e305877e3e0b1d4644b5605225e07c Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod 8310388: Shenandoah: Auxiliary bitmap is not madvised for THP Reviewed-by: shade, kdnilsen ------------- PR: https://git.openjdk.org/jdk/pull/14953 From stuefe at openjdk.org Fri Aug 4 18:45:44 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 4 Aug 2023 18:45:44 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 22:12:28 GMT, Ashutosh Mehra wrote: > This patch adds NestHost and NestMembers attributes to the class dumped by SA. > > Testing: `test/hotspot/jtreg/serviceability/sa` and `test/jdk/sun/tools/jhsdb` > Manual testing by dumping `j.l.String` and `j.l.String$CaseInsensitiveComparator` classes. > `j.l.String` shows one entry in `NestMembers` attribute for `j.l.String$CaseInsensitiveComparator` and `j.l.String$CaseInsensitiveComparator` has `j.l.String` as its `NestHost`. Belatedly, and unnecessary since you have two reviews, but this looks good to me too. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15005#pullrequestreview-1563382820 From duke at openjdk.org Fri Aug 4 18:45:44 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Fri, 4 Aug 2023 18:45:44 GMT Subject: Integrated: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 22:12:28 GMT, Ashutosh Mehra wrote: > This patch adds NestHost and NestMembers attributes to the class dumped by SA. > > Testing: `test/hotspot/jtreg/serviceability/sa` and `test/jdk/sun/tools/jhsdb` > Manual testing by dumping `j.l.String` and `j.l.String$CaseInsensitiveComparator` classes. > `j.l.String` shows one entry in `NestMembers` attribute for `j.l.String$CaseInsensitiveComparator` and `j.l.String$CaseInsensitiveComparator` has `j.l.String` as its `NestHost`. This pull request has now been integrated. Changeset: 873d1179 Author: Ashutosh Mehra Committer: Chris Plummer URL: https://git.openjdk.org/jdk/commit/873d11793211717c37c6c72c80a76d1472c64c8a Stats: 50 lines in 3 files changed: 50 ins; 0 del; 0 mod 8312623: SA add NestHost and NestMembers attributes when dumping class Reviewed-by: cjplummer, sspitsyn, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/15005 From duke at openjdk.org Fri Aug 4 18:51:39 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Fri, 4 Aug 2023 18:51:39 GMT Subject: RFR: 8312623: SA add NestHost and NestMembers attributes when dumping class In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 22:12:28 GMT, Ashutosh Mehra wrote: > This patch adds NestHost and NestMembers attributes to the class dumped by SA. > > Testing: `test/hotspot/jtreg/serviceability/sa` and `test/jdk/sun/tools/jhsdb` > Manual testing by dumping `j.l.String` and `j.l.String$CaseInsensitiveComparator` classes. > `j.l.String` shows one entry in `NestMembers` attribute for `j.l.String$CaseInsensitiveComparator` and `j.l.String$CaseInsensitiveComparator` has `j.l.String` as its `NestHost`. Thanks every one for reviewing this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15005#issuecomment-1666039907 From clanger at openjdk.org Fri Aug 4 19:12:37 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 4 Aug 2023 19:12:37 GMT Subject: RFR: 8313795: Fix for JDK-8313564 breaks ppc and s390x builds Message-ID: The fix for JDK-8313564 breaks the ppc and s390x builds. This should repair it. ------------- Commit messages: - JDK-8313795 Changes: https://git.openjdk.org/jdk/pull/15165/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15165&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313795 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15165/head:pull/15165 PR: https://git.openjdk.org/jdk/pull/15165 From clanger at openjdk.org Fri Aug 4 19:12:37 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 4 Aug 2023 19:12:37 GMT Subject: RFR: 8313795: Fix for JDK-8313564 breaks ppc and s390x builds In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 19:05:43 GMT, Christoph Langer wrote: > The fix for JDK-8313564 breaks the ppc and s390x builds. This should repair it. Ping @coleenp ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15165#issuecomment-1666056869 From stuefe at openjdk.org Fri Aug 4 19:26:31 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 4 Aug 2023 19:26:31 GMT Subject: RFR: 8313795: Fix for JDK-8313564 breaks ppc and s390x builds In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 19:05:43 GMT, Christoph Langer wrote: > The fix for JDK-8313564 breaks the ppc and s390x builds. This should repair it. Looks good and trivial. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15165#pullrequestreview-1563452311 From coleenp at openjdk.org Fri Aug 4 19:30:33 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 19:30:33 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. Thanks for reviewing, Serguei. ------------- PR Review: https://git.openjdk.org/jdk/pull/15160#pullrequestreview-1563456331 From coleenp at openjdk.org Fri Aug 4 19:30:35 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Aug 2023 19:30:35 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: <4KZv-vY4ljZFSr8K6dQihGCAX6Jq72pITjTfXBCSWo0=.54ef5264-c92b-4da2-a3b4-9b2f5324ada3@github.com> References: <4KZv-vY4ljZFSr8K6dQihGCAX6Jq72pITjTfXBCSWo0=.54ef5264-c92b-4da2-a3b4-9b2f5324ada3@github.com> Message-ID: On Fri, 4 Aug 2023 18:10:30 GMT, Serguei Spitsyn wrote: >> This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). >> int field_offset (int index) const { return field(index).offset(); } >> >> So when we get the field offset back, it's an int. >> >> Also stackwalker passes jlong, so made that consistent. >> >> Tested with tier1 on Oracle supported platforms. > > src/hotspot/share/prims/unsafe.cpp line 111: > >> 109: } >> 110: >> 111: static inline int field_offset_from_byte_offset(int byte_offset) { > > Nit: I wonder if the same fix is needed for the previous function at line 107 to make it consistent. > But I guess there is no warning related to it. The names look almost the same, but field_offset_to_byte_offset() is called primarily passing jlong in several places so changing that would have had more fan out (and might not have been correct). The callers of field_offset_from_byte_offset() had callers that passed int and expected int returns, so that's why I changed only that one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284776327 From lmesnik at openjdk.org Fri Aug 4 19:45:56 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 4 Aug 2023 19:45:56 GMT Subject: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v3] In-Reply-To: References: Message-ID: <9_aaKm7wC_9cQH2qHKbb5myvx7roacZJVzWRLZ8NdQM=.6dc482e0-c215-4a1b-b84a-d819f0ee3979@github.com> > The fix adds posting VmObjectAlloc events by Unsafe.allocateInstance(Class cls). The previous attempt to post event directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance regression even if jvmti event is not enabled. Some optimizations have been disabled just because possible usage and escaping of newly allocated object. > So event posting is doing by returning to interpreter if events are enabled. > > I verified that that performance (run locally only) of > org.renaissance.jdk.streams.JmhScrabble.runOperation > doesn't change if events are not enabled. > > There might be other intrinsics like 'LibraryCallKit::inline_unsafe_newArray()' where VM allocate memory. I'm going to file separate issue to find and fix them. > > Many thanks to Tobias H. for proposed solution. > > Testing with all tiers. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: The too many deopts check should be first. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15110/files - new: https://git.openjdk.org/jdk/pull/15110/files/5095114f..64871b91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15110&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15110&range=01-02 Stats: 13 lines in 1 file changed: 7 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15110/head:pull/15110 PR: https://git.openjdk.org/jdk/pull/15110 From dlong at openjdk.org Fri Aug 4 19:49:33 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 19:49:33 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v4] In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:05:55 GMT, Matias Saavedra Silva wrote: >> The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > Changed field namnes to resolve error Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15126#pullrequestreview-1563476373 From azafari at openjdk.org Fri Aug 4 19:59:39 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 4 Aug 2023 19:59:39 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp Message-ID: The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. ### Tests tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug tier1 all passed. ------------- Commit messages: - Fixed intx->int for Wconversion warnings. Changes: https://git.openjdk.org/jdk/pull/15164/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308850 Stats: 19 lines in 5 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/15164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15164/head:pull/15164 PR: https://git.openjdk.org/jdk/pull/15164 From matsaave at openjdk.org Fri Aug 4 20:27:40 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 4 Aug 2023 20:27:40 GMT Subject: RFR: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry [v4] In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:29:36 GMT, Coleen Phillimore wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed field namnes to resolve error > > This looks good. Thank you for the reviews @coleenp, @dean-long, and @dholmes-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15126#issuecomment-1666133646 From matsaave at openjdk.org Fri Aug 4 20:27:42 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 4 Aug 2023 20:27:42 GMT Subject: Integrated: 8313554: Fix -Wconversion warnings for ResolvedFieldEntry In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 19:15:24 GMT, Matias Saavedra Silva wrote: > The recent change in [JDK-8301996](https://bugs.openjdk.org/browse/JDK-8301996) added more -Wconversion warnings that are addressed in this patch. The aforementioned change has overlooked inconsistencies with the types used by `ResolvedFieldEntry` and the method `fill_in()`. Verified with tier 1-4 tests. This pull request has now been integrated. Changeset: ad6e9e75 Author: Matias Saavedra Silva URL: https://git.openjdk.org/jdk/commit/ad6e9e75bff24e74c888d9b96c3f698ae0f54127 Stats: 12 lines in 3 files changed: 4 ins; 0 del; 8 mod 8313554: Fix -Wconversion warnings for ResolvedFieldEntry Reviewed-by: coleenp, dlong ------------- PR: https://git.openjdk.org/jdk/pull/15126 From sspitsyn at openjdk.org Fri Aug 4 20:32:31 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 4 Aug 2023 20:32:31 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: <4KZv-vY4ljZFSr8K6dQihGCAX6Jq72pITjTfXBCSWo0=.54ef5264-c92b-4da2-a3b4-9b2f5324ada3@github.com> Message-ID: On Fri, 4 Aug 2023 19:27:50 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/unsafe.cpp line 111: >> >>> 109: } >>> 110: >>> 111: static inline int field_offset_from_byte_offset(int byte_offset) { >> >> Nit: I wonder if the same fix is needed for the previous function at line 107 to make it consistent. >> But I guess there is no warning related to it. > > The names look almost the same, but field_offset_to_byte_offset() is called primarily passing jlong in several places so changing that would have had more fan out (and might not have been correct). > The callers of field_offset_from_byte_offset() had callers that passed int and expected int returns, so that's why I changed only that one. Okay, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284824110 From sspitsyn at openjdk.org Fri Aug 4 20:39:30 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 4 Aug 2023 20:39:30 GMT Subject: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v3] In-Reply-To: <9_aaKm7wC_9cQH2qHKbb5myvx7roacZJVzWRLZ8NdQM=.6dc482e0-c215-4a1b-b84a-d819f0ee3979@github.com> References: <9_aaKm7wC_9cQH2qHKbb5myvx7roacZJVzWRLZ8NdQM=.6dc482e0-c215-4a1b-b84a-d819f0ee3979@github.com> Message-ID: On Fri, 4 Aug 2023 19:45:56 GMT, Leonid Mesnik wrote: >> The fix adds posting VmObjectAlloc events by Unsafe.allocateInstance(Class cls). The previous attempt to post event directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance regression even if jvmti event is not enabled. Some optimizations have been disabled just because possible usage and escaping of newly allocated object. >> So event posting is doing by returning to interpreter if events are enabled. >> >> I verified that that performance (run locally only) of >> org.renaissance.jdk.streams.JmhScrabble.runOperation >> doesn't change if events are not enabled. >> >> There might be other intrinsics like 'LibraryCallKit::inline_unsafe_newArray()' where VM allocate memory. I'm going to file separate issue to find and fix them. >> >> Many thanks to Tobias H. for proposed solution. >> >> Testing with all tiers. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > The too many deopts check should be first. This looks okay to me. It needs to be reviewed by someone from the compiler team. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15110#pullrequestreview-1563532886 From clanger at openjdk.org Fri Aug 4 20:53:30 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 4 Aug 2023 20:53:30 GMT Subject: RFR: 8313795: Fix for JDK-8313564 breaks ppc and s390x builds In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 19:05:43 GMT, Christoph Langer wrote: > The fix for JDK-8313564 breaks the ppc and s390x builds. This should repair it. Thanks Thomas. Will integrate when GHA is through and confirms that the patch works. Luckily, the cross-build should be repaired by now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15165#issuecomment-1666167255 From sspitsyn at openjdk.org Fri Aug 4 20:59:27 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 4 Aug 2023 20:59:27 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 18:34:52 GMT, Chris Plummer wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > test/lib/jdk/test/lib/Platform.java line 376: > >> 374: } >> 375: } >> 376: > > The following tests could leverage this new API. Just look for calls to `Platform.sharedLibraryExt()`: > > test/hotspot/jtreg/runtime/signal/SigTestDriver.java > test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeLibraryCopier.java > test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java > > Perhaps a `Platform.buildSharedLibraryName()` API is worth considering. The fix looks good in general. But I like the suggestion from Chris above ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15151#discussion_r1284840135 From dlong at openjdk.org Fri Aug 4 21:13:31 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 21:13:31 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. src/hotspot/share/prims/jni.cpp line 209: > 207: > 208: > 209: intptr_t jfieldIDWorkaround::encode_klass_hash(Klass* k, intptr_t offset) { The caller always passes an int, so why not change the parameter to int? Suggestion: intptr_t jfieldIDWorkaround::encode_klass_hash(Klass* k, int offset) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284851860 From dlong at openjdk.org Fri Aug 4 21:58:29 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 21:58:29 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. src/hotspot/share/prims/jni.cpp line 1906: > 1904: o = JvmtiExport::jni_SetField_probe(thread, obj, o, k, fieldID, false, SigType, (jvalue *)&field_value); \ > 1905: } \ > 1906: if (SigType == JVM_SIGNATURE_BOOLEAN) { value = (Argument)(((jboolean)value) & 1); } \ This is already done in bool_field_put(), so it is redundant here. I think it can be safely removed. src/hotspot/share/prims/jni.cpp line 2099: > 2097: JvmtiExport::jni_SetField_probe(thread, nullptr, nullptr, id->holder(), fieldID, true, SigType, (jvalue *)&field_value); \ > 2098: } \ > 2099: if (SigType == JVM_SIGNATURE_BOOLEAN) { value = (Argument)(((jboolean)value) & 1); } \ Same as above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284873690 PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284873793 From dlong at openjdk.org Fri Aug 4 22:04:29 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 22:04:29 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: Message-ID: <4QzZ_UPEST8laP_iDiNcVFaiKqWpRweIjLDy9CBcai4=.88c94ba4-1c59-404a-acae-f209c260309b@github.com> On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. src/hotspot/share/prims/jvm.cpp line 612: > 610: // as implemented in the classic virtual machine; return 0 if object is null > 611: return handle == nullptr ? 0 : > 612: checked_cast(ObjectSynchronizer::FastHashCode (THREAD, JNIHandles::resolve_non_null(handle))); What about making FastHashCode return jint? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284876719 From dlong at openjdk.org Fri Aug 4 22:22:31 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 22:22:31 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. src/hotspot/share/prims/methodHandles.cpp line 910: > 908: InstanceKlass* defc = InstanceKlass::cast(java_lang_Class::as_Klass(clazz)); > 909: DEBUG_ONLY(clazz = nullptr); // safety > 910: intptr_t vmindex = java_lang_invoke_MemberName::vmindex(mname()); Why not do the checked_cast here instead of below? Ideally, the vmindex field would be changed to int (field offsets, itable/vtable indexes are all int), but that's more work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284883812 From dlong at openjdk.org Fri Aug 4 22:35:33 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 22:35:33 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15160#pullrequestreview-1563625051 From clanger at openjdk.org Fri Aug 4 22:36:38 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 4 Aug 2023 22:36:38 GMT Subject: RFR: 8313795: Fix for JDK-8313564 breaks ppc and s390x builds In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 19:05:43 GMT, Christoph Langer wrote: > The fix for JDK-8313564 breaks the ppc and s390x builds. This should repair it. GHA looks good. Integrating to unbreak builds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15165#issuecomment-1666239832 From clanger at openjdk.org Fri Aug 4 22:36:39 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 4 Aug 2023 22:36:39 GMT Subject: Integrated: 8313795: Fix for JDK-8313564 breaks ppc and s390x builds In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 19:05:43 GMT, Christoph Langer wrote: > The fix for JDK-8313564 breaks the ppc and s390x builds. This should repair it. This pull request has now been integrated. Changeset: 6d185296 Author: Christoph Langer URL: https://git.openjdk.org/jdk/commit/6d185296161606edbc9f737a6b1b27496add9367 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8313795: Fix for JDK-8313564 breaks ppc and s390x builds Reviewed-by: stuefe ------------- PR: https://git.openjdk.org/jdk/pull/15165 From dlong at openjdk.org Fri Aug 4 22:50:33 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 22:50:33 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari wrote: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. src/hotspot/share/opto/macro.cpp line 1841: > 1839: // Generate several prefetch instructions. > 1840: int step_size = AllocatePrefetchStepSize; > 1841: int distance = AllocatePrefetchDistance; I think this is a step in the wrong direction. Shouldn't these remain uint? src/hotspot/share/runtime/globals.hpp line 1258: > 1256: range(1, 64) \ > 1257: \ > 1258: product(int, AllocatePrefetchStepSize, 16, \ I feel like uint is more correct for most of these. src/hotspot/share/runtime/globals.hpp line 1590: > 1588: "switch") \ > 1589: \ > 1590: develop(int, StopInterpreterAt, 0, \ Some cpu ports access this from assembly, so changing the size is gong to require cpu-specific changes. I'd rather see this and BytecodeCounter::_counter_value both changed to uint64_t. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1284893943 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1284894485 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1284893634 From dlong at openjdk.org Fri Aug 4 22:54:30 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 4 Aug 2023 22:54:30 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari wrote: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. I know HotSpot code is not very careful about distinguishing between int and uint, but shouldn't we prefer uint for values that can't be negative? The disadvantage of uint though is will we get more -Wsign-conversion warnings to fix when that warning gets turned on. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1666252138 From luhenry at openjdk.org Sat Aug 5 12:19:44 2023 From: luhenry at openjdk.org (Ludovic Henry) Date: Sat, 5 Aug 2023 12:19:44 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic [v2] In-Reply-To: References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: <9GfgygtqCJYU_2RVqttNTV4W4yl5q5NwC5C7gvQN6jc=.6b6be170-3d6e-4d89-a5ad-194d2f011654@github.com> On Fri, 4 Aug 2023 15:15:06 GMT, Antonios Printezis wrote: >> Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): >> >> before: >> >> >> MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op >> MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op >> MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op >> MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op >> >> >> after: >> >> >> MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op >> MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op >> MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op >> MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op >> >> >> (only line 3 is not an improvement, but it has higher variation) >> >> It seems to save around 5% of executed instructions. > > Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: > > changes based on code review feedback Marked as reviewed by luhenry (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15156#pullrequestreview-1563888732 From coleenp at openjdk.org Sat Aug 5 16:21:57 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 5 Aug 2023 16:21:57 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code [v2] In-Reply-To: References: Message-ID: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Dean's suggested changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15160/files - new: https://git.openjdk.org/jdk/pull/15160/files/a693cc38..07304dd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15160&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15160&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15160/head:pull/15160 PR: https://git.openjdk.org/jdk/pull/15160 From coleenp at openjdk.org Sat Aug 5 16:21:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 5 Aug 2023 16:21:59 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code [v2] In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 21:11:05 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Dean's suggested changes. > > src/hotspot/share/prims/jni.cpp line 209: > >> 207: >> 208: >> 209: intptr_t jfieldIDWorkaround::encode_klass_hash(Klass* k, intptr_t offset) { > > The caller always passes an int, so why not change the parameter to int? > Suggestion: > > intptr_t jfieldIDWorkaround::encode_klass_hash(Klass* k, int offset) { Ok. That's a good suggestion. > src/hotspot/share/prims/jni.cpp line 1906: > >> 1904: o = JvmtiExport::jni_SetField_probe(thread, obj, o, k, fieldID, false, SigType, (jvalue *)&field_value); \ >> 1905: } \ >> 1906: if (SigType == JVM_SIGNATURE_BOOLEAN) { value = (Argument)(((jboolean)value) & 1); } \ > > This is already done in bool_field_put(), so it is redundant here. I think it can be safely removed. It is, you're right. I'm going to rerun the tests because this is an unrelated change. > src/hotspot/share/prims/jvm.cpp line 612: > >> 610: // as implemented in the classic virtual machine; return 0 if object is null >> 611: return handle == nullptr ? 0 : >> 612: checked_cast(ObjectSynchronizer::FastHashCode (THREAD, JNIHandles::resolve_non_null(handle))); > > What about making FastHashCode return jint? I briefly had a look at that but that's a bit more fan-out from code in synchronizer.cpp and other callers. > src/hotspot/share/prims/methodHandles.cpp line 910: > >> 908: InstanceKlass* defc = InstanceKlass::cast(java_lang_Class::as_Klass(clazz)); >> 909: DEBUG_ONLY(clazz = nullptr); // safety >> 910: intptr_t vmindex = java_lang_invoke_MemberName::vmindex(mname()); > > Why not do the checked_cast here instead of below? > Ideally, the vmindex field would be changed to int (field offsets, itable/vtable indexes are all int), but that's more work. Why not? It's the same and casts the int where it's needed to be an int. It would be a bigger change to make this an int. Not that big because it's an injected field but too much extra for this change. I had a look at this and it affects platform code non-trivially. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284901764 PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284903411 PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284899851 PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1284905530 From coleenp at openjdk.org Sat Aug 5 16:24:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 5 Aug 2023 16:24:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari wrote: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. The argument checking code gives a nice error if you pass a negative value for a parameter in the range of 0 .. positive-number if the argument is an int, and a bad one if the argument is uint. That's why in previous changes, I've preferred changing to int. We could file an RFE to improve the error message though. I don't know how hard that would be to fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1666545492 From coleenp at openjdk.org Sat Aug 5 16:24:30 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 5 Aug 2023 16:24:30 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 22:44:49 GMT, Dean Long wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > src/hotspot/share/runtime/globals.hpp line 1590: > >> 1588: "switch") \ >> 1589: \ >> 1590: develop(int, StopInterpreterAt, 0, \ > > Some cpu ports access this from assembly, so changing the size is gong to require cpu-specific changes. I'd rather see this and BytecodeCounter::_counter_value both changed to uint64_t. share/interpreter/bytecodeHistogram.cpp:int BytecodeCounter::_counter_value = 0; Maybe this should be inx instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285083024 From fyang at openjdk.org Sun Aug 6 02:41:30 2023 From: fyang at openjdk.org (Fei Yang) Date: Sun, 6 Aug 2023 02:41:30 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic [v2] In-Reply-To: References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: <42Pr0SQVU4sxSwdMxE9QsH0t2a2zGjwAoAO351DpLqc=.269631b5-dfcd-4a2d-a5bf-63ef0622209d@github.com> On Fri, 4 Aug 2023 15:15:06 GMT, Antonios Printezis wrote: >> Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): >> >> before: >> >> >> MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op >> MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op >> MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op >> MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op >> >> >> after: >> >> >> MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op >> MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op >> MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op >> MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op >> >> >> (only line 3 is not an improvement, but it has higher variation) >> >> It seems to save around 5% of executed instructions. > > Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: > > changes based on code review feedback Looks good. BTW: I noticed that two `li` are used in your previous PR to implement MD5 intrinsic: ./stubGenerator_riscv.cpp: __ li(rtmp2, t); ./stubGenerator_riscv.cpp: __ li(rmask32, MASK_32); I think It should be more consistent if you use 'mv' instead as we did in other places when moving an immediate into register. template::value)> inline void mv(Register Rd, T o) { li(Rd, (int64_t)o); } ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15156#pullrequestreview-1564049901 From aturbanov at openjdk.org Sun Aug 6 09:34:38 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sun, 6 Aug 2023 09:34:38 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 06:29:28 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo > > Signed-off-by: Sidraya src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 112: > 110: } > 111: > 112: public static MethodHandle arrangeDowncall(MethodType mt, FunctionDescriptor cDesc, LinkerOptions options) { Suggestion: public static MethodHandle arrangeDowncall(MethodType mt, FunctionDescriptor cDesc, LinkerOptions options) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1285183843 From jwaters at openjdk.org Mon Aug 7 02:29:31 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 02:29:31 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: <9xaGezLeGvAidlgYkB0HaobJkvqbTi13FlUQT8H55Bg=.16175e10-1289-40e7-91cd-e73e89a739de@github.com> On Fri, 28 Jul 2023 09:33:45 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> zPhysicalMemoryBacking_windows.cpp > > src/hotspot/share/code/codeHeapState.cpp line 1387: > >> 1385: " occupied space) is used by the blocks in the given size range.\n" >> 1386: " %ld characters are printed per percentage point.\n", pctFactor/100); >> 1387: ast->print_cr("total size of all blocks: " INT64_FORMAT_W(7) "M", (total_size< > Wrong for 32-bit platforms. I don't quite know what to do here, since on platforms where long < size_t (which in practice is probably just 32 bit or Windows) this division will promote to the type of size_t, which is likely 64 bits in size, but unfortunately %zd cannot be used here since the promotion only happens on said platforms where long < size_t, which will trip a compilation breaking warning on platforms where sizeof long is sizeof size_t, which is probably just 64 bit platforms that are not Windows ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1285324651 From dholmes at openjdk.org Mon Aug 7 02:40:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 02:40:33 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 22:45:58 GMT, Dean Long wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > src/hotspot/share/opto/macro.cpp line 1841: > >> 1839: // Generate several prefetch instructions. >> 1840: int step_size = AllocatePrefetchStepSize; >> 1841: int distance = AllocatePrefetchDistance; > > I think this is a step in the wrong direction. Shouldn't these remain uint? This change also doesn't fit the PR description. There is no need to change this in this PR (or even at all). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285309136 From dholmes at openjdk.org Mon Aug 7 02:40:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 02:40:34 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Sat, 5 Aug 2023 16:21:29 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/globals.hpp line 1590: >> >>> 1588: "switch") \ >>> 1589: \ >>> 1590: develop(int, StopInterpreterAt, 0, \ >> >> Some cpu ports access this from assembly, so changing the size is gong to require cpu-specific changes. I'd rather see this and BytecodeCounter::_counter_value both changed to uint64_t. > > share/interpreter/bytecodeHistogram.cpp:int BytecodeCounter::_counter_value = 0; > > Maybe this should be inx instead. The only reason to use `intx` is if this should be 32-bit on 32-bit and 64-bit on 64-bit. I don't think that is the case here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285312430 From dholmes at openjdk.org Mon Aug 7 02:40:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 02:40:31 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: <9jVcTomxlgxuotOMDSRY9JOkrKAQc4rFHbaG1ogMt8I=.f5761775-2196-4f20-a117-9fc4ed1c5894@github.com> On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari wrote: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. I think the basic change from `intx` to `int` is sound - there is no reason for these flags to have a different size depending on the platform. But you need to check any other references to these flags (e.g. printing) are changed appropriately. The issue of signed versus unsigned is a topic for a different day IMO. Thanks. src/hotspot/share/opto/macro.cpp line 1879: > 1877: // Generate several prefetch instructions. > 1878: int step_size = AllocatePrefetchStepSize; > 1879: int distance = AllocatePrefetchDistance; Ditto no need to change src/hotspot/share/runtime/globals.hpp line 1104: > 1102: "Collect information about IndexSets") \ > 1103: \ > 1104: develop(int, FastAllocateSizeLimit, 128*K, \ Ensure the value is either never printed or else the format specifier is updated accordingly. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1564442865 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285309321 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285309479 From dholmes at openjdk.org Mon Aug 7 03:59:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 03:59:29 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: <9xaGezLeGvAidlgYkB0HaobJkvqbTi13FlUQT8H55Bg=.16175e10-1289-40e7-91cd-e73e89a739de@github.com> References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> <9xaGezLeGvAidlgYkB0HaobJkvqbTi13FlUQT8H55Bg=.16175e10-1289-40e7-91cd-e73e89a739de@github.com> Message-ID: On Mon, 7 Aug 2023 02:27:07 GMT, Julian Waters wrote: >> src/hotspot/share/code/codeHeapState.cpp line 1387: >> >>> 1385: " occupied space) is used by the blocks in the given size range.\n" >>> 1386: " %ld characters are printed per percentage point.\n", pctFactor/100); >>> 1387: ast->print_cr("total size of all blocks: " INT64_FORMAT_W(7) "M", (total_size<> >> Wrong for 32-bit platforms. > > I don't quite know what to do here, since on platforms where long < size_t (which in practice is probably just 32 bit or Windows) this division will promote to the type of size_t, which is likely 64 bits in size, but unfortunately %zd cannot be used here since the promotion only happens on said platforms where long < size_t, which will trip a compilation breaking warning on platforms where sizeof long is sizeof size_t, which is probably just 64 bit platforms that are not Windows If we defer the issue of what type `total_size` should be and just keep it as `unsigned long` then the simple and correct fix would be to use `%7lu` would it not? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1285354581 From dholmes at openjdk.org Mon Aug 7 04:44:26 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 04:44:26 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 11:21:27 GMT, Oli Gillespie wrote: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Why does `equals` bump the ref count? That seems a very strange thing to do as there is no "opposing" operation that would decrement the ref count again. ??? ------------- PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1564535664 From dholmes at openjdk.org Mon Aug 7 05:56:41 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 05:56:41 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code [v2] In-Reply-To: References: Message-ID: <2a2RwBXrGa-NHvzQeY28LfSvFIf3nwCU4FvBhHC2HCU=.42455117-1b52-4d41-81ec-251e53733800@github.com> On Fri, 4 Aug 2023 23:06:54 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvm.cpp line 612: >> >>> 610: // as implemented in the classic virtual machine; return 0 if object is null >>> 611: return handle == nullptr ? 0 : >>> 612: checked_cast(ObjectSynchronizer::FastHashCode (THREAD, JNIHandles::resolve_non_null(handle))); >> >> What about making FastHashCode return jint? > > I briefly had a look at that but that's a bit more fan-out from code in synchronizer.cpp and other callers. I agree with Coleen, we use intptr_t all through the markWord code and we can't change all that (not that we would want to) so converting to jint before we leave the VM seems the best place to do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1285396390 From dholmes at openjdk.org Mon Aug 7 05:56:39 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 05:56:39 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code [v2] In-Reply-To: References: Message-ID: On Sat, 5 Aug 2023 16:21:57 GMT, Coleen Phillimore wrote: >> This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). >> int field_offset (int index) const { return field(index).offset(); } >> >> So when we get the field offset back, it's an int. >> >> Also stackwalker passes jlong, so made that consistent. >> >> Tested with tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Dean's suggested changes. Generally seems okay. However I don't think the stackwalk changes to use `jlong` are necessary or desirable: it seems a bug to me that the `mode` field is declared as `long` at the Java level, when it is always assigned from an int AFAICS. ------------- PR Review: https://git.openjdk.org/jdk/pull/15160#pullrequestreview-1564578956 From jwaters at openjdk.org Mon Aug 7 06:42:41 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 06:42:41 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: - Mismatched declaration in D3DGlyphCache.cpp - Fields in awt_TextComponent.cpp - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp - Qualifiers in awt_PrintDialog.h should be removed - Likewise for awt_DnDDT.cpp - awt_ole.h include order issue in awt_DnDDS.cpp - Revert awt_ole.h - Earlier fix in awt_ole.h was not complete - Merge branch 'openjdk:master' into patch-10 - Likewise for awt_Frame.cpp - ... and 12 more: https://git.openjdk.org/jdk/compare/6432a4e7...51230f3d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/8d8cb5aa..51230f3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=00-01 Stats: 5173 lines in 265 files changed: 2892 ins; 846 del; 1435 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Mon Aug 7 06:42:42 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 06:42:42 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 1 Aug 2023 01:52:24 GMT, Julian Waters wrote: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code That broken mismatched exception specifier in allocation.cpp has been annoying the absolute **** out of me for a long time now, feels good to see it go Ready for initial rounds of review ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1659458669 PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1667269318 From dholmes at openjdk.org Mon Aug 7 06:42:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 06:42:44 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:37:21 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/6432a4e7...51230f3d src/hotspot/os/windows/symbolengine.cpp line 114: > 112: _capacity = (int)(sizeof(_fallback_buffer) / sizeof(T)); > 113: } > 114: _p[0] = (T) '\0'; I find this use of `'\0'` quite suspicious in itself, but it is consistent with the use of `'X'` in `imprint_sentinel()`. I'm unclear what types are possible for `T` in this code. src/hotspot/share/memory/allocation.cpp line 114: > 112: // > 113: > 114: void* AnyObj::operator new(size_t size, Arena *arena) { Please remind us what the issue is with `throw()` as this is a change to shared code and it looks very inconsistent to remove it only for this one definition of `operator new`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1280259660 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1280260492 From jwaters at openjdk.org Mon Aug 7 06:42:44 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 06:42:44 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 1 Aug 2023 08:10:10 GMT, David Holmes wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: >> >> - Mismatched declaration in D3DGlyphCache.cpp >> - Fields in awt_TextComponent.cpp >> - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp >> - Qualifiers in awt_PrintDialog.h should be removed >> - Likewise for awt_DnDDT.cpp >> - awt_ole.h include order issue in awt_DnDDS.cpp >> - Revert awt_ole.h >> - Earlier fix in awt_ole.h was not complete >> - Merge branch 'openjdk:master' into patch-10 >> - Likewise for awt_Frame.cpp >> - ... and 12 more: https://git.openjdk.org/jdk/compare/6432a4e7...51230f3d > > src/hotspot/os/windows/symbolengine.cpp line 114: > >> 112: _capacity = (int)(sizeof(_fallback_buffer) / sizeof(T)); >> 113: } >> 114: _p[0] = (T) '\0'; > > I find this use of `'\0'` quite suspicious in itself, but it is consistent with the use of `'X'` in `imprint_sentinel()`. I'm unclear what types are possible for `T` in this code. There are currently only 2 possible types of HMODULE and char/uint8_t for T at the moment. Weirdly enough only line 126 errors out without the cast while line 114, despite having the same problem, doesn't, but I added the cast to both lines for consistency. If someone else knows why I could probably deal with this code in a better way besides just casting it to T (which I also am reluctant to do) > src/hotspot/share/memory/allocation.cpp line 114: > >> 112: // >> 113: >> 114: void* AnyObj::operator new(size_t size, Arena *arena) { > > Please remind us what the issue is with `throw()` as this is a change to shared code and it looks very inconsistent to remove it only for this one definition of `operator new`. Hi David, this throw was removed for this method's declaration in the corresponding hpp file in an earlier commit [8305590: Remove nothrow exception specifications from operator new](https://github.com/openjdk/jdk/commit/0f51e6326373ff7d4a4d9a0e3a2788401f73405d), but the Author forgot to remove the throw() from the definition as well (the error can be viewed in the GHA for the earlier versions of this PR). I believe gcc only errors on this in C++17 mode (for some weird reason) and not our current C++14 mode, which is why it gets a pass on other platforms ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1280269818 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1280267058 From dholmes at openjdk.org Mon Aug 7 06:45:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 06:45:32 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 20:55:25 GMT, Serguei Spitsyn wrote: >> test/lib/jdk/test/lib/Platform.java line 376: >> >>> 374: } >>> 375: } >>> 376: >> >> The following tests could leverage this new API. Just look for calls to `Platform.sharedLibraryExt()`: >> >> test/hotspot/jtreg/runtime/signal/SigTestDriver.java >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeLibraryCopier.java >> test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java >> >> Perhaps a `Platform.buildSharedLibraryName()` API is worth considering. > > The fix looks good in general. > But I like the suggestion from Chris above Agreed, I'd like to see `Platform.buildSharedLibraryName()` in addition to the other methods (the latter are needed if you want to decompose a filename to get the library name (though we could also provide a function just to do that). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15151#discussion_r1285438334 From dholmes at openjdk.org Mon Aug 7 06:47:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 06:47:29 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError and ciEnv [v2] In-Reply-To: References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: <-bDT01GHUmCo4DApZXGV2tN-4D68Hh-GiXITru9_jr0=.9bf7ab6f-bb61-4603-b9ed-2c5fa0584a5f@github.com> On Fri, 4 Aug 2023 07:02:02 GMT, Matthias Baesken wrote: >> In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. >> The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). >> >> However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. > > Matthias Baesken 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: > > - Adjust ciEnv.cpp and comment > - Merge remote-tracking branch 'origin/master' into JDK-8313691 > - JDK-8313691 Looks good. I'd missed the other PR initially. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15139#pullrequestreview-1564649791 From thartmann at openjdk.org Mon Aug 7 07:33:31 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 7 Aug 2023 07:33:31 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError and ciEnv [v2] In-Reply-To: References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: On Fri, 4 Aug 2023 07:02:02 GMT, Matthias Baesken wrote: >> In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. >> The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). >> >> However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. > > Matthias Baesken 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: > > - Adjust ciEnv.cpp and comment > - Merge remote-tracking branch 'origin/master' into JDK-8313691 > - JDK-8313691 All tests passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15139#issuecomment-1667338009 From dholmes at openjdk.org Mon Aug 7 08:04:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 08:04:32 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/8eae6324...51230f3d Hotspot and build changes seem okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15096#pullrequestreview-1564771081 From dholmes at openjdk.org Mon Aug 7 08:04:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Aug 2023 08:04:34 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 1 Aug 2023 08:16:41 GMT, Julian Waters wrote: >> src/hotspot/share/memory/allocation.cpp line 114: >> >>> 112: // >>> 113: >>> 114: void* AnyObj::operator new(size_t size, Arena *arena) { >> >> Please remind us what the issue is with `throw()` as this is a change to shared code and it looks very inconsistent to remove it only for this one definition of `operator new`. > > Hi David, this throw was removed for this method's declaration in the corresponding hpp file in an earlier commit [8305590: Remove nothrow exception specifications from operator new](https://github.com/openjdk/jdk/commit/0f51e6326373ff7d4a4d9a0e3a2788401f73405d), but the Author forgot to remove the throw() from the definition as well (the error can be viewed in the GHA for the earlier versions of this PR). I believe gcc only errors on this in C++17 mode (for some weird reason) and not our current C++14 mode, which is why it gets a pass on other platforms Thanks for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1285518812 From jwaters at openjdk.org Mon Aug 7 08:08:35 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 08:08:35 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <1RputHpTgH5gDU5TObp5N87AyeOiyCQ6WLM1PTfCyk4=.3004faa1-36e0-4f6c-9909-519d598ea823@github.com> On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/27f60d75...51230f3d Setting reviewers required to 4 for each subcomponent ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1667390881 From bulasevich at openjdk.org Mon Aug 7 08:11:59 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 08:11:59 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v4] In-Reply-To: References: Message-ID: > This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 > > The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. > > InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: > > > Cortex-A53 (Pi 3 Model B Rev 1.2) > > test1stInt2Types 37.5 37.358 0.38 > test1stInt3Types 160.166 148.04 8.19 > test1stInt5Types 158.131 147.955 6.88 > test2ndInt2Types 52.634 53.291 -1.23 > test2ndInt3Types 201.39 181.603 10.90 > test2ndInt5Types 195.722 176.707 10.76 > testIfaceCall 157.453 140.498 12.07 > testIfaceExtCall 175.46 154.351 13.68 > testMonomorphic 32.052 32.039 0.04 > AVG: 6.85 > > Cortex-A72 (Pi 4 Model B Rev 1.2) > > test1stInt2Types 27.4796 27.4738 0.02 > test1stInt3Types 66.0085 64.9374 1.65 > test1stInt5Types 67.9812 66.2316 2.64 > test2ndInt2Types 32.0581 32.062 -0.01 > test2ndInt3Types 68.2715 65.6643 3.97 > test2ndInt5Types 68.1012 65.8024 3.49 > testIfaceCall 64.0684 64.1811 -0.18 > testIfaceExtCall 91.6226 81.5867 12.30 > testMonomorphic 26.7161 26.7142 0.01 > AVG: 2.66 > > Neoverse N1 (m6g.metal) > > test1stInt2Types 2.9104 2.9086 0.06 > test1stInt3Types 10.9642 10.2909 6.54 > test1stInt5Types 10.9607 10.2856 6.56 > test2ndInt2Types 3.3410 3.3478 -0.20 > test2ndInt3Types 12.3291 11.3089 9.02 > test2ndInt5Types 12.328 11.2704 9.38 > testIfaceCall 11.0598 10.3657 6.70 > testIfaceExtCall 13.0692 11.2826 15.84 > testMonomorphic 2.2354 2.2341 0.06 > AVG: 6.00 > > Neoverse V1 (c7g.2xlarge) > > test1stInt2Types 2.2317 2.2320 -0.01 > test1stInt3Types 6.6884 6.1911 8.03 > test1stInt5Types 6.7334 6.2193 8.27 > test2ndInt2Types 2.4002 2.4013 -0.04 > test2ndInt3Types 7.9603 7.0372 13.12 > test2ndInt5Types 7.9532 7.0474 12.85 > testIfaceCall 6.7028 6.3272 5.94 > testIfaceExtCall 8.3253 6.9416 19.93 > testMonomorphic 1.2446 1.2544 -0.79 > AVG: 7.48 > > > Testing... Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: Review comments, most of them renaming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13792/files - new: https://git.openjdk.org/jdk/pull/13792/files/7aa3f45f..d3c7ba93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=02-03 Stats: 30 lines in 2 files changed: 3 ins; 6 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/13792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13792/head:pull/13792 PR: https://git.openjdk.org/jdk/pull/13792 From bulasevich at openjdk.org Mon Aug 7 08:12:01 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 08:12:01 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 09:03:33 GMT, Evgeny Astigeevich wrote: >> Boris Ulasevich 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 one additional commit since the last revision: >> >> 8307352: AARCH64: Improve itable_stub > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1217: > >> 1215: assert_different_registers(method_result, recv_klass, holder_klass, temp_itbl_klass, scan_temp, holder_offset); >> 1216: >> 1217: int vtable_base = in_bytes(Klass::vtable_start_offset()); > > Why not to use `vtable_start_offset` to be explicit? OK > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1218: > >> 1216: >> 1217: int vtable_base = in_bytes(Klass::vtable_start_offset()); >> 1218: int itentry_off = in_bytes(itableMethodEntry::method_offset()); > > `itmentry_method_offset`? The value is applied once. I removed the variable and use `in_bytes(itableMethodEntry::method_offset())` in place. > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1219: > >> 1217: int vtable_base = in_bytes(Klass::vtable_start_offset()); >> 1218: int itentry_off = in_bytes(itableMethodEntry::method_offset()); >> 1219: int scan_step = itableOffsetEntry::size() * wordSize; > > `itoentry_size_in_bytes`? Let it be itable_offset_entry_size ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285522209 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285524698 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285525284 From bulasevich at openjdk.org Mon Aug 7 08:12:02 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 08:12:02 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 11:45:34 GMT, Volker Simonis wrote: >> src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp line 200: >> >>> 198: temp_reg, temp_reg2, temp_reg3, itable_index, L_no_such_interface); >>> 199: >>> 200: const ptrdiff_t lookupSize = __ pc() - start_pc; >> >> I think you can rename `lookupSize` into `codesize`. > > Agree. Done. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285521784 From bulasevich at openjdk.org Mon Aug 7 08:15:38 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 08:15:38 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: References: Message-ID: <-Uzb3ABeUUqTzDLDblJ57zQMS376sPH5ZdOyb7urm1w=.98faf815-c788-4358-a05e-99ad7ecce596@github.com> On Wed, 19 Jul 2023 09:08:33 GMT, Evgeny Astigeevich wrote: >> Boris Ulasevich 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 one additional commit since the last revision: >> >> 8307352: AARCH64: Improve itable_stub > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1221: > >> 1219: int scan_step = itableOffsetEntry::size() * wordSize; >> 1220: int vte_size = vtableEntry::size_in_bytes(); >> 1221: int ioffset = in_bytes(itableOffsetEntry::interface_offset()); > > `itoentry_interface_offset`? The correct explicit name would be itable_offset_entry_interface_offset, which I think is hard to read. if you don't mind, let us keep the short name for this case: int vtable_start_offset = in_bytes(Klass::vtable_start_offset()); int itable_offset_entry_size = itableOffsetEntry::size() * wordSize; int ioffset = in_bytes(itableOffsetEntry::interface_offset()); int ooffset = in_bytes(itableOffsetEntry::offset_offset()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285531028 From jwaters at openjdk.org Mon Aug 7 08:17:35 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 7 Aug 2023 08:17:35 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 1 Aug 2023 08:19:06 GMT, Julian Waters wrote: >> src/hotspot/os/windows/symbolengine.cpp line 114: >> >>> 112: _capacity = (int)(sizeof(_fallback_buffer) / sizeof(T)); >>> 113: } >>> 114: _p[0] = (T) '\0'; >> >> I find this use of `'\0'` quite suspicious in itself, but it is consistent with the use of `'X'` in `imprint_sentinel()`. I'm unclear what types are possible for `T` in this code. > > There are currently only 2 possible types of HMODULE and char/uint8_t for T at the moment. Weirdly enough only line 126 errors out without the cast while line 114, despite having the same problem, doesn't, but I added the cast to both lines for consistency. If someone else knows why I could probably deal with this code in a better way besides just casting it to T (which I also am reluctant to do) I just checked and the value of the sentinel is ultimately the prvalue 88. I don't know if we'd want to replace all the weird char usages here with explicit values of 0 (and 88 for the sentinel). Maybe future reviews can help with that ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1285533375 From bulasevich at openjdk.org Mon Aug 7 08:19:38 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 08:19:38 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: <4Zkiwd4YBo1Z_PFWBV6RgSIu95OCQ0-gsZKQoi4q9BY=.4c293358-cf53-4984-a12f-3898d81799ed@github.com> References: <4Zkiwd4YBo1Z_PFWBV6RgSIu95OCQ0-gsZKQoi4q9BY=.4c293358-cf53-4984-a12f-3898d81799ed@github.com> Message-ID: <722eqADSc6piGTIWW5rWvD1m7y_JkDGqEGpu-uHH8ME=.73bcd411-e496-43a4-ad53-20fddd9e5270@github.com> On Wed, 19 Jul 2023 09:19:11 GMT, Evgeny Astigeevich wrote: >> Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8307352: AARCH64: Improve itable_stub > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1253: > >> 1251: // } while (temp_itbl_klass != 0); >> 1252: // goto L_no_such_interface // Not found. >> 1253: Label L_scan_holder; > > `L_search_holder_class`? OK > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1274: > >> 1272: // } >> 1273: // } while (temp_itbl_klass != 0); >> 1274: // goto L_no_such_interface // Not found. > > How about the following variant, it will have back jumps to one point instead of two points: > > bind(L_loop_scan_resolved); > ldr(temp_itbl_klass, Address(pre(scan_temp, scan_step))); > bind(L_loop_scan_resolved_entry); > cbz(temp_itbl_klass, L_no_such_interface); > cmp(resolved_klass, temp_itbl_klass); > br(Assembler::EQ, L_resolved_found); > cmp(holder_klass, temp_itbl_klass); > br(Assembler::NE, L_loop_scan_resolved); > mov(holder_offset, scan_temp); > b(L_loop_scan_resolved); Right. This variant is more natural and has the same performance. Thanks! > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1283: > >> 1281: bind(L_loop_scan_resolved); >> 1282: ldr(temp_itbl_klass, Address(pre(scan_temp, scan_step))); >> 1283: bind(L_loop_scan_resolved_entry); > > Is the indentation of `bind` correct? fixed. thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285535106 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285534663 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285535608 From bulasevich at openjdk.org Mon Aug 7 08:31:36 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 08:31:36 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 15:16:25 GMT, Evgeny Astigeevich wrote: >> Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8307352: AARCH64: Improve itable_stub > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1233: > >> 1231: ldr(temp_itbl_klass, Address(recv_klass, scan_temp, Address::lsl(3))); >> 1232: mov(holder_offset, zr); >> 1233: lea(scan_temp, Address(recv_klass, scan_temp, Address::lsl(3))); > > The comments to the code help little to understand the origins of the generated code. > I understand the generated code corresponds to: > > temp_itbl_klass = (itableOffsetEntry*)(recv_klass->start_of_itable())[0].interface_klass() > > which is > > temp_itbl_klass = *(recv_klass + Klass::vtable_start_offset() + sizeof(intptr_t)*recv_klass->_vtable_length + itableOffsetEntry::offset_offset()) > > > You store `recv_klass + Klass::vtable_start_offset() +itableOffsetEntry::offset_offset()` into `recv_klass`. > BTW, you assume `sizeof(intptr_t) == 8` to use `Address::lsl(3)`. Should this be mentioned in comments? > You store `recv_klass + sizeof(intptr_t)*recv_klass->_vtable_length` into `scan_temp` to access `itable[i].interface_klass()`. > > I think the code is worth adding more comments. A simple cpp code explains things better than words. Let me put it in a way that explains data access, rather than strictly following a sequence of register manipulation: int vtable_start_offset = in_bytes(Klass::vtable_start_offset()); int ioffset = in_bytes(itableOffsetEntry::interface_offset()); ldrw(scan_temp, Address(recv_klass, Klass::vtable_length_offset())); add(recv_klass, recv_klass, vtable_start_offset + ioffset); // itableOffsetEntry[] itable = recv_klass + Klass::vtable_start_offset() + recv_klass->_vtable_len; // temp_itbl_klass = itable[0]._interface; ldr(temp_itbl_klass, Address(recv_klass, scan_temp, Address::lsl(3))); // scan_temp = &(itable[0]._interface) lea(scan_temp, Address(recv_klass, scan_temp, Address::lsl(3))); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285548102 From bulasevich at openjdk.org Mon Aug 7 08:40:39 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 08:40:39 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: <4Zkiwd4YBo1Z_PFWBV6RgSIu95OCQ0-gsZKQoi4q9BY=.4c293358-cf53-4984-a12f-3898d81799ed@github.com> References: <4Zkiwd4YBo1Z_PFWBV6RgSIu95OCQ0-gsZKQoi4q9BY=.4c293358-cf53-4984-a12f-3898d81799ed@github.com> Message-ID: On Wed, 19 Jul 2023 09:20:48 GMT, Evgeny Astigeevich wrote: >> Boris Ulasevich 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 one additional commit since the last revision: >> >> 8307352: AARCH64: Improve itable_stub > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1245: > >> 1243: cbz(temp_itbl_klass, L_no_such_interface); >> 1244: >> 1245: // Loop: Look for holder_klass record in itable > > `// Loop: Look for itableOffsetEntry containing holder_klass` The structure of itable is now explained in comment above ` // itableOffsetEntry[] itable = recv_klass + Klass::vtable_start_offset() + recv_klass->_vtable_len;` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285558445 From bulasevich at openjdk.org Mon Aug 7 08:44:38 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 08:44:38 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 09:34:58 GMT, Evgeny Astigeevich wrote: >> Boris Ulasevich 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 one additional commit since the last revision: >> >> 8307352: AARCH64: Improve itable_stub > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1211: > >> 1209: Register temp_itbl_klass, >> 1210: Register scan_temp, >> 1211: Register holder_offset, > > `holder_klass_itoentry`? In fact it holds an offset to a holder_class pointer in the itable, not the whole entry offset. Let us leave is as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285563080 From bulasevich at openjdk.org Mon Aug 7 09:10:32 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 09:10:32 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v5] In-Reply-To: References: Message-ID: > This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 > > The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. > > InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: > > > Cortex-A53 (Pi 3 Model B Rev 1.2) > > test1stInt2Types 37.5 37.358 0.38 > test1stInt3Types 160.166 148.04 8.19 > test1stInt5Types 158.131 147.955 6.88 > test2ndInt2Types 52.634 53.291 -1.23 > test2ndInt3Types 201.39 181.603 10.90 > test2ndInt5Types 195.722 176.707 10.76 > testIfaceCall 157.453 140.498 12.07 > testIfaceExtCall 175.46 154.351 13.68 > testMonomorphic 32.052 32.039 0.04 > AVG: 6.85 > > Cortex-A72 (Pi 4 Model B Rev 1.2) > > test1stInt2Types 27.4796 27.4738 0.02 > test1stInt3Types 66.0085 64.9374 1.65 > test1stInt5Types 67.9812 66.2316 2.64 > test2ndInt2Types 32.0581 32.062 -0.01 > test2ndInt3Types 68.2715 65.6643 3.97 > test2ndInt5Types 68.1012 65.8024 3.49 > testIfaceCall 64.0684 64.1811 -0.18 > testIfaceExtCall 91.6226 81.5867 12.30 > testMonomorphic 26.7161 26.7142 0.01 > AVG: 2.66 > > Neoverse N1 (m6g.metal) > > test1stInt2Types 2.9104 2.9086 0.06 > test1stInt3Types 10.9642 10.2909 6.54 > test1stInt5Types 10.9607 10.2856 6.56 > test2ndInt2Types 3.3410 3.3478 -0.20 > test2ndInt3Types 12.3291 11.3089 9.02 > test2ndInt5Types 12.328 11.2704 9.38 > testIfaceCall 11.0598 10.3657 6.70 > testIfaceExtCall 13.0692 11.2826 15.84 > testMonomorphic 2.2354 2.2341 0.06 > AVG: 6.00 > > Neoverse V1 (c7g.2xlarge) > > test1stInt2Types 2.2317 2.2320 -0.01 > test1stInt3Types 6.6884 6.1911 8.03 > test1stInt5Types 6.7334 6.2193 8.27 > test2ndInt2Types 2.4002 2.4013 -0.04 > test2ndInt3Types 7.9603 7.0372 13.12 > test2ndInt5Types 7.9532 7.0474 12.85 > testIfaceCall 6.7028 6.3272 5.94 > testIfaceExtCall 8.3253 6.9416 19.93 > testMonomorphic 1.2446 1.2544 -0.79 > AVG: 7.48 > > > Testing... Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Review comments, most of them renaming - rework loop_scan_resolved_entry cycle as proposed - 8307352: AARCH64: Improve itable_stub ------------- Changes: https://git.openjdk.org/jdk/pull/13792/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=04 Stats: 129 lines in 3 files changed: 111 ins; 15 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13792/head:pull/13792 PR: https://git.openjdk.org/jdk/pull/13792 From bulasevich at openjdk.org Mon Aug 7 09:10:34 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 09:10:34 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: References: Message-ID: <6bcJmpd_g-Qq9sIr6YtdL7DMiXKxHXeeCYXv2Jm_WO8=.703eba8b-1dc7-4340-8405-ecabfefa4754@github.com> On Wed, 12 Jul 2023 11:46:09 GMT, Volker Simonis wrote: > I wonder if you can get rid of `temp_reg3` (and the `holder_offset` argument of `MacroAssembler::lookup_interface_method_stub()`) by defining `resolved_klass_reg` as `r17` in `VtableStubs::create_itable_stub()` and defining `Register holder_offset = method_result` as local variable in `MacroAssembler::lookup_interface_method_stub()` (the usages of `holder_offset` and `method_result` don't seem to overlap). I think it does not work. Non-overlapping registers are already optimized: resolved_klass and method_result are actually reusing the same rmethod(r12) register. > Otherwise looks good. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13792#issuecomment-1667479781 From bulasevich at openjdk.org Mon Aug 7 09:10:35 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 09:10:35 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v5] In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 11:33:35 GMT, Evgeny Astigeevich wrote: >> What I am trying to say is that I have not found any benchmark or application where a performance impact of TemplateTable::invokeinterface is visible. I would be happy to rework it as well once we see a benchmark which clearly demonstrates the gain, and the gain is substantial to justify the code complexity. > > @bulasevich >> What I am trying to say is that I have not found any benchmark > > IMHO you can run the benchmark mentioned in the description with `-Xint`. > >> Unfortunately, the instructions in between the lookup_interface_method calls are different, making it difficult to create a common stub for them. > > If it needs a lot of work, we can create a JBS issue to implement the same approach for the interpreter. When it is being implemented some common parts might be identified and refactored. Right. I created a separate issue for this task: https://bugs.openjdk.org/browse/JDK-8313870 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1285587456 From kbarrett at openjdk.org Mon Aug 7 09:15:36 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 7 Aug 2023 09:15:36 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: On Fri, 28 Jul 2023 09:33:45 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> zPhysicalMemoryBacking_windows.cpp > > src/hotspot/share/code/codeHeapState.cpp line 1387: > >> 1385: " occupied space) is used by the blocks in the given size range.\n" >> 1386: " %ld characters are printed per percentage point.\n", pctFactor/100); >> 1387: ast->print_cr("total size of all blocks: " INT64_FORMAT_W(7) "M", (total_size< > Wrong for 32-bit platforms. We shouldn't defer the issue of what type `total_size` should be. That's the underlying source of the problem. Don't use `long` types in shared code! I agree with @tstuefe - these should be `size_t`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1285597007 From ogillespie at openjdk.org Mon Aug 7 09:15:34 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Mon, 7 Aug 2023 09:15:34 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 11:21:27 GMT, Oli Gillespie wrote: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Thanks for looking, David. I'm not sure. I can only guess that it was intended to cover all the possible lookup cases, so that any *successful* (equals only increments refcount if it matches) lookup bumps the refcount, making it impossible to forget. And it's true that the majority of the successful equals calls correspond to lookups so the refcount needs to be incremented by someone. The alternatives I see are: * increment after lookup in SymbolTable * let the symbol table caller increment (they already manage decrementing) But really I don't know so I'm hoping someone else has insight. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1667491689 From kbarrett at openjdk.org Mon Aug 7 09:23:32 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 7 Aug 2023 09:23:32 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 08:00:12 GMT, David Holmes wrote: >> Hi David, this throw was removed for this method's declaration in the corresponding hpp file in an earlier commit [8305590: Remove nothrow exception specifications from operator new](https://github.com/openjdk/jdk/commit/0f51e6326373ff7d4a4d9a0e3a2788401f73405d), but the Author forgot to remove the throw() from the definition as well (the error can be viewed in the GHA for the earlier versions of this PR). I believe gcc only errors on this in C++17 mode (for some weird reason) and not our current C++14 mode, which is why it gets a pass on other platforms > > Thanks for that. C++17 makes exception specifications part of the type system: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html Hence a mismatch between a declaration and it's definition is an error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1285607278 From thamtth at imt-soft.com Mon Aug 7 09:23:35 2023 From: thamtth at imt-soft.com (Tham To Thi Hong) Date: Mon, 07 Aug 2023 09:23:35 +0000 (UTC) Subject: Request for Bug Assignment: Test Timed Out Issue in ClhsdbSymbol.java Message-ID: <668719561.1071537.1691399909359.JavaMail.zimbra@imt-soft.com> Dear HotSpot Development Team, I hope this email finds you well. My name is Tham To, and I am a new contributor to the OpenJDK community. I am writing to seek your guidance and assistance regarding a bug that I have been tracking. Bug Details: Bug ID: JDK-8313814 Bug Description: Test serviceability/sa/ClhsdbSymbol.java timed out after passing Status: NEW Priority: P4 Resolution: Unresolved Affects Version/s: 22 Component/s: hotspot Subcomponent: svc-agent OS: Windows Description: I have been actively monitoring the aforementioned bug, which involves a test case timing out after passing. It appears to be a significant issue that may require attention. I believe that understanding and resolving this issue will not only contribute to the enhancement of the HotSpot component but also provide me with valuable learning opportunities as a new contributor to the OpenJDK community. I am eager to contribute to the community by assisting in identifying and addressing this bug. I kindly request to be assigned to this bug so that I can collaborate with the development team to investigate and resolve the root cause of the test timeout. As a new contributor, I am excited about the opportunity to learn from experienced developers and contribute my skills to the OpenJDK project. Thank you for considering my request. I am eager to contribute and learn from the community's expertise. Best regards, Tham To(Ms.) Software Engineer I ------------------ IMT Solutions|Fostering IT Innovation 55-57 Bau Cat 4 St., Tan Binh Dist, Ho Chi Minh City, Vietnam Phone: +84 35 333 4110 Skype: totham024 http://www.imt-soft.com From coleenp at openjdk.org Mon Aug 7 12:05:34 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Aug 2023 12:05:34 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 02:07:22 GMT, David Holmes wrote: >> share/interpreter/bytecodeHistogram.cpp:int BytecodeCounter::_counter_value = 0; >> >> Maybe this should be inx instead. > > The only reason to use `intx` is if this should be 32-bit on 32-bit and 64-bit on 64-bit. I don't think that is the case here. The reason that this should be reverted is that to fix it, you have to fix all the platform code and that seems out of scope for fixing Wconversion warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285771575 From coleenp at openjdk.org Mon Aug 7 12:07:33 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Aug 2023 12:07:33 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code [v2] In-Reply-To: References: Message-ID: On Sat, 5 Aug 2023 16:21:57 GMT, Coleen Phillimore wrote: >> This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). >> int field_offset (int index) const { return field(index).offset(); } >> >> So when we get the field offset back, it's an int. >> >> Also stackwalker passes jlong, so made that consistent. >> >> Tested with tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Dean's suggested changes. The stackwalking code uses jlong and passes it to some functions that take int so gets warnings if the mode argument is inconsistent. This change makes it consistent and avoids the warnings. The Java code uses it as long. If this should be changed to int (which makes more sense), it should be done as a separate change. We can file another RFE for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15160#issuecomment-1667729889 From coleenp at openjdk.org Mon Aug 7 13:03:32 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Aug 2023 13:03:32 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code Message-ID: Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] 1802 | _thread->dec_held_monitor_count(rec + 1); | ~~~~^~~ Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. ------------- Commit messages: - Fix jvmci for held_monitor_count type. - Fix format strings for monitor_counts and fix arguments.cpp differently. - Fix gtests - Fix asserted files in runtime with one warning. - Fix signature.cpp - Fix continuationFreezeThaw.cpp - Fix deoptimization.cpp (size_of_frames is used to assign to _total_frame_sizes, which is an int and referred to from cpu code, so left it as an int and added checked cast instead) - Fixed synchronizer.cpp by fixing _held_monitor_count and _jni_monitor_count. - Fix arguments.cpp - Fixed sharedRuntime.cpp - ... and 3 more: https://git.openjdk.org/jdk/compare/0bb6af3b...4eeeb165 Changes: https://git.openjdk.org/jdk/pull/15177/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313882 Stats: 115 lines in 24 files changed: 3 ins; 9 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/15177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177 PR: https://git.openjdk.org/jdk/pull/15177 From tonyp at openjdk.org Mon Aug 7 13:28:28 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Mon, 7 Aug 2023 13:28:28 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic [v2] In-Reply-To: <42Pr0SQVU4sxSwdMxE9QsH0t2a2zGjwAoAO351DpLqc=.269631b5-dfcd-4a2d-a5bf-63ef0622209d@github.com> References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> <42Pr0SQVU4sxSwdMxE9QsH0t2a2zGjwAoAO351DpLqc=.269631b5-dfcd-4a2d-a5bf-63ef0622209d@github.com> Message-ID: On Sun, 6 Aug 2023 02:38:18 GMT, Fei Yang wrote: > I think It should be more consistent if you use 'mv' instead as we did in other places when moving an immediate into register. Thanks for the suggestion @RealFYang ! I thought `mv` was for register to register copy. But I'll change `li` to `mv` in those two places. I'll integrate the change as soon as I retest. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15156#issuecomment-1667855653 From mdoerr at openjdk.org Mon Aug 7 13:40:39 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 7 Aug 2023 13:40:39 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 06:29:28 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo > > Signed-off-by: Sidraya src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 154: > 152: } else { > 153: assert(to_reg.stack_size() == 4, "size should match"); > 154: // s390 needs 4 Byte offset Seems like this comment should get removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1285880721 From mdoerr at openjdk.org Mon Aug 7 13:45:40 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 7 Aug 2023 13:45:40 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 06:29:28 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo > > Signed-off-by: Sidraya src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 221: > 219: Class type = SharedUtils.primitiveCarrierForSize(layout.byteSize(), false); > 220: bindings.bufferLoad(0, type) > 221: .vmStore(storage, type); Maybe improve indentation? src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/TypeClass.java line 44: > 42: FLOAT; > 43: > 44: private static final int MAX_AGGREGATE_REGS_SIZE = 1; Unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1285885012 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1285886685 From tonyp at openjdk.org Mon Aug 7 13:50:48 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Mon, 7 Aug 2023 13:50:48 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic [v3] In-Reply-To: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: <-iJzv0-csb1Ee7xRGNhY7wAOFlGk6BBN0cN2zKlOyx0=.cc96012c-27b4-4216-8fe6-9c1cbce8aa8d@github.com> > Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): > > before: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op > > > after: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op > > > (only line 3 is not an improvement, but it has higher variation) > > It seems to save around 5% of executed instructions. Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: replaced li with mv ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15156/files - new: https://git.openjdk.org/jdk/pull/15156/files/d7d1cfee..a7e9df67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15156&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15156&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15156.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15156/head:pull/15156 PR: https://git.openjdk.org/jdk/pull/15156 From tonyp at openjdk.org Mon Aug 7 14:17:31 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Mon, 7 Aug 2023 14:17:31 GMT Subject: RFR: 8313779: RISC-V: use andn / orn in the MD5 instrinsic [v3] In-Reply-To: <-iJzv0-csb1Ee7xRGNhY7wAOFlGk6BBN0cN2zKlOyx0=.cc96012c-27b4-4216-8fe6-9c1cbce8aa8d@github.com> References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> <-iJzv0-csb1Ee7xRGNhY7wAOFlGk6BBN0cN2zKlOyx0=.cc96012c-27b4-4216-8fe6-9c1cbce8aa8d@github.com> Message-ID: On Mon, 7 Aug 2023 13:50:48 GMT, Antonios Printezis wrote: >> Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): >> >> before: >> >> >> MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op >> MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op >> MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op >> MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op >> >> >> after: >> >> >> MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op >> MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op >> MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op >> MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op >> >> >> (only line 3 is not an improvement, but it has higher variation) >> >> It seems to save around 5% of executed instructions. > > Antonios Printezis has updated the pull request incrementally with one additional commit since the last revision: > > replaced li with mv Tests pass (with both `-UseZbb` and `+UseZbb`) with the `li` -> `mv` change. I also confirmed that the generated code is the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15156#issuecomment-1667943172 From tonyp at openjdk.org Mon Aug 7 14:20:42 2023 From: tonyp at openjdk.org (Antonios Printezis) Date: Mon, 7 Aug 2023 14:20:42 GMT Subject: Integrated: 8313779: RISC-V: use andn / orn in the MD5 instrinsic In-Reply-To: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> References: <_SMIfJ4dYpqStItAjgPQPcXn5ALQvJIhqDSwqdRa_9Q=.41e197b0-fe32-4895-bae1-11784df9ac5e@github.com> Message-ID: <4T9Oturr_DZVvx1kpuq1MvMoeOdp5rxsflCOcCfpG6o=.7ad37bdc-48b8-4b89-baff-041e89723b08@github.com> On Fri, 4 Aug 2023 13:10:06 GMT, Antonios Printezis wrote: > Small improvement of the MD5 intrinsic when the Zbb extension is available. Performance comparison (with thanks again to @robehn for this!): > > before: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1835.246 ? 252.071 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 145386.522 ? 444.446 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2555.515 ? 639.491 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 149045.631 ? 6658.545 ns/op > > > after: > > > MessageDigests.digest md5 64 DEFAULT avgt 6 1779.637 ? 207.869 ns/op > MessageDigests.digest md5 16384 DEFAULT avgt 6 137147.179 ? 706.396 ns/op > MessageDigests.getAndDigest md5 64 DEFAULT avgt 6 2645.354 ? 1245.318 ns/op > MessageDigests.getAndDigest md5 16384 DEFAULT avgt 6 141306.966 ? 7000.576 ns/op > > > (only line 3 is not an improvement, but it has higher variation) > > It seems to save around 5% of executed instructions. This pull request has now been integrated. Changeset: 4726960f Author: Antonios Printezis URL: https://git.openjdk.org/jdk/commit/4726960fcdc9489fb8f9c7e1a100828f1347c30c Stats: 35 lines in 3 files changed: 26 ins; 3 del; 6 mod 8313779: RISC-V: use andn / orn in the MD5 instrinsic Reviewed-by: luhenry, fyang ------------- PR: https://git.openjdk.org/jdk/pull/15156 From coleenp at openjdk.org Mon Aug 7 14:46:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Aug 2023 14:46:31 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 12:02:14 GMT, Coleen Phillimore wrote: >> The only reason to use `intx` is if this should be 32-bit on 32-bit and 64-bit on 64-bit. I don't think that is the case here. > > The reason that this should be reverted is that to fix it, you have to fix all the platform code and that seems out of scope for fixing Wconversion warnings. Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285976633 From mdoerr at openjdk.org Mon Aug 7 14:51:32 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 7 Aug 2023 14:51:32 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames In-Reply-To: References: Message-ID: <-c8g0jAXEsNr6LEMupIBRiAzCceOWD66779zJYv7KpA=.e0f9f1ce-1d03-4dba-82a9-11eededcb50c@github.com> On Mon, 19 Jun 2023 15:59:15 GMT, Fredrik Bredberg wrote: > Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. > Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. > > By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. I'd use `Rtemp2`. Note that one of the computations can be simplified: diff --git a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp index 00722171058..721a1467ed8 100644 --- a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp +++ b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp @@ -1994,10 +1994,10 @@ void InterpreterMacroAssembler::add_monitor_to_stack(bool stack_is_empty, Regist "size of a monitor must respect alignment of SP"); resize_frame(-monitor_size, /*temp*/esp); // Allocate space for new monitor - sub(R11_scratch1, R1_SP, esp); // esp contains fp - sradi(R11_scratch1, R11_scratch1, Interpreter::logStackElementSize); + subf(Rtemp2, esp, R1_SP); // esp contains fp + sradi(Rtemp2, Rtemp2, Interpreter::logStackElementSize); // Store relativized top_frame_sp - std(R11_scratch1, _ijava_state_neg(top_frame_sp), esp); // esp contains fp + std(Rtemp2, _ijava_state_neg(top_frame_sp), esp); // esp contains fp // Shuffle expression stack down. Recall that stack_base points // just above the new expression stack bottom. Old_tos and new_tos diff --git a/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp b/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp index 7df95d5672e..e3a8b3fbd94 100644 --- a/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp +++ b/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp @@ -1061,9 +1061,8 @@ void TemplateInterpreterGenerator::generate_fixed_frame(bool native_call, Regist __ std(R0, _ijava_state_neg(oop_tmp), R1_SP); // only used for native_call // Store sender's SP and this frame's top SP. - __ subf(R12_scratch2, Rtop_frame_size, R1_SP); __ std(R21_sender_SP, _ijava_state_neg(sender_sp), R1_SP); - __ sub(R12_scratch2, R12_scratch2, R1_SP); + __ neg(R12_scratch2, Rtop_frame_size); __ sradi(R12_scratch2, R12_scratch2, Interpreter::logStackElementSize); // Store relativized top_frame_sp __ std(R12_scratch2, _ijava_state_neg(top_frame_sp), R1_SP); ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1668012425 From coleenp at openjdk.org Mon Aug 7 14:55:30 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Aug 2023 14:55:30 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 14:43:26 GMT, Coleen Phillimore wrote: >> The reason that this should be reverted is that to fix it, you have to fix all the platform code and that seems out of scope for fixing Wconversion warnings. > > Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms. This is complicated. BytecodeCounter::_counter_value is an int, and StopInterpreterAt compares to that in shared code, which is fine because it'll promote the former to intx. The cpu-specific code fetches the former as int and the latter as intx, except in one place so fixing either is going to be work. The one place that complains on x86 is src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp:1865:12: warning: conversion from 'intx' {aka 'long int'} to 'int32_t' {aka 'int'} may change value [-Wconversion] 1865 | StopInterpreterAt, | ^~~~~~~~~~~~~~~~~ __ cmp32(ExternalAddress((address) &BytecodeCounter::_counter_value), StopInterpreterAt, rscratch1); We could just static_cast StopInterpreterAt to int here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1285995173 From duke at openjdk.org Mon Aug 7 17:05:23 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 17:05:23 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer Message-ID: We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. ------------- Commit messages: - JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer Changes: https://git.openjdk.org/jdk/pull/15178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313796 Stats: 25 lines in 5 files changed: 19 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15178/head:pull/15178 PR: https://git.openjdk.org/jdk/pull/15178 From bulasevich at openjdk.org Mon Aug 7 18:56:36 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 7 Aug 2023 18:56:36 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v6] In-Reply-To: References: Message-ID: > This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 > > The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. > > InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: > > > Cortex-A53 (Pi 3 Model B Rev 1.2) > > test1stInt2Types 37.5 37.358 0.38 > test1stInt3Types 160.166 148.04 8.19 > test1stInt5Types 158.131 147.955 6.88 > test2ndInt2Types 52.634 53.291 -1.23 > test2ndInt3Types 201.39 181.603 10.90 > test2ndInt5Types 195.722 176.707 10.76 > testIfaceCall 157.453 140.498 12.07 > testIfaceExtCall 175.46 154.351 13.68 > testMonomorphic 32.052 32.039 0.04 > AVG: 6.85 > > Cortex-A72 (Pi 4 Model B Rev 1.2) > > test1stInt2Types 27.4796 27.4738 0.02 > test1stInt3Types 66.0085 64.9374 1.65 > test1stInt5Types 67.9812 66.2316 2.64 > test2ndInt2Types 32.0581 32.062 -0.01 > test2ndInt3Types 68.2715 65.6643 3.97 > test2ndInt5Types 68.1012 65.8024 3.49 > testIfaceCall 64.0684 64.1811 -0.18 > testIfaceExtCall 91.6226 81.5867 12.30 > testMonomorphic 26.7161 26.7142 0.01 > AVG: 2.66 > > Neoverse N1 (m6g.metal) > > test1stInt2Types 2.9104 2.9086 0.06 > test1stInt3Types 10.9642 10.2909 6.54 > test1stInt5Types 10.9607 10.2856 6.56 > test2ndInt2Types 3.3410 3.3478 -0.20 > test2ndInt3Types 12.3291 11.3089 9.02 > test2ndInt5Types 12.328 11.2704 9.38 > testIfaceCall 11.0598 10.3657 6.70 > testIfaceExtCall 13.0692 11.2826 15.84 > testMonomorphic 2.2354 2.2341 0.06 > AVG: 6.00 > > Neoverse V1 (c7g.2xlarge) > > test1stInt2Types 2.2317 2.2320 -0.01 > test1stInt3Types 6.6884 6.1911 8.03 > test1stInt5Types 6.7334 6.2193 8.27 > test2ndInt2Types 2.4002 2.4013 -0.04 > test2ndInt3Types 7.9603 7.0372 13.12 > test2ndInt5Types 7.9532 7.0474 12.85 > testIfaceCall 6.7028 6.3272 5.94 > testIfaceExtCall 8.3253 6.9416 19.93 > testMonomorphic 1.2446 1.2544 -0.79 > AVG: 7.48 > > > Testing... Boris Ulasevich 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: rework loop_scan_resolved_entry cycle as proposed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13792/files - new: https://git.openjdk.org/jdk/pull/13792/files/93539e29..63b7d369 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=04-05 Stats: 10 lines in 1 file changed: 4 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13792/head:pull/13792 PR: https://git.openjdk.org/jdk/pull/13792 From aph at openjdk.org Mon Aug 7 20:28:36 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 7 Aug 2023 20:28:36 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 13:37:33 GMT, Richard Startin wrote: > We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. src/hotspot/cpu/ppc/frame_ppc.cpp line 332: > 330: } > 331: Method* m = *m_addr; > 332: Wouldn't it make more sense to define a function which takes a pointer to a (possible) method pointer and returns true if the method is valid? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286354014 From aph at openjdk.org Mon Aug 7 20:45:33 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 7 Aug 2023 20:45:33 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 13:37:33 GMT, Richard Startin wrote: > We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. src/hotspot/cpu/aarch64/frame_aarch64.cpp line 514: > 512: return false; > 513: } > 514: Method* m = *m_addr; Suggestion: Method* m_addr = interpreter_frame_method_addr(); if (m_addr == nullptr) { return false; } Method* m = SafeFetchN(m_addr, nullptr); if (m == nullptr) { return false; } Reason: more robust against changes in memory map, faster. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286366886 From duke at openjdk.org Mon Aug 7 20:45:34 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 20:45:34 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 20:26:06 GMT, Andrew Haley wrote: >> We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. > > src/hotspot/cpu/ppc/frame_ppc.cpp line 332: > >> 330: } >> 331: Method* m = *m_addr; >> 332: > > Wouldn't it make more sense to define a function which takes a pointer to a (possible) method pointer and returns true if the method is valid? It's not clear to me how the proposed solution could make less sense than another solution - could you elaborate please? Are you concerned about code repetition? I must say this code is already rather repetitive across the different architectures and, while I don't want to make it any worse in that respect, I'm trying to make the smallest possible change to prevent the observed crash from recurring. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286366611 From apangin at openjdk.org Mon Aug 7 20:58:29 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Mon, 7 Aug 2023 20:58:29 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer In-Reply-To: References: Message-ID: <0FU1J6ZFASHhUKobCWyZKpwwyg51nJC4a4pD81nnnvA=.0eb47a27-1a75-452f-bad1-a11bf33015ca@github.com> On Mon, 7 Aug 2023 13:37:33 GMT, Richard Startin wrote: > We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. src/hotspot/cpu/aarch64/frame_aarch64.cpp line 511: > 509: // first the method > 510: Method** m_addr = interpreter_frame_method_addr(); > 511: if (m_addr == nullptr || !os::is_readable_pointer(m_addr)) { Just wondering, why checking `is_readable_pointer` + dereference instead of `SafeFetch` which does both in one shot? Especially since `os::is_readable_pointer` is implemented with `SafeFetch` anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286375719 From duke at openjdk.org Mon Aug 7 21:06:35 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 21:06:35 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 20:42:48 GMT, Andrew Haley wrote: >> We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. > > src/hotspot/cpu/aarch64/frame_aarch64.cpp line 514: > >> 512: return false; >> 513: } >> 514: Method* m = *m_addr; > > Suggestion: > > Method* m_addr = interpreter_frame_method_addr(); > if (m_addr == nullptr) { > return false; > } > Method* m = SafeFetchN(m_addr, nullptr); > if (m == nullptr) { > return false; > } > > > Reason: more robust against changes in memory map, faster. Thanks for raising this. It doesn't look like `SafeFetchN` is async signal safe because it calls into this: template ATTRIBUTE_NO_ASAN static bool _SafeFetchXX_internal(const T *adr, T* result) { T n = 0; // Set up a jump buffer. Anchor its pointer in TLS. Then read from the unsafe address. // If that address was invalid, we fault, and in the signal handler we will jump back // to the jump point. sigjmp_buf jb; if (sigsetjmp(jb, 1) != 0) { // We faulted. Reset TLS slot, then return. pthread_setspecific(g_jmpbuf_key, nullptr); *result = 0; return false; } // Anchor jump buffer in TLS pthread_setspecific(g_jmpbuf_key, &jb); // unsafe access n = *adr; // Still here... All went well, adr was valid. // Reset TLS slot, then return result. pthread_setspecific(g_jmpbuf_key, nullptr); *result = n; return true; } This means we shouldn't be calling `os:: is_readable_pointer` either here, because it calls `SafeFetch32` which calls into the same function above. I had originally intended to simply perform a null check here (because that's the condition we've actually observed) and will push a change to revert to the null check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286381814 From duke at openjdk.org Mon Aug 7 21:12:40 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 21:12:40 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v2] In-Reply-To: References: Message-ID: > We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. Richard Startin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15178/files - new: https://git.openjdk.org/jdk/pull/15178/files/d9c92a15..5520d1e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15178&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15178&range=00-01 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15178/head:pull/15178 PR: https://git.openjdk.org/jdk/pull/15178 From duke at openjdk.org Mon Aug 7 21:15:30 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 21:15:30 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v2] In-Reply-To: <0FU1J6ZFASHhUKobCWyZKpwwyg51nJC4a4pD81nnnvA=.0eb47a27-1a75-452f-bad1-a11bf33015ca@github.com> References: <0FU1J6ZFASHhUKobCWyZKpwwyg51nJC4a4pD81nnnvA=.0eb47a27-1a75-452f-bad1-a11bf33015ca@github.com> Message-ID: On Mon, 7 Aug 2023 20:54:45 GMT, Andrei Pangin wrote: >> Richard Startin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer > > src/hotspot/cpu/aarch64/frame_aarch64.cpp line 511: > >> 509: // first the method >> 510: Method** m_addr = interpreter_frame_method_addr(); >> 511: if (m_addr == nullptr || !os::is_readable_pointer(m_addr)) { > > Just wondering, why checking `is_readable_pointer` + dereference instead of `SafeFetch` which does both in one shot? Especially since `os::is_readable_pointer` is implemented with `SafeFetch` anyway. Thanks for the question. I've just removed the `is_readable_pointer` check since it's not necessary. We only observed a null pointer so the null check is sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286387497 From duke at openjdk.org Mon Aug 7 21:15:29 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 21:15:29 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v2] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 21:12:40 GMT, Richard Startin wrote: >> We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. > > Richard Startin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer I apologise for force-pushing as I was not aware of OpenJDK etiquette regarding this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15178#issuecomment-1668583911 From aph at openjdk.org Mon Aug 7 21:19:31 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 7 Aug 2023 21:19:31 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v2] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 21:03:28 GMT, Richard Startin wrote: >> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 514: >> >>> 512: return false; >>> 513: } >>> 514: Method* m = *m_addr; >> >> Suggestion: >> >> Method* m_addr = interpreter_frame_method_addr(); >> if (m_addr == nullptr) { >> return false; >> } >> Method* m = SafeFetchN(m_addr, nullptr); >> if (m == nullptr) { >> return false; >> } >> >> >> Reason: more robust against changes in memory map, faster. > > Thanks for raising this. It doesn't look like `SafeFetchN` is async signal safe because it calls into this: > > > template > ATTRIBUTE_NO_ASAN static bool _SafeFetchXX_internal(const T *adr, T* result) { > > T n = 0; > > // Set up a jump buffer. Anchor its pointer in TLS. Then read from the unsafe address. > // If that address was invalid, we fault, and in the signal handler we will jump back > // to the jump point. > sigjmp_buf jb; > if (sigsetjmp(jb, 1) != 0) { > // We faulted. Reset TLS slot, then return. > pthread_setspecific(g_jmpbuf_key, nullptr); > *result = 0; > return false; > } > > // Anchor jump buffer in TLS > pthread_setspecific(g_jmpbuf_key, &jb); > > // unsafe access > n = *adr; > > // Still here... All went well, adr was valid. > // Reset TLS slot, then return result. > pthread_setspecific(g_jmpbuf_key, nullptr); > *result = n; > > return true; > > } > > > This means we shouldn't be calling `os:: is_readable_pointer` either here, because it calls `SafeFetch32` which calls into the same function above. I had originally intended to simply perform a null check here (because that's the condition we've actually observed) and will push a change to revert to the null check. > Thanks for raising this. It doesn't look like `SafeFetchN` is async signal safe because it calls into this: > > ```c++ > template > ATTRIBUTE_NO_ASAN static bool _SafeFetchXX_internal(const T *adr, T* result) { > > ``` > > This means we shouldn't be calling `os:: is_readable_pointer` either here, because it calls `SafeFetch32` which calls into the same function above. I had originally intended to simply perform a null check here (because that's the condition we've actually observed) and will push a change to revert to the null check. That's not how `SafeFetchN` is normally implemented. On Linux and BSD it's more like # Support for intptr_t SafeFetchN(intptr_t* address, intptr_t defaultval); # # x1 : address # x0 : defaultval SafeFetchN_impl: _SafeFetchN_fault: ldr x0, [x0] ret _SafeFetchN_continuation: mov x0, x1 ret which should be fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286391557 From jbechberger at openjdk.org Mon Aug 7 21:28:29 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 7 Aug 2023 21:28:29 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v2] In-Reply-To: References: Message-ID: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> On Mon, 7 Aug 2023 21:17:04 GMT, Andrew Haley wrote: >> Thanks for raising this. It doesn't look like `SafeFetchN` is async signal safe because it calls into this: >> >> >> template >> ATTRIBUTE_NO_ASAN static bool _SafeFetchXX_internal(const T *adr, T* result) { >> >> T n = 0; >> >> // Set up a jump buffer. Anchor its pointer in TLS. Then read from the unsafe address. >> // If that address was invalid, we fault, and in the signal handler we will jump back >> // to the jump point. >> sigjmp_buf jb; >> if (sigsetjmp(jb, 1) != 0) { >> // We faulted. Reset TLS slot, then return. >> pthread_setspecific(g_jmpbuf_key, nullptr); >> *result = 0; >> return false; >> } >> >> // Anchor jump buffer in TLS >> pthread_setspecific(g_jmpbuf_key, &jb); >> >> // unsafe access >> n = *adr; >> >> // Still here... All went well, adr was valid. >> // Reset TLS slot, then return result. >> pthread_setspecific(g_jmpbuf_key, nullptr); >> *result = n; >> >> return true; >> >> } >> >> >> This means we shouldn't be calling `os:: is_readable_pointer` either here, because it calls `SafeFetch32` which calls into the same function above. I had originally intended to simply perform a null check here (because that's the condition we've actually observed) and will push a change to revert to the null check. > >> Thanks for raising this. It doesn't look like `SafeFetchN` is async signal safe because it calls into this: >> >> ```c++ >> template >> ATTRIBUTE_NO_ASAN static bool _SafeFetchXX_internal(const T *adr, T* result) { >> >> ``` >> >> This means we shouldn't be calling `os:: is_readable_pointer` either here, because it calls `SafeFetch32` which calls into the same function above. I had originally intended to simply perform a null check here (because that's the condition we've actually observed) and will push a change to revert to the null check. > > That's not how `SafeFetchN` is normally implemented. On Linux and BSD it's more like > > > # Support for intptr_t SafeFetchN(intptr_t* address, intptr_t defaultval); > # > # x1 : address > # x0 : defaultval > SafeFetchN_impl: > _SafeFetchN_fault: > ldr x0, [x0] > ret > _SafeFetchN_continuation: > mov x0, x1 > ret > > > which should be fine. @tstuefe implemented explicitly for being signal safe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286395805 From duke at openjdk.org Mon Aug 7 21:28:31 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 21:28:31 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v2] In-Reply-To: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> References: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> Message-ID: On Mon, 7 Aug 2023 21:23:48 GMT, Johannes Bechberger wrote: >>> Thanks for raising this. It doesn't look like `SafeFetchN` is async signal safe because it calls into this: >>> >>> ```c++ >>> template >>> ATTRIBUTE_NO_ASAN static bool _SafeFetchXX_internal(const T *adr, T* result) { >>> >>> ``` >>> >>> This means we shouldn't be calling `os:: is_readable_pointer` either here, because it calls `SafeFetch32` which calls into the same function above. I had originally intended to simply perform a null check here (because that's the condition we've actually observed) and will push a change to revert to the null check. >> >> That's not how `SafeFetchN` is normally implemented. On Linux and BSD it's more like >> >> >> # Support for intptr_t SafeFetchN(intptr_t* address, intptr_t defaultval); >> # >> # x1 : address >> # x0 : defaultval >> SafeFetchN_impl: >> _SafeFetchN_fault: >> ldr x0, [x0] >> ret >> _SafeFetchN_continuation: >> mov x0, x1 >> ret >> >> >> which should be fine. > > @tstuefe implemented explicitly for being signal safe. OK let's go with your suggestion, thanks for explaining. I'm actually skeptical this can actually be a non-null bad pointer, as we've only seen this crash happen once, and the pointer was null in that instance. But this solution looks robust, so thanks for suggesting it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286397215 From duke at openjdk.org Mon Aug 7 21:37:47 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 21:37:47 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v3] In-Reply-To: References: Message-ID: > We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. Richard Startin has updated the pull request incrementally with one additional commit since the last revision: use Andrew Haley's suggested implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15178/files - new: https://git.openjdk.org/jdk/pull/15178/files/5520d1e0..5a613b3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15178&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15178&range=01-02 Stats: 22 lines in 5 files changed: 16 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15178/head:pull/15178 PR: https://git.openjdk.org/jdk/pull/15178 From duke at openjdk.org Mon Aug 7 21:52:47 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 21:52:47 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: Message-ID: > We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. Richard Startin has updated the pull request incrementally with one additional commit since the last revision: missing includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15178/files - new: https://git.openjdk.org/jdk/pull/15178/files/5a613b3a..1a8b10c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15178&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15178&range=02-03 Stats: 5 lines in 5 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15178/head:pull/15178 PR: https://git.openjdk.org/jdk/pull/15178 From duke at openjdk.org Mon Aug 7 21:52:50 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 21:52:50 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: <0FU1J6ZFASHhUKobCWyZKpwwyg51nJC4a4pD81nnnvA=.0eb47a27-1a75-452f-bad1-a11bf33015ca@github.com> Message-ID: On Mon, 7 Aug 2023 21:11:59 GMT, Richard Startin wrote: >> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 511: >> >>> 509: // first the method >>> 510: Method** m_addr = interpreter_frame_method_addr(); >>> 511: if (m_addr == nullptr || !os::is_readable_pointer(m_addr)) { >> >> Just wondering, why checking `is_readable_pointer` + dereference instead of `SafeFetch` which does both in one shot? Especially since `os::is_readable_pointer` is implemented with `SafeFetch` anyway. > > Thanks for the question. I've just removed the `is_readable_pointer` check since it's not necessary. We only observed a null pointer so the null check is sufficient. I implemented @theRealAph's suggestion instead, please take a look ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286410702 From duke at openjdk.org Mon Aug 7 22:02:44 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 22:02:44 GMT Subject: Withdrawn: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 13:37:33 GMT, Richard Startin wrote: > We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15178 From duke at openjdk.org Mon Aug 7 22:02:43 2023 From: duke at openjdk.org (Richard Startin) Date: Mon, 7 Aug 2023 22:02:43 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 21:52:47 GMT, Richard Startin wrote: >> We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. > > Richard Startin has updated the pull request incrementally with one additional commit since the last revision: > > missing includes I intend to revert to the null check I originally intended, I'll follow up with another PR rather than force push again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15178#issuecomment-1668631874 From jbachorik at openjdk.org Tue Aug 8 00:15:37 2023 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Tue, 8 Aug 2023 00:15:37 GMT Subject: RFR: 8313816: Accessing jmethodID might lead to spurious crashes Message-ID: <9OQfGXwDLioWWVoJpNbaJ_seGXH_XB-m8-zx462dIag=.a0641514-a759-4a38-bcd8-c808c7c1aa2e@github.com> This is a best effort attempt to harmonize the handling of jmethodIDs when the instanceKlass internal structures are being deallocated (eg. due to `ClassLoaderData::free_deallocate_list`). In all other instances, the jmethodID is NULLed (or set to `_free_method`) before the references Method structures are deallocated. This actually makes possible to query such jmethodIDs without crashing JVM even if the corresponding classes/methods were unloaded. While it is understandable why JVM can not keep the method metadata around forever it really should be possible to at least assert the validity of a jmethodID without crashing JVM. If nothing else, this makes using the JVMTI functions `GetAllStackTraces` or `GetStackTrace` a risk to use in JVMTI agents - the jmethodids can become invalid the very next moment after the stacktrace is obtained. ------------- Commit messages: - 8313816: Accessing jmethodID might lead to spurious crashes Changes: https://git.openjdk.org/jdk/pull/15171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313816 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15171/head:pull/15171 PR: https://git.openjdk.org/jdk/pull/15171 From apangin at openjdk.org Tue Aug 8 01:53:41 2023 From: apangin at openjdk.org (Andrei Pangin) Date: Tue, 8 Aug 2023 01:53:41 GMT Subject: RFR: 8313816: Accessing jmethodID might lead to spurious crashes In-Reply-To: <9OQfGXwDLioWWVoJpNbaJ_seGXH_XB-m8-zx462dIag=.a0641514-a759-4a38-bcd8-c808c7c1aa2e@github.com> References: <9OQfGXwDLioWWVoJpNbaJ_seGXH_XB-m8-zx462dIag=.a0641514-a759-4a38-bcd8-c808c7c1aa2e@github.com> Message-ID: <4j0z4CRk8dfNlaw84cTgMay9v0w20Egl4xveBtEK5Go=.172bcaf0-5cf2-44f0-a540-a7e00a88381b@github.com> On Mon, 7 Aug 2023 00:50:30 GMT, Jaroslav Bachorik wrote: > This is a best effort attempt to harmonize the handling of jmethodIDs when the instanceKlass internal structures are being deallocated (eg. due to `ClassLoaderData::free_deallocate_list`). > In all other instances, the jmethodID is NULLed (or set to `_free_method`) before the references Method structures are deallocated. This actually makes possible to query such jmethodIDs without crashing JVM even if the corresponding classes/methods were unloaded. > > While it is understandable why JVM can not keep the method metadata around forever it really should be possible to at least assert the validity of a jmethodID without crashing JVM. If nothing else, this makes using the JVMTI functions `GetAllStackTraces` or `GetStackTrace` a risk to use in JVMTI agents - the jmethodids can become invalid the very next moment after the stacktrace is obtained. Changes requested by apangin (no project role). src/hotspot/share/oops/instanceKlass.cpp line 2834: > 2832: for (size_t i = 1; i <= count; i++) { > 2833: *((Method**)jmeths[i]) = nullptr; > 2834: } The proposed change looks suspicious: the structure being zeroed is released on the very next line. So, this change does not seem to fix anything - it only makes a bug (if any) less obvious. I would rather do the opposite: poison the memory to make sure any attempt to access freed memory will immediately fail and thus reveal the bug in the code. P.S. JVM TI functions do not access this structure; they use jmethodID cache in ClassLoaderData which is cleared but never released, see https://github.com/openjdk/jdk/blob/87b08b6e0192d88025c2275c7dd2c4bdecda58e8/src/hotspot/share/classfile/classLoaderData.cpp#L609C14-L622 ------------- PR Review: https://git.openjdk.org/jdk/pull/15171#pullrequestreview-1566354864 PR Review Comment: https://git.openjdk.org/jdk/pull/15171#discussion_r1286518429 From dlong at openjdk.org Tue Aug 8 02:36:49 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 8 Aug 2023 02:36:49 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code [v2] In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 23:24:45 GMT, Coleen Phillimore wrote: > Why not? It's the same and casts the int where it's needed to be an int. To me the checked_cast looks less ugly in the initialization vs at the uses sites, but in this case with only one use it doesn't really matter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15160#discussion_r1286536069 From eosterlund at openjdk.org Tue Aug 8 04:10:42 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 8 Aug 2023 04:10:42 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> Message-ID: On Mon, 7 Aug 2023 21:26:00 GMT, Richard Startin wrote: >> @tstuefe implemented explicitly for being signal safe. > > OK let's go with your suggestion, thanks for explaining. I'm actually skeptical this can actually be a non-null bad pointer, as we've only seen this crash happen once, and the pointer was null in that instance. But this solution looks robust, so thanks for suggesting it. So you can safely fetch something that might be a method, and even if it really is a method and that can be verified, it might be a concurrently unloading method that is about to get clobbered or uncommiyted. Dereferencing and using such a Method is also subject to occasional crashing. Might be a problem for another day though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286573306 From jbachorik at openjdk.org Tue Aug 8 04:33:43 2023 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Tue, 8 Aug 2023 04:33:43 GMT Subject: RFR: 8313816: Accessing jmethodID might lead to spurious crashes In-Reply-To: <4j0z4CRk8dfNlaw84cTgMay9v0w20Egl4xveBtEK5Go=.172bcaf0-5cf2-44f0-a540-a7e00a88381b@github.com> References: <9OQfGXwDLioWWVoJpNbaJ_seGXH_XB-m8-zx462dIag=.a0641514-a759-4a38-bcd8-c808c7c1aa2e@github.com> <4j0z4CRk8dfNlaw84cTgMay9v0w20Egl4xveBtEK5Go=.172bcaf0-5cf2-44f0-a540-a7e00a88381b@github.com> Message-ID: On Tue, 8 Aug 2023 01:51:01 GMT, Andrei Pangin wrote: >> This is a best effort attempt to harmonize the handling of jmethodIDs when the instanceKlass internal structures are being deallocated (eg. due to `ClassLoaderData::free_deallocate_list`). >> In all other instances, the jmethodID is NULLed (or set to `_free_method`) before the references Method structures are deallocated. This actually makes possible to query such jmethodIDs without crashing JVM even if the corresponding classes/methods were unloaded. >> >> While it is understandable why JVM can not keep the method metadata around forever it really should be possible to at least assert the validity of a jmethodID without crashing JVM. If nothing else, this makes using the JVMTI functions `GetAllStackTraces` or `GetStackTrace` a risk to use in JVMTI agents - the jmethodids can become invalid the very next moment after the stacktrace is obtained. > > src/hotspot/share/oops/instanceKlass.cpp line 2834: > >> 2832: for (size_t i = 1; i <= count; i++) { >> 2833: *((Method**)jmeths[i]) = nullptr; >> 2834: } > > The proposed change looks suspicious: the structure being zeroed is released on the very next line. > So, this change does not seem to fix anything - it only makes a bug (if any) less obvious. > I would rather do the opposite: poison the memory to make sure any attempt to access freed memory will immediately fail and thus reveal the bug in the code. > > P.S. JVM TI functions do not access this structure; they use jmethodID cache in ClassLoaderData which is cleared but never released, see https://github.com/openjdk/jdk/blob/87b08b6e0192d88025c2275c7dd2c4bdecda58e8/src/hotspot/share/classfile/classLoaderData.cpp#L609C14-L622 Regarding PS - are you sure? Eg. when I look at the way the stacktrace is obtained at https://github.com/openjdk/jdk/blob/87b08b6e0192d88025c2275c7dd2c4bdecda58e8/src/hotspot/share/prims/jvmtiEnvBase.cpp#L1171, it calls to https://github.com/openjdk/jdk/blob/87b08b6e0192d88025c2275c7dd2c4bdecda58e8/src/hotspot/share/oops/method.cpp#L2196 which in turn calls to https://github.com/openjdk/jdk/blob/87b08b6e0192d88025c2275c7dd2c4bdecda58e8/src/hotspot/share/oops/instanceKlass.cpp#L2247 and then https://github.com/openjdk/jdk/blob/87b08b6e0192d88025c2275c7dd2c4bdecda58e8/src/hotspot/share/oops/instanceKlass.cpp#L2397 This really seems like the the jmethodID array obtained via `methods_jmethod_ids_acquire()` is the source of truth, at least in this case. Regarding zeroing the released structure - IIUC, by doing something like `jmethodID mid = jmeths[idx]` the `mid` value (which is in fact a pointer to `Method`) will remain valid even after the holding array has been deallocated. I have also did a small experiment, just to be sure I am not making a complete fool of myself with following code mid = jni->GetStaticMethodID(clz, "run", "()V"); if (mid != nullptr) { printf("jmethodID points to null: %s\n", *((void**)mid) == nullptr ? "true" : "false"); jmethodID mid1 = mid; *((void**)mid1) = nullptr; printf("jmethodID points to null: %s\n", *((void**)mid) == nullptr ? "true" : "false"); } yielding jmethodID points to null: false jmethodID points to null: true I am running some extra tests now and will switch the PR to draft until I have some results ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15171#discussion_r1286582932 From duke at openjdk.org Tue Aug 8 05:39:05 2023 From: duke at openjdk.org (sid8606) Date: Tue, 8 Aug 2023 05:39:05 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 13:37:57 GMT, Martin Doerr wrote: >> sid8606 has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo >> >> Signed-off-by: Sidraya > > src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 154: > >> 152: } else { >> 153: assert(to_reg.stack_size() == 4, "size should match"); >> 154: // s390 needs 4 Byte offset > > Seems like this comment should get removed. Fixed > src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 221: > >> 219: Class type = SharedUtils.primitiveCarrierForSize(layout.byteSize(), false); >> 220: bindings.bufferLoad(0, type) >> 221: .vmStore(storage, type); > > Maybe improve indentation? Thank you @TheRealMDoerr. Fixed in new commit. > src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/TypeClass.java line 44: > >> 42: FLOAT; >> 43: >> 44: private static final int MAX_AGGREGATE_REGS_SIZE = 1; > > Unused. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286613915 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286613616 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286613721 From duke at openjdk.org Tue Aug 8 05:39:04 2023 From: duke at openjdk.org (sid8606) Date: Tue, 8 Aug 2023 05:39:04 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for s390x (Big Endian). sid8606 has updated the pull request incrementally with one additional commit since the last revision: Fix indentation Signed-off-by: Sidraya ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14801/files - new: https://git.openjdk.org/jdk/pull/14801/files/924b45bc..a28c92d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=09-10 Stats: 16 lines in 3 files changed: 0 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/14801.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801 PR: https://git.openjdk.org/jdk/pull/14801 From duke at openjdk.org Tue Aug 8 05:39:05 2023 From: duke at openjdk.org (sid8606) Date: Tue, 8 Aug 2023 05:39:05 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: On Sun, 6 Aug 2023 09:32:08 GMT, Andrey Turbanov wrote: >> sid8606 has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo >> >> Signed-off-by: Sidraya > > src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 112: > >> 110: } >> 111: >> 112: public static MethodHandle arrangeDowncall(MethodType mt, FunctionDescriptor cDesc, LinkerOptions options) { > > Suggestion: > > public static MethodHandle arrangeDowncall(MethodType mt, FunctionDescriptor cDesc, LinkerOptions options) { Thank you @turbanoff for the review comment. I have Fixed this in new commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286613222 From stuefe at openjdk.org Tue Aug 8 05:52:54 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 05:52:54 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 21:52:47 GMT, Richard Startin wrote: >> We have observed invalid pointers to the interpreted method at Datadog. The fix is based on a discussion with and a code snippet from @parttimenerd. > > Richard Startin has updated the pull request incrementally with one additional commit since the last revision: > > missing includes Hi Richard, Looks good. It is still not perfectly safe since the method could go out of scope concurrently while you are using it. Cheers, Thomas --- Oh, I see you closed it. Ah, well. ------------- PR Review: https://git.openjdk.org/jdk/pull/15178#pullrequestreview-1566515484 From jbechberger at openjdk.org Tue Aug 8 06:27:53 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 8 Aug 2023 06:27:53 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> Message-ID: On Tue, 8 Aug 2023 04:07:20 GMT, Erik ?sterlund wrote: >> OK let's go with your suggestion, thanks for explaining. I'm actually skeptical this can actually be a non-null bad pointer, as we've only seen this crash happen once, and the pointer was null in that instance. But this solution looks robust, so thanks for suggesting it. > > So you can safely fetch something that might be a method, and even if it really is a method and that can be verified, it might be a concurrently unloading method that is about to get clobbered or uncommiyted. Dereferencing and using such a Method is also subject to occasional crashing. Might be a problem for another day though. @fisk this might be solved in a new version of the API. I already spoke with @apangin about this and he's positive :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286647947 From stuefe at openjdk.org Tue Aug 8 06:27:53 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 06:27:53 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> Message-ID: On Mon, 7 Aug 2023 21:26:00 GMT, Richard Startin wrote: >> @tstuefe implemented explicitly for being signal safe. > > OK let's go with your suggestion, thanks for explaining. I'm actually skeptical this can actually be a non-null bad pointer, as we've only seen this crash happen once, and the pointer was null in that instance. But this solution looks robust, so thanks for suggesting it. @richardstartin About async-safety: all supported (jit) architectures use static assembly as @theRealAph pointed out, these should be signal safe. The code snippet you found is only used by zero. You are probably not concerned with zero. And even there, yes, we longjmp out of signal handling, since there is no other way to implement SafeFetch in zero. That is technically async-sig-unsafe, but in practice it works and is tested for use in signal handlers. About safety, @fisk is right in that this is still not completely safe since Method (and any of the objects chained to it that AGCT implicitly relies on being there, e.g. ConstMethod) can get out of scope while AGCT uses them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286645990 From duke at openjdk.org Tue Aug 8 08:49:41 2023 From: duke at openjdk.org (Richard Startin) Date: Tue, 8 Aug 2023 08:49:41 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> Message-ID: On Tue, 8 Aug 2023 06:22:23 GMT, Thomas Stuefe wrote: >> OK let's go with your suggestion, thanks for explaining. I'm actually skeptical this can actually be a non-null bad pointer, as we've only seen this crash happen once, and the pointer was null in that instance. But this solution looks robust, so thanks for suggesting it. > > @richardstartin About async-safety: all supported (jit) architectures use static assembly as @theRealAph pointed out, these should be signal safe. The code snippet you found is only used by zero. You are probably not concerned with zero. And even there, yes, we longjmp out of signal handling, since there is no other way to implement SafeFetch in zero. That is technically async-sig-unsafe, but in practice it works and is tested for use in signal handlers. > > About safety, @fisk is right in that this is still not completely safe since Method (and any of the objects chained to it that AGCT implicitly relies on being there, e.g. ConstMethod) can get out of scope while AGCT uses them. @tstuefe @fisk I hadn't appreciated that the cause was probably concurrent method unloading, we don't have a core dump, just the backtrace from the crash and the disassembly from objdump, so all I knew was that the pointer was null but not why. This is not the sort of thing that reproduces readily. I don't have as much context about the adjacent JVM mechanisms as others in this thread and am just trying to fix a crash based on the evidence I have. This pointer being null seems to be a symptom rather than a cause and it doesn't appear there's anything we can do about concurrent method unloading interfering with AsyncGetCallTrace, so I wonder how worthwhile attempting to fix this is. On the one hand it will crash another way sometimes, on the other hand the probability of this happening is significantly reduced to the subsequent usages of the pointer, whereas that window of time for unloading a method to cause a crash in AsyncGetCallTrace is currently the duration of the unwind preceding the current frame. Let me know what you think about proceeding and I'll submit a fix with the null check which would have been sufficient to avoid the observed segfault. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1286808560 From azafari at openjdk.org Tue Aug 8 09:22:12 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 8 Aug 2023 09:22:12 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v2] In-Reply-To: References: Message-ID: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. 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/15164/files - new: https://git.openjdk.org/jdk/pull/15164/files/18437bd0..1fe96046 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15164/head:pull/15164 PR: https://git.openjdk.org/jdk/pull/15164 From azafari at openjdk.org Tue Aug 8 09:22:16 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 8 Aug 2023 09:22:16 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v2] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 02:01:17 GMT, David Holmes wrote: >> src/hotspot/share/opto/macro.cpp line 1841: >> >>> 1839: // Generate several prefetch instructions. >>> 1840: int step_size = AllocatePrefetchStepSize; >>> 1841: int distance = AllocatePrefetchDistance; >> >> I think this is a step in the wrong direction. Shouldn't these remain uint? > > This change also doesn't fit the PR description. There is no need to change this in this PR (or even at all). Okay. Reverted back. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1286844367 From azafari at openjdk.org Tue Aug 8 09:22:18 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 8 Aug 2023 09:22:18 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v2] In-Reply-To: <9jVcTomxlgxuotOMDSRY9JOkrKAQc4rFHbaG1ogMt8I=.f5761775-2196-4f20-a117-9fc4ed1c5894@github.com> References: <9jVcTomxlgxuotOMDSRY9JOkrKAQc4rFHbaG1ogMt8I=.f5761775-2196-4f20-a117-9fc4ed1c5894@github.com> Message-ID: On Mon, 7 Aug 2023 02:01:55 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments applied. > > src/hotspot/share/opto/macro.cpp line 1879: > >> 1877: // Generate several prefetch instructions. >> 1878: int step_size = AllocatePrefetchStepSize; >> 1879: int distance = AllocatePrefetchDistance; > > Ditto no need to change Okay. Reverted back. > src/hotspot/share/runtime/globals.hpp line 1104: > >> 1102: "Collect information about IndexSets") \ >> 1103: \ >> 1104: develop(int, FastAllocateSizeLimit, 128*K, \ > > Ensure the value is either never printed or else the format specifier is updated accordingly. Okay. It is only printed in `[Global flags]` printing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1286844903 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1286842588 From stefank at openjdk.org Tue Aug 8 09:54:49 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 8 Aug 2023 09:54:49 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names [v2] In-Reply-To: References: Message-ID: > I've found that our misc flags printing is broken. This can be seen in our hs_err files: > > RCX=0x00007f86bf0073c8 is a pointer to class: > java.lang.Class {0x00007f86bf0073c8} > - instance size: 22 > - klass size: 97 > - access: public final synchronized > - flags: ##name ##name ##name ##name ##name ##name > > > With this fix the flags are now printed as expected: > > java.util.Hashtable {0x00007f5fff00e8c0} > - instance size: 8 > - klass size: 123 > - access: public synchronized > - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method > > > The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Tweak ouput ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15153/files - new: https://git.openjdk.org/jdk/pull/15153/files/beae18c2..1e879f92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15153&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15153&range=00-01 Stats: 4 lines in 3 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15153.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15153/head:pull/15153 PR: https://git.openjdk.org/jdk/pull/15153 From stefank at openjdk.org Tue Aug 8 09:56:33 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 8 Aug 2023 09:56:33 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 11:28:50 GMT, Stefan Karlsson wrote: > I've found that our misc flags printing is broken. This can be seen in our hs_err files: > > RCX=0x00007f86bf0073c8 is a pointer to class: > java.lang.Class {0x00007f86bf0073c8} > - instance size: 22 > - klass size: 97 > - access: public final synchronized > - flags: ##name ##name ##name ##name ##name ##name > > > With this fix the flags are now printed as expected: > > java.util.Hashtable {0x00007f5fff00e8c0} > - instance size: 8 > - klass size: 123 > - access: public synchronized > - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method > > > The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. I've tweaked the output slightly so that it looks nicer: - access: public interface abstract - flags: rewritten is_shared_boot_class - state: linked Manually inspected the output of InstanceKlassFlags::print_on and MethodFlags::print_on. ConstMethod::print_on doesn't seem to be explicitly called. Also note that ConstMethod::print_on isn't an "override" because ConstMethod inherits from MetaspaceObj and not Metadata. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15153#issuecomment-1669299171 From mdoerr at openjdk.org Tue Aug 8 10:04:42 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 8 Aug 2023 10:04:42 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: <5j-qoK4YcY7h8xUGAGnrumzLQ3pWplhlGesEEhV6MFA=.987f91c3-e920-4b3a-b961-b54baadb758e@github.com> On Tue, 8 Aug 2023 05:39:04 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation > > Signed-off-by: Sidraya src/hotspot/cpu/s390/downcallLinker_s390.cpp line 95: > 93: > 94: static const int native_invoker_code_base_size = 384; > 95: static const int native_invoker_size_per_args = 8; Sizes were taken from PPC64. Are they correct for s390? src/hotspot/cpu/s390/downcallLinker_s390.cpp line 156: > 154: #endif > 155: > 156: int allocated_frame_size = 0; Line not needed. src/hotspot/cpu/s390/downcallLinker_s390.cpp line 163: > 161: assert(!_needs_return_buffer, "unexpected needs_return_buffer"); > 162: RegSpiller out_reg_spiller(_output_registers); > 163: int spill_offset = -1; Line not needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286895276 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286897339 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286897502 From mdoerr at openjdk.org Tue Aug 8 10:30:41 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 8 Aug 2023 10:30:41 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 05:39:04 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation > > Signed-off-by: Sidraya src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 130: > 128: } > 129: switch (to_reg.stack_size()) { > 130: case 8: __ reg2mem_opt(as_Register(from_reg), Address(Z_SP, reg2offset(to_reg, out_bias)), true);break; Coding style: Spaces missing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286924775 From mdoerr at openjdk.org Tue Aug 8 10:35:39 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 8 Aug 2023 10:35:39 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 05:39:04 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation > > Signed-off-by: Sidraya src/hotspot/cpu/s390/upcallLinker_s390.cpp line 118: > 116: > 117: static const int upcall_stub_code_base_size = 1536; // depends on GC (resolve_jobject) > 118: static const int upcall_stub_size_per_arg = 16; // arg save & restore + move Again sizes from PPC64. Should be checked! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286929336 From ogillespie at openjdk.org Tue Aug 8 10:47:50 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 8 Aug 2023 10:47:50 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg Message-ID: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> According to the JNI spec for NewWeakGlobalRef: > Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) ------------- Commit messages: - 8313874 - JNI NewWeakGlobalRef throws exception for null arg Changes: https://git.openjdk.org/jdk/pull/15188/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15188&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313874 Stats: 42 lines in 3 files changed: 41 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15188/head:pull/15188 PR: https://git.openjdk.org/jdk/pull/15188 From mdoerr at openjdk.org Tue Aug 8 10:48:40 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 8 Aug 2023 10:48:40 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 05:39:04 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation > > Signed-off-by: Sidraya I couldn't spot real bugs, but sizes should get determined. (+ Possibly a bit more cleanup.) ------------- PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1567019061 From coleenp at openjdk.org Tue Aug 8 11:50:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 11:50:31 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names [v2] In-Reply-To: References: Message-ID: <1P8xDUNdkDnCrHP8bNMAvmq883JyWbto6iHUIuVxL_s=.5c9badee-553d-456f-9268-c472ae0c7bfa@github.com> On Tue, 8 Aug 2023 09:54:49 GMT, Stefan Karlsson wrote: >> I've found that our misc flags printing is broken. This can be seen in our hs_err files: >> >> RCX=0x00007f86bf0073c8 is a pointer to class: >> java.lang.Class {0x00007f86bf0073c8} >> - instance size: 22 >> - klass size: 97 >> - access: public final synchronized >> - flags: ##name ##name ##name ##name ##name ##name >> >> >> With this fix the flags are now printed as expected: >> >> java.util.Hashtable {0x00007f5fff00e8c0} >> - instance size: 8 >> - klass size: 123 >> - access: public synchronized >> - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method >> >> >> The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Tweak ouput Thank you for fixing the leading blanks in the 3 places. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15153#pullrequestreview-1567115413 From coleenp at openjdk.org Tue Aug 8 11:54:43 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 11:54:43 GMT Subject: RFR: 8313785: Fix -Wconversion warnings in prims code [v2] In-Reply-To: References: Message-ID: On Sat, 5 Aug 2023 16:21:57 GMT, Coleen Phillimore wrote: >> This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). >> int field_offset (int index) const { return field(index).offset(); } >> >> So when we get the field offset back, it's an int. >> >> Also stackwalker passes jlong, so made that consistent. >> >> Tested with tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Dean's suggested changes. Thanks for the reviews and comments Serguei, Dean and David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15160#issuecomment-1669466004 From coleenp at openjdk.org Tue Aug 8 11:54:44 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 11:54:44 GMT Subject: Integrated: 8313785: Fix -Wconversion warnings in prims code In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 14:37:07 GMT, Coleen Phillimore wrote: > This patch fixes Wconversion in code in the src/hotspot/share/prims directory. Most of the changes correct the types. jfieldID's are created with the int offset returned by InstanceKlass::field_offset(). > int field_offset (int index) const { return field(index).offset(); } > > So when we get the field offset back, it's an int. > > Also stackwalker passes jlong, so made that consistent. > > Tested with tier1 on Oracle supported platforms. This pull request has now been integrated. Changeset: 8752d498 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/8752d4984a762393ffbe53181e07ce254df2cd19 Stats: 38 lines in 11 files changed: 5 ins; 2 del; 31 mod 8313785: Fix -Wconversion warnings in prims code Reviewed-by: sspitsyn, dlong ------------- PR: https://git.openjdk.org/jdk/pull/15160 From stefank at openjdk.org Tue Aug 8 12:04:29 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 8 Aug 2023 12:04:29 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 10:40:30 GMT, Oli Gillespie wrote: > or if obj was a weak global reference There's no check to see if `obj` is a weak global reference in this function. Is that also an oversight or is the spec just weirdly phrased? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15188#issuecomment-1669480369 From dholmes at openjdk.org Tue Aug 8 12:08:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Aug 2023 12:08:32 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 10:40:30 GMT, Oli Gillespie wrote: > According to the JNI spec for NewWeakGlobalRef: > >> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. > > The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. > > (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) Changes requested by dholmes (Reviewer). src/hotspot/share/prims/jni.cpp line 2879: > 2877: Handle ref_handle(thread, JNIHandles::resolve(ref)); > 2878: jweak ret = JNIHandles::make_weak_global(ref_handle, AllocFailStrategy::RETURN_NULL); > 2879: if (ret == nullptr && ref_handle != nullptr) { That isn't how you check a Handle for null content - you need `!ref_handle.is_null()`. test/hotspot/jtreg/runtime/jni/NullJNIWeak/NullJNIWeak.java line 1: > 1: /* Is there not an existing test we can simply add the null case to? ------------- PR Review: https://git.openjdk.org/jdk/pull/15188#pullrequestreview-1567143282 PR Review Comment: https://git.openjdk.org/jdk/pull/15188#discussion_r1287020371 PR Review Comment: https://git.openjdk.org/jdk/pull/15188#discussion_r1287020998 From coleenp at openjdk.org Tue Aug 8 12:15:37 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 12:15:37 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 09:22:12 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Review comments applied. This looks good with the minor issue of removing a blank space. src/hotspot/share/runtime/globals.hpp line 1590: > 1588: "switch") \ > 1589: \ > 1590: develop(intx, StopInterpreterAt, 0, \ Does this add a blank? Should be aligned. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1567155588 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1287028124 From dholmes at openjdk.org Tue Aug 8 12:17:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Aug 2023 12:17:31 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 12:01:23 GMT, Stefan Karlsson wrote: > There's no check to see if obj is a weak global reference in this function. I'm not even sure what that means. Are `jweak` and `jobject` interchangeable i.e we should detect: jweak j = env->NewWeakGlobalRef(env, env->NewWeakGlobalRef(env, obj)); ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15188#issuecomment-1669499644 From azafari at openjdk.org Tue Aug 8 12:21:53 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 8 Aug 2023 12:21:53 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v3] In-Reply-To: References: Message-ID: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: backslash aligned ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15164/files - new: https://git.openjdk.org/jdk/pull/15164/files/1fe96046..d88a1238 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15164/head:pull/15164 PR: https://git.openjdk.org/jdk/pull/15164 From stefank at openjdk.org Tue Aug 8 12:30:30 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 8 Aug 2023 12:30:30 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 10:40:30 GMT, Oli Gillespie wrote: > According to the JNI spec for NewWeakGlobalRef: > >> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. > > The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. > > (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) I don't see why `env->NewWeakGlobalRef(env, env->NewWeakGlobalRef(env, obj));` should return NULL, but it sounds to me like that's what the spec asks for. My guess is that the spec is ill-worded. You can pass `jweak`s as `jobject`s. `JNIHandles::resolve` will apply the correct GC barriers depending on the underlying handle. @kimbarrett implemented that support by adding tagged bits to the handles. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15188#issuecomment-1669517632 From kbarrett at openjdk.org Tue Aug 8 12:40:30 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 8 Aug 2023 12:40:30 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 10:40:30 GMT, Oli Gillespie wrote: > According to the JNI spec for NewWeakGlobalRef: > >> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. > > The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. > > (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) Changes requested by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15188#pullrequestreview-1567172754 From stefank at openjdk.org Tue Aug 8 12:40:31 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 8 Aug 2023 12:40:31 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 10:40:30 GMT, Oli Gillespie wrote: > According to the JNI spec for NewWeakGlobalRef: > >> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. > > The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. > > (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) I see that the spec further down says: `obj was a weak global reference and has already been garbage collected` So, it is just the first `obj was a weak global reference` occurrence that is ill-worded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15188#issuecomment-1669531678 From kbarrett at openjdk.org Tue Aug 8 12:40:33 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 8 Aug 2023 12:40:33 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 12:05:12 GMT, David Holmes wrote: >> According to the JNI spec for NewWeakGlobalRef: >> >>> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. >> >> The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. >> >> (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) > > src/hotspot/share/prims/jni.cpp line 2879: > >> 2877: Handle ref_handle(thread, JNIHandles::resolve(ref)); >> 2878: jweak ret = JNIHandles::make_weak_global(ref_handle, AllocFailStrategy::RETURN_NULL); >> 2879: if (ret == nullptr && ref_handle != nullptr) { > > That isn't how you check a Handle for null content - you need `!ref_handle.is_null()`. even better would be `ref_handle.not_null()`. Though I think the comparison does work. > test/hotspot/jtreg/runtime/jni/NullJNIWeak/NullJNIWeak.java line 1: > >> 1: /* > > Is there not an existing test we can simply add the null case to? Agree that adding this to some existing test might be preferable. Maybe another subtest (see main) in runtime/jni/ReturnJNIWeak? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15188#discussion_r1287039034 PR Review Comment: https://git.openjdk.org/jdk/pull/15188#discussion_r1287049972 From stuefe at openjdk.org Tue Aug 8 12:47:41 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 12:47:41 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> Message-ID: <-a19PIlaG91QKPcRDljz2QmfWujugzpzKCXvr_Uxc70=.6a9559cb-de99-48e5-aa1e-d00646743044@github.com> On Tue, 8 Aug 2023 08:46:41 GMT, Richard Startin wrote: >> @richardstartin About async-safety: all supported (jit) architectures use static assembly as @theRealAph pointed out, these should be signal safe. The code snippet you found is only used by zero. You are probably not concerned with zero. And even there, yes, we longjmp out of signal handling, since there is no other way to implement SafeFetch in zero. That is technically async-sig-unsafe, but in practice it works and is tested for use in signal handlers. >> >> About safety, @fisk is right in that this is still not completely safe since Method (and any of the objects chained to it that AGCT implicitly relies on being there, e.g. ConstMethod) can get out of scope while AGCT uses them. > > @tstuefe @fisk I hadn't appreciated that the cause was probably concurrent method unloading, we don't have a core dump, just the backtrace from the crash and the disassembly from objdump, so all I knew was that the pointer was null but not why. This is not the sort of thing that reproduces readily. I don't have as much context about the adjacent JVM mechanisms as others in this thread and am just trying to fix a crash based on the evidence I have. > > This pointer being null seems to be a symptom rather than a cause and it doesn't appear there's anything we can do about concurrent method unloading interfering with AsyncGetCallTrace, so I wonder how worthwhile attempting to fix this is. On the one hand it will crash another way sometimes, on the other hand the probability of this happening is significantly reduced to the subsequent usages of the pointer, whereas that window of time for unloading a method to cause a crash in AsyncGetCallTrace is currently the duration of the unwind preceding the current frame. Let me know what you think about proceeding and I'll submit a fix with the null check which would have been sufficient to avoid the observed segfault. Thanks. @richardstartin I definitely think a patch in the propsed form - first check for NULL, then check again with SafeFetch - makes a lot of sense. Not perfect, but it will reduce the chance of crashes happening. And it is very simple and backportable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1287064701 From stuefe at openjdk.org Tue Aug 8 12:49:31 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 12:49:31 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 09:54:49 GMT, Stefan Karlsson wrote: >> I've found that our misc flags printing is broken. This can be seen in our hs_err files: >> >> RCX=0x00007f86bf0073c8 is a pointer to class: >> java.lang.Class {0x00007f86bf0073c8} >> - instance size: 22 >> - klass size: 97 >> - access: public final synchronized >> - flags: ##name ##name ##name ##name ##name ##name >> >> >> With this fix the flags are now printed as expected: >> >> java.util.Hashtable {0x00007f5fff00e8c0} >> - instance size: 8 >> - klass size: 123 >> - access: public synchronized >> - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method >> >> >> The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Tweak ouput Still good ------------- PR Comment: https://git.openjdk.org/jdk/pull/15153#issuecomment-1669545133 From shade at openjdk.org Tue Aug 8 13:20:34 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 8 Aug 2023 13:20:34 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 09:54:49 GMT, Stefan Karlsson wrote: >> I've found that our misc flags printing is broken. This can be seen in our hs_err files: >> >> RCX=0x00007f86bf0073c8 is a pointer to class: >> java.lang.Class {0x00007f86bf0073c8} >> - instance size: 22 >> - klass size: 97 >> - access: public final synchronized >> - flags: ##name ##name ##name ##name ##name ##name >> >> >> With this fix the flags are now printed as expected: >> >> java.util.Hashtable {0x00007f5fff00e8c0} >> - instance size: 8 >> - klass size: 123 >> - access: public synchronized >> - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method >> >> >> The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Tweak ouput Still fine. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15153#pullrequestreview-1567281638 From ogillespie at openjdk.org Tue Aug 8 13:20:57 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 8 Aug 2023 13:20:57 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 10:40:30 GMT, Oli Gillespie wrote: > According to the JNI spec for NewWeakGlobalRef: > >> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. > > The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. > > (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) Updated the null check and moved the test to an existing file, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15188#issuecomment-1669594535 From ogillespie at openjdk.org Tue Aug 8 13:20:55 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 8 Aug 2023 13:20:55 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg [v2] In-Reply-To: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: <7IOJ9HRfGvZJ_SD6hmIWbMpVxvfFFQqiAsfW85o2iDs=.d7f39560-252f-4b73-822d-dfce60f344e0@github.com> > According to the JNI spec for NewWeakGlobalRef: > >> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. > > The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. > > (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: Review feedback Move test case to existing test, use .not_null() for null check. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15188/files - new: https://git.openjdk.org/jdk/pull/15188/files/87ab7c9e..69ab3c4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15188&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15188&range=00-01 Stats: 52 lines in 4 files changed: 10 ins; 41 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15188.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15188/head:pull/15188 PR: https://git.openjdk.org/jdk/pull/15188 From jbechberger at openjdk.org Tue Aug 8 13:47:42 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 8 Aug 2023 13:47:42 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: <-a19PIlaG91QKPcRDljz2QmfWujugzpzKCXvr_Uxc70=.6a9559cb-de99-48e5-aa1e-d00646743044@github.com> References: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> <-a19PIlaG91QKPcRDljz2QmfWujugzpzKCXvr_Uxc70=.6a9559cb-de99-48e5-aa1e-d00646743044@github.com> Message-ID: On Tue, 8 Aug 2023 12:44:35 GMT, Thomas Stuefe wrote: >> @tstuefe @fisk I hadn't appreciated that the cause was probably concurrent method unloading, we don't have a core dump, just the backtrace from the crash and the disassembly from objdump, so all I knew was that the pointer was null but not why. This is not the sort of thing that reproduces readily. I don't have as much context about the adjacent JVM mechanisms as others in this thread and am just trying to fix a crash based on the evidence I have. >> >> This pointer being null seems to be a symptom rather than a cause and it doesn't appear there's anything we can do about concurrent method unloading interfering with AsyncGetCallTrace, so I wonder how worthwhile attempting to fix this is. On the one hand it will crash another way sometimes, on the other hand the probability of this happening is significantly reduced to the subsequent usages of the pointer, whereas that window of time for unloading a method to cause a crash in AsyncGetCallTrace is currently the duration of the unwind preceding the current frame. Let me know what you think about proceeding and I'll submit a fix with the null check which would have been sufficient to avoid the observed segfault. Thanks. > > @richardstartin I definitely think a patch in the propsed form - first check for NULL, then check again with SafeFetch - makes a lot of sense. Not perfect, but it will reduce the chance of crashes happening. And it is very simple and backportable. Hardening the API is always a good idea, especially if it doesn't have a performance impact. We generally don't know in which state ASGCT is called. I added comparable checks at many places before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1287146823 From aboldtch at openjdk.org Tue Aug 8 13:55:34 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 8 Aug 2023 13:55:34 GMT Subject: RFR: 8311508: ZGC: RAII use of IntelJccErratumAlignment Message-ID: Fixed the locations where unnamed IntelJccErratumAlignment circumvented the correctness asserts. Also strengthened the asserts so that a IntelJccErratumAlignment RAII object scope must surround at least some instruction. Tested GHA and tier1,tier2 ------------- Commit messages: - 8311508: ZGC: RAII use of IntelJccErratumAlignment Changes: https://git.openjdk.org/jdk/pull/15191/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311508 Stats: 6 lines in 3 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15191.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15191/head:pull/15191 PR: https://git.openjdk.org/jdk/pull/15191 From stefank at openjdk.org Tue Aug 8 15:28:31 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 8 Aug 2023 15:28:31 GMT Subject: RFR: 8311508: ZGC: RAII use of IntelJccErratumAlignment In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 13:49:24 GMT, Axel Boldt-Christmas wrote: > Fixed the locations where unnamed IntelJccErratumAlignment circumvented the correctness asserts. > Also strengthened the asserts so that a IntelJccErratumAlignment RAII object scope must surround at least some instruction. > > Tested GHA and tier1,tier2 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15191#pullrequestreview-1567571924 From shade at openjdk.org Tue Aug 8 15:45:30 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 8 Aug 2023 15:45:30 GMT Subject: RFR: 8311508: ZGC: RAII use of IntelJccErratumAlignment In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 13:49:24 GMT, Axel Boldt-Christmas wrote: > Fixed the locations where unnamed IntelJccErratumAlignment circumvented the correctness asserts. > Also strengthened the asserts so that a IntelJccErratumAlignment RAII object scope must surround at least some instruction. > > Tested GHA and tier1,tier2 Looks fine. There is no functional change, only the assert that verifies the destructor actually runs after the "protected" instructions emitted. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15191#pullrequestreview-1567604075 From kbarrett at openjdk.org Tue Aug 8 17:12:31 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 8 Aug 2023 17:12:31 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg [v2] In-Reply-To: <7IOJ9HRfGvZJ_SD6hmIWbMpVxvfFFQqiAsfW85o2iDs=.d7f39560-252f-4b73-822d-dfce60f344e0@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> <7IOJ9HRfGvZJ_SD6hmIWbMpVxvfFFQqiAsfW85o2iDs=.d7f39560-252f-4b73-822d-dfce60f344e0@github.com> Message-ID: On Tue, 8 Aug 2023 13:20:55 GMT, Oli Gillespie wrote: >> According to the JNI spec for NewWeakGlobalRef: >> >>> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. >> >> The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. >> >> (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback > > Move test case to existing test, use .not_null() for null check. Looks good. It's weird that NewWeakGlobalRef throws on OOM, but NewGlobalRef doesn't. But that's what the spec says. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15188#pullrequestreview-1567783874 From duke at openjdk.org Tue Aug 8 17:55:42 2023 From: duke at openjdk.org (Richard Startin) Date: Tue, 8 Aug 2023 17:55:42 GMT Subject: RFR: 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: References: <6m1I71xjmmNXir3bB5nxSQc7xgj4VlPzMfAAiXFMrBk=.13ea32fc-7c5f-47df-bf64-d8808752aa44@github.com> <-a19PIlaG91QKPcRDljz2QmfWujugzpzKCXvr_Uxc70=.6a9559cb-de99-48e5-aa1e-d00646743044@github.com> Message-ID: On Tue, 8 Aug 2023 13:45:11 GMT, Johannes Bechberger wrote: >> @richardstartin I definitely think a patch in the propsed form - first check for NULL, then check again with SafeFetch - makes a lot of sense. Not perfect, but it will reduce the chance of crashes happening. And it is very simple and backportable. > > Hardening the API is always a good idea, especially if it doesn't have a performance impact. We generally don't know in which state ASGCT is called. I added comparable checks at many places before. I prepared a new patch incorporating the suggestions made in this thread, which seems more straightforward to review given the force push and having gone round in circles #15193 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15178#discussion_r1287467665 From duke at openjdk.org Tue Aug 8 17:56:40 2023 From: duke at openjdk.org (Richard Startin) Date: Tue, 8 Aug 2023 17:56:40 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer Message-ID: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Makes AsyncGetCallTrace more resilient to method unloading. ------------- Commit messages: - JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer Changes: https://git.openjdk.org/jdk/pull/15193/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313796 Stats: 45 lines in 5 files changed: 39 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15193/head:pull/15193 PR: https://git.openjdk.org/jdk/pull/15193 From coleenp at openjdk.org Tue Aug 8 18:02:33 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 18:02:33 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer In-Reply-To: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: <8pCauDJsDU2uVXUvWY4--RxW4hmjnBgaFMTMhmJ715I=.8569e4ef-df8b-435e-b463-86a67817df8e@github.com> On Tue, 8 Aug 2023 15:02:59 GMT, Richard Startin wrote: > Makes AsyncGetCallTrace more resilient to method unloading. Can you add a new function like frame::interpreter_frame_method_safe() or frame::safe_interpreter_frame_method() and put this code in shared/runtime ? ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15193#pullrequestreview-1567857612 From duke at openjdk.org Tue Aug 8 18:36:01 2023 From: duke at openjdk.org (Richard Startin) Date: Tue, 8 Aug 2023 18:36:01 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v2] In-Reply-To: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: > Makes AsyncGetCallTrace more resilient to method unloading. Richard Startin has updated the pull request incrementally with one additional commit since the last revision: DRY ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15193/files - new: https://git.openjdk.org/jdk/pull/15193/files/72e4ab71..6a257d4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=00-01 Stats: 63 lines in 7 files changed: 15 ins; 41 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15193/head:pull/15193 PR: https://git.openjdk.org/jdk/pull/15193 From erikj at openjdk.org Tue Aug 8 18:41:34 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 8 Aug 2023 18:41:34 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: <22KaxTbA_XWZS28f7xM5oEXoZhlNttZvNNNnc66Mi-c=.0e98ec5f-7a47-41f1-b65b-37c0ac81d308@github.com> On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Build change looks ok. ------------- PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1567918097 From duke at openjdk.org Tue Aug 8 18:49:35 2023 From: duke at openjdk.org (Richard Startin) Date: Tue, 8 Aug 2023 18:49:35 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v3] In-Reply-To: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: > Makes AsyncGetCallTrace more resilient to method unloading. Richard Startin has updated the pull request incrementally with three additional commits since the last revision: - revert unnecessary whitespace changes - revert yet another unnecessary change - revert unnecessary change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15193/files - new: https://git.openjdk.org/jdk/pull/15193/files/6a257d4b..86813482 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=01-02 Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15193/head:pull/15193 PR: https://git.openjdk.org/jdk/pull/15193 From aph at openjdk.org Tue Aug 8 18:49:37 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 8 Aug 2023 18:49:37 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v2] In-Reply-To: References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: On Tue, 8 Aug 2023 18:36:01 GMT, Richard Startin wrote: >> Makes AsyncGetCallTrace more resilient to method unloading. > > Richard Startin has updated the pull request incrementally with one additional commit since the last revision: > > DRY Great, thanks. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15193#pullrequestreview-1567922128 From coleenp at openjdk.org Tue Aug 8 18:58:34 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 18:58:34 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 11:21:27 GMT, Oli Gillespie wrote: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) This is a really good analysis and find. I'm wondering if it would be cleaner for the LookupFunction class to have an is_dead() function to return whether the entry is dead, rather than calling equals. The call to equals is surprising in delete_in_bucket. The reason that the Lookup class increments refcount is that it has the is_dead return, so needs to keep the entry alive at that point. Also, Symbol refcounts going to zero in a surprising manner is a source of frequent bugs. Moving that to the Get class (SymbolTableGet) might be too late - ie something may have discovered that the refcount went to zero before incrementing it. SymbolTable::try_increment_refcount() will fail if the refcount is already zero and we don't want lookup to find that entry. Can you see if adding a is_dead() function looks nicer here? The remove_entry() case doesn't matter because we're removing the entry anyway, I believe. ------------- PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1567941355 From erikj at openjdk.org Tue Aug 8 19:00:36 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 8 Aug 2023 19:00:36 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/6d476cbe...51230f3d Build change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15096#pullrequestreview-1567944297 From coleenp at openjdk.org Tue Aug 8 19:33:38 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 19:33:38 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v3] In-Reply-To: References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: On Tue, 8 Aug 2023 18:49:35 GMT, Richard Startin wrote: >> Makes AsyncGetCallTrace more resilient to method unloading. > > Richard Startin has updated the pull request incrementally with three additional commits since the last revision: > > - revert unnecessary whitespace changes > - revert yet another unnecessary change > - revert unnecessary change This looks good. Thank you for taking my suggestion. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15193#pullrequestreview-1568014138 From stuefe at openjdk.org Tue Aug 8 19:54:36 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 19:54:36 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 08:14:41 GMT, Julian Waters wrote: >> There are currently only 2 possible types of HMODULE and char/uint8_t for T at the moment. Weirdly enough only line 126 errors out without the cast while line 114, despite having the same problem, doesn't, but I added the cast to both lines for consistency. If someone else knows why I could probably deal with this code in a better way besides just casting it to T (which I also am reluctant to do) > > I just checked and the value of the sentinel is ultimately the prvalue 88. I don't know if we'd want to replace all the weird char usages here with explicit values of 0 (and 88 for the sentinel). Maybe future reviews can help with that I wrote this code ages ago. I'm not sure what's weird or suspicious about it, though. The comment at the file's beginning explains this code's motivation. The buffer was never thought to be used for something different than HANDLEs or characters, where the assignment of integer literals work. I often use char constants for sentinels as debugging aid. As for `'\0'`, that indicates to the casual code reader that this is a termination of a string, better than had I used a plain 0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287626062 From coleenp at openjdk.org Tue Aug 8 19:56:32 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 19:56:32 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v3] In-Reply-To: References: Message-ID: <_CxHiiiT_x4tgRPapxwPdWdQWZcQ-3CATphJzpgf2VA=.1d2e1b54-4dcb-4a0b-ba9d-6fe08aed5d33@github.com> On Tue, 8 Aug 2023 12:21:53 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > backslash aligned Hi, I thought you were going to change this one too: LogEventsBufferEntries ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1670221262 From coleenp at openjdk.org Tue Aug 8 20:09:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Aug 2023 20:09:56 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: > Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. > > src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] > 1802 | _thread->dec_held_monitor_count(rec + 1); > | ~~~~^~~ > > Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Make bytecode.hpp index() functions return u2 not long. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15177/files - new: https://git.openjdk.org/jdk/pull/15177/files/4eeeb165..a77884e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177 PR: https://git.openjdk.org/jdk/pull/15177 From dlong at openjdk.org Tue Aug 8 20:13:31 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 8 Aug 2023 20:13:31 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com> On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. src/hotspot/share/runtime/arguments.cpp line 1215: > 1213: } > 1214: } > 1215: c = getc(stream); How about int c0 for the getc value, then the first line in the loop does char c = checked_cast(c0); No other changes should be needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287641580 From stuefe at openjdk.org Tue Aug 8 20:22:42 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 20:22:42 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/c9dcbf20...51230f3d Hi Julian, Cursory review. I stopped halfway in when I noticed that I had no idea why many of the changes were done. They did not seem to have an obvious connection to the title of the JBS, and I did not find an explanation. I also find the usage of "monstrosities" unnecessary. It is very much a matter of taste - to me, nothing in the code you changed looks monstrous. Cheers, Thomas src/hotspot/os/windows/os_windows.cpp line 2888: > 2886: LONG WINAPI topLevelUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo) { > 2887: if (!InterceptOSException) { > 2888: DWORD exception_code = exceptionInfo->ExceptionRecord->ExceptionCode; I find this less clearer than the original code, that didn't use negation - it was clear that InterceptOSException leads to immediate bailout. What is the problem, the goto? Is that just your personal taste, or is the compiler complaining? If the latter, I would vote for duplicating the return statement here (and this would count as an example where discarding out-of-fashion statements like goto actually makes the code worse). src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 216: > 214: { > 215: PDATA pData; > 216: JNI_CHECK_PEER_GOTO(canvas, ret); Here, and other places: why this scope? src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp line 48: > 46: > 47: #include "jlong.h" > 48: #include "awt.h" Why the reordering of includes? src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp line 34: > 32: #include "sun_awt_windows_WDropTargetContextPeer.h" > 33: #include "awt_Container.h" > 34: #include "awt_ole.h" Why? ------------- PR Review: https://git.openjdk.org/jdk/pull/15096#pullrequestreview-1568088318 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287629714 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287630358 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287631591 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287632623 From stuefe at openjdk.org Tue Aug 8 20:26:33 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 20:26:33 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v3] In-Reply-To: References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: On Tue, 8 Aug 2023 18:49:35 GMT, Richard Startin wrote: >> Makes AsyncGetCallTrace more resilient to method unloading. > > Richard Startin has updated the pull request incrementally with three additional commits since the last revision: > > - revert unnecessary whitespace changes > - revert yet another unnecessary change > - revert unnecessary change Small nit, otherwise good. src/hotspot/share/runtime/frame.cpp line 311: > 309: } > 310: Method* m = (Method*) SafeFetchN((intptr_t*) m_addr, 0); > 311: if (m == 0) { Small nits: - nullptr instead of 0 - you can just return m. Its either nullptr or the Method. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15193#pullrequestreview-1568124446 PR Review Comment: https://git.openjdk.org/jdk/pull/15193#discussion_r1287652156 From stuefe at openjdk.org Tue Aug 8 20:56:37 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 8 Aug 2023 20:56:37 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/59027534...51230f3d I think I see now that the added scopes were to prevent variable life scopes from intersecting goto's? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1670293563 From duke at openjdk.org Tue Aug 8 20:59:34 2023 From: duke at openjdk.org (Richard Startin) Date: Tue, 8 Aug 2023 20:59:34 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v4] In-Reply-To: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: > Makes AsyncGetCallTrace more resilient to method unloading. Richard Startin has updated the pull request incrementally with one additional commit since the last revision: nits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15193/files - new: https://git.openjdk.org/jdk/pull/15193/files/86813482..bfb3ff59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15193/head:pull/15193 PR: https://git.openjdk.org/jdk/pull/15193 From dholmes at openjdk.org Tue Aug 8 21:06:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Aug 2023 21:06:33 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg [v2] In-Reply-To: References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 12:22:38 GMT, Kim Barrett wrote: >> src/hotspot/share/prims/jni.cpp line 2879: >> >>> 2877: Handle ref_handle(thread, JNIHandles::resolve(ref)); >>> 2878: jweak ret = JNIHandles::make_weak_global(ref_handle, AllocFailStrategy::RETURN_NULL); >>> 2879: if (ret == nullptr && ref_handle != nullptr) { >> >> That isn't how you check a Handle for null content - you need `!ref_handle.is_null()`. > > even better would be `ref_handle.not_null()`. Though I think the comparison does work. Yes it seems that some implicit Handle conversions were removed at some point which now makes direct comparison to `nullptr` allowable - somewhat obsolescing the `is_null()/not_null()` helper methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15188#discussion_r1287687902 From duke at openjdk.org Tue Aug 8 21:10:57 2023 From: duke at openjdk.org (Richard Startin) Date: Tue, 8 Aug 2023 21:10:57 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v3] In-Reply-To: References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: <0mxN8v-BhpSgk4QVPMIWY73N2sbkLynHyFzoiqf8_AU=.721d93ad-179b-4f11-a98f-65c767f9f591@github.com> On Tue, 8 Aug 2023 20:23:21 GMT, Thomas Stuefe wrote: >> Richard Startin has updated the pull request incrementally with three additional commits since the last revision: >> >> - revert unnecessary whitespace changes >> - revert yet another unnecessary change >> - revert unnecessary change > > src/hotspot/share/runtime/frame.cpp line 311: > >> 309: } >> 310: Method* m = (Method*) SafeFetchN((intptr_t*) m_addr, 0); >> 311: if (m == 0) { > > Small nits: > - nullptr instead of 0 > - you can just return m. Its either nullptr or the Method. This didn't compile: `error: cannot convert 'std::nullptr_t' to 'intptr_t' {aka 'long int'}` - I put it back to the literal 0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15193#discussion_r1287689704 From duke at openjdk.org Tue Aug 8 21:10:53 2023 From: duke at openjdk.org (Richard Startin) Date: Tue, 8 Aug 2023 21:10:53 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v5] In-Reply-To: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: <1y4jGhKb5JXPJZIwZFMS-WIaGGbxHFZsEVPXUcaOdkw=.6cc92de4-3a52-418f-b20f-a3dea4c331db@github.com> > Makes AsyncGetCallTrace more resilient to method unloading. Richard Startin has updated the pull request incrementally with one additional commit since the last revision: nullptr can't be converted to intptr_t ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15193/files - new: https://git.openjdk.org/jdk/pull/15193/files/bfb3ff59..ad96b72f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15193&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15193.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15193/head:pull/15193 PR: https://git.openjdk.org/jdk/pull/15193 From dlong at openjdk.org Tue Aug 8 21:12:32 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 8 Aug 2023 21:12:32 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. src/hotspot/share/runtime/arguments.cpp line 1667: > 1665: > 1666: if (InitialHeapSize == 0) { > 1667: julong reasonable_initial = (julong)((phys_mem * (julong)InitialRAMPercentage) / 100); This and the two changes above loses the fractional part. Suggestion: julong reasonable_initial = (julong)((double)phys_mem * InitialRAMPercentage / 100.0); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287692376 From dlong at openjdk.org Tue Aug 8 21:16:31 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 8 Aug 2023 21:16:31 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. src/hotspot/share/runtime/arguments.cpp line 2738: > 2736: } > 2737: > 2738: if (FLAG_SET_CMDLINE(MaxTenuringThreshold, (uint)max_tenuring_thresh) != JVMFlag::SUCCESS) { MaxTenuringThreshold was recently changed to uint, so it would make sense change uintx above to uint. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287695274 From dlong at openjdk.org Tue Aug 8 21:31:34 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 8 Aug 2023 21:31:34 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. src/hotspot/share/runtime/deoptimization.cpp line 255: > 253: result += frame_sizes()[index]; > 254: } > 255: return checked_cast(result); Isn't _caller_adjustment already an int? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287706980 From dlong at openjdk.org Tue Aug 8 21:41:33 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 8 Aug 2023 21:41:33 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: <8svWRRP4NxnJb2S-I0zP_q5TVuptLBsAp095rNoMo1Y=.8cfde906-5c79-46b5-b9be-adf5c12b3cc9@github.com> On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. src/hotspot/share/runtime/java.hpp line 108: > 106: > 107: // Factory methods for convenience > 108: static JDK_Version jdk(int m) { Finally, support for JDK 256 and beyond! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287713839 From dlong at openjdk.org Tue Aug 8 22:03:33 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 8 Aug 2023 22:03:33 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. src/hotspot/share/runtime/objectMonitor.hpp line 238: > 236: // > 237: #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \ > 238: ((in_bytes(ObjectMonitor::f ## _offset())) - (unsigned)markWord::monitor_value) This makes it int vs uint (-Wsign-conversion warning), and assumes the range of monitor_value. One option is to narrow the type of monitor_value. Option 2, cast the lhs to uintptr_t. Option 3, use offset_of instead of signed ByteSize. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287727808 From jbechberger at openjdk.org Tue Aug 8 22:08:32 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 8 Aug 2023 22:08:32 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v3] In-Reply-To: <0mxN8v-BhpSgk4QVPMIWY73N2sbkLynHyFzoiqf8_AU=.721d93ad-179b-4f11-a98f-65c767f9f591@github.com> References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> <0mxN8v-BhpSgk4QVPMIWY73N2sbkLynHyFzoiqf8_AU=.721d93ad-179b-4f11-a98f-65c767f9f591@github.com> Message-ID: On Tue, 8 Aug 2023 21:05:57 GMT, Richard Startin wrote: >> src/hotspot/share/runtime/frame.cpp line 311: >> >>> 309: } >>> 310: Method* m = (Method*) SafeFetchN((intptr_t*) m_addr, 0); >>> 311: if (m == 0) { >> >> Small nits: >> - nullptr instead of 0 >> - you can just return m. Its either nullptr or the Method. > > This didn't compile: `error: cannot convert 'std::nullptr_t' to 'intptr_t' {aka 'long int'}` - I put it back to the literal 0. `(void*)nullptr` is probably best, with `0` it is not directly obvious, that it is a pointer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15193#discussion_r1287731081 From pchilanomate at openjdk.org Tue Aug 8 22:17:39 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 8 Aug 2023 22:17:39 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com> On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. src/hotspot/share/runtime/os.cpp line 143: > 141: milliseconds_since_19700101 / milliseconds_per_microsecond; > 142: const int milliseconds_after_second = > 143: checked_cast(milliseconds_since_19700101 % milliseconds_per_microsecond); Not related to this change but seems milliseconds_per_microsecond should be named milliseconds_per_second. src/hotspot/share/runtime/safepoint.cpp line 98: > 96: int initial_number_of_threads, > 97: int threads_waiting_to_block, > 98: int iterations) { Maybe leave iterations as unsigned and change the caller instead? src/hotspot/share/runtime/sharedRuntime.cpp line 2348: > 2346: double sum = 0; > 2347: double weighted_sum = 0; > 2348: for (int i = 0; i <= n; i++) { sum += (double)histo[i]; weighted_sum += (double)(i*histo[i]); } So hist is a uint64_t*, why can't we make sum and weighted_sum just uint64_t? src/hotspot/share/runtime/threadHeapSampler.cpp line 359: > 357: "double and uint64_t do not have the same size"); > 358: x = *reinterpret_cast(&d); > 359: const uint32_t x_high = (uint32_t)(x >> 32); Can't we do a checked_cast here? The cast should be reversible with that shift value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287725795 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287728163 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287734252 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287733638 From dlong at openjdk.org Tue Aug 8 22:30:33 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 8 Aug 2023 22:30:33 GMT Subject: RFR: 8310239: Add missing cross modifying fence in nmethod entry barriers [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 08:26:08 GMT, Erik ?sterlund wrote: >> In fact, there is a current race in the nmethod entry barriers, where what we are doing violates the AMD APM (cf. APM volume 2 section 7.6.1 https://www.amd.com/system/files/TechDocs/24593.pdf). >> In particular, if the compare instruction of the nmethod entry barrier is not yet patched and we call a slow path on thread 1, then before taking the nmethod entry lock, another thread 2 could fix and disarm the nmethod. Then thread 1 will observe *data* suggesting the nmethod has been patched, but never re-executes the patched compare (which might indeed still be stale), hence not qualifying for asynchronous cross modifying code, and neither do we run a serializing cpuid instruction, qualifying for synchronous cross modifying code. In this scenario, we can indeed start executing the nmethod instructions, while observing inconsistent concurrent patching effects, where some instructions will be updated and some not. >> >> The following patch ensures that x86 nmethod entry barriers execute cross modifying fence after calling into the VM, where another thread could have disarmed the nmethod. I also ensured the other platforms perform their fencing after the VM call, instead of before - including a cross_modify_fence in the shared code for OSR nmethod entries. While fencing before will flush out the instruction pipeline, and it shouldn't be populated with problematic instructions until after we start executing the nmethod again, it feels unnecessary to fence on the wrong side of the modifications it wishes to guard, and hence not strictly following the synchronous cross modifying fence recipe. >> >> I'm currently running tier1-5 and running performance testing in aurora. In the interest of time, I'm opening this PR before getting the final result, and will report the results when they come in. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Typo in comment At first glance, this seems like an optimization to me, and not a correctness issue. At worst, we continue to execute the stale compare and go through the slow path unnecessarily. I don't think we are violating AMD APM, at least for the compare for the entry barrier. However, there may be a problem if what that barrier is protecting, the nmethod code, was patched in a way that is not concurrent-execution-safe. If that is the case, or just to be safe, then executing a serializing instruction seems like a good idea. But we don't do that for all threads. For any thread that sees the patched instruction, we will just take the fast path and not executed the serializing instruction. Does visibility of the patched entry point instruction as code imply all patching to the nmethod is also visible, as both data and instructions? I'm not convinced it does. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14543#issuecomment-1670399364 From aph at openjdk.org Wed Aug 9 00:18:38 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 9 Aug 2023 00:18:38 GMT Subject: RFR: 8310239: Add missing cross modifying fence in nmethod entry barriers [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 08:26:08 GMT, Erik ?sterlund wrote: >> In fact, there is a current race in the nmethod entry barriers, where what we are doing violates the AMD APM (cf. APM volume 2 section 7.6.1 https://www.amd.com/system/files/TechDocs/24593.pdf). >> In particular, if the compare instruction of the nmethod entry barrier is not yet patched and we call a slow path on thread 1, then before taking the nmethod entry lock, another thread 2 could fix and disarm the nmethod. Then thread 1 will observe *data* suggesting the nmethod has been patched, but never re-executes the patched compare (which might indeed still be stale), hence not qualifying for asynchronous cross modifying code, and neither do we run a serializing cpuid instruction, qualifying for synchronous cross modifying code. In this scenario, we can indeed start executing the nmethod instructions, while observing inconsistent concurrent patching effects, where some instructions will be updated and some not. >> >> The following patch ensures that x86 nmethod entry barriers execute cross modifying fence after calling into the VM, where another thread could have disarmed the nmethod. I also ensured the other platforms perform their fencing after the VM call, instead of before - including a cross_modify_fence in the shared code for OSR nmethod entries. While fencing before will flush out the instruction pipeline, and it shouldn't be populated with problematic instructions until after we start executing the nmethod again, it feels unnecessary to fence on the wrong side of the modifications it wishes to guard, and hence not strictly following the synchronous cross modifying fence recipe. >> >> I'm currently running tier1-5 and running performance testing in aurora. In the interest of time, I'm opening this PR before getting the final result, and will report the results when they come in. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Typo in comment Do we need an ISB on AArch64-specifc code? There, the guard value is data, not an immediate field. In other words, what instruction has just been patched that we need to make visible? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14543#issuecomment-1670473919 From coleenp at openjdk.org Wed Aug 9 00:58:32 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 00:58:32 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. Thank you Dean and Patricio for your comments on this change. ------------- PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1568509515 From coleenp at openjdk.org Wed Aug 9 00:58:37 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 00:58:37 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 21:09:30 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make bytecode.hpp index() functions return u2 not long. > > src/hotspot/share/runtime/arguments.cpp line 1667: > >> 1665: >> 1666: if (InitialHeapSize == 0) { >> 1667: julong reasonable_initial = (julong)((phys_mem * (julong)InitialRAMPercentage) / 100); > > This and the two changes above loses the fractional part. > Suggestion: > > julong reasonable_initial = (julong)((double)phys_mem * InitialRAMPercentage / 100.0); Thanks, yes. That's wrong. > src/hotspot/share/runtime/arguments.cpp line 2738: > >> 2736: } >> 2737: >> 2738: if (FLAG_SET_CMDLINE(MaxTenuringThreshold, (uint)max_tenuring_thresh) != JVMFlag::SUCCESS) { > > MaxTenuringThreshold was recently changed to uint, so it would make sense change uintx above to uint. I couldn't change that one because there isn't a parse_uint() version of this: if (!parse_uintx(tail, &max_tenuring_thresh, 0)) { Which calls parse_integer into a 64 bit value. > src/hotspot/share/runtime/deoptimization.cpp line 255: > >> 253: result += frame_sizes()[index]; >> 254: } >> 255: return checked_cast(result); > > Isn't _caller_adjustment already an int? frame_sizes() returns intptr_t so I had to promote result, then demote it. frame_sizes() is a more difficult change. runtime/deoptimization.hpp: intptr_t* _frame_sizes; // Array of frame sizes, in bytes, for unrolling the stack > src/hotspot/share/runtime/java.hpp line 108: > >> 106: >> 107: // Factory methods for convenience >> 108: static JDK_Version jdk(int m) { > > Finally, support for JDK 256 and beyond! Hooray! > src/hotspot/share/runtime/objectMonitor.hpp line 238: > >> 236: // >> 237: #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \ >> 238: ((in_bytes(ObjectMonitor::f ## _offset())) - (unsigned)markWord::monitor_value) > > This makes it int vs uint (-Wsign-conversion warning), and assumes the range of monitor_value. > One option is to narrow the type of monitor_value. Option 2, cast the lhs to uintptr_t. Option 3, use offset_of instead of signed ByteSize. I looked at option 1, but monitor_value is used for byte operations, and it seemed unsafe to make it smaller than uintptr_t, eg: oops/markWord.hpp: return markWord(tmp | monitor_value); The -Wconversion warning is complaining about OM_OFFSET_NO_MONITOR_VALUE_TAG is an long unsigned int because the expression is promoted to the size of markWord::monitor_value without the cast. Option 3 turns the address into a 64 bit int, but the Address constructor expects a 32 bit displacement. 88 | __ movptr(Address(mon, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), r15_thread); Should this convert to int instead of unsigned instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287791980 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287793204 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287794097 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287794217 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287800508 From coleenp at openjdk.org Wed Aug 9 00:58:41 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 00:58:41 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com> References: <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com> Message-ID: On Tue, 8 Aug 2023 21:57:17 GMT, Patricio Chilano Mateo wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make bytecode.hpp index() functions return u2 not long. > > src/hotspot/share/runtime/os.cpp line 143: > >> 141: milliseconds_since_19700101 / milliseconds_per_microsecond; >> 142: const int milliseconds_after_second = >> 143: checked_cast(milliseconds_since_19700101 % milliseconds_per_microsecond); > > Not related to this change but seems milliseconds_per_microsecond should be named milliseconds_per_second. That's easily fixed, and I've already changed those lines. > src/hotspot/share/runtime/safepoint.cpp line 98: > >> 96: int initial_number_of_threads, >> 97: int threads_waiting_to_block, >> 98: int iterations) { > > Maybe leave iterations as unsigned and change the caller instead? If I change the caller: synchronize_threads, it returns the parameter iterations, so I'd have to change its callers. Everything uses iterations here as an int, other than this parameter. > src/hotspot/share/runtime/sharedRuntime.cpp line 2348: > >> 2346: double sum = 0; >> 2347: double weighted_sum = 0; >> 2348: for (int i = 0; i <= n; i++) { sum += (double)histo[i]; weighted_sum += (double)(i*histo[i]); } > > So hist is a uint64_t*, why can't we make sum and weighted_sum just uint64_t? I think there were less casts this way, since sum and weighted sum had to be turned into double more than histo[i], but it does make more sense to use int for summing the numbers, and cast to double for printing. > src/hotspot/share/runtime/threadHeapSampler.cpp line 359: > >> 357: "double and uint64_t do not have the same size"); >> 358: x = *reinterpret_cast(&d); >> 359: const uint32_t x_high = (uint32_t)(x >> 32); > > Can't we do a checked_cast here? The cast should be reversible with that shift value. I think so. I was afraid of sign extension so I just wanted to chop it off, also didn't seem necessary to check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287801694 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287802613 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287805610 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287819364 From dlong at openjdk.org Wed Aug 9 01:35:32 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 01:35:32 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 23:55:42 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/arguments.cpp line 2738: >> >>> 2736: } >>> 2737: >>> 2738: if (FLAG_SET_CMDLINE(MaxTenuringThreshold, (uint)max_tenuring_thresh) != JVMFlag::SUCCESS) { >> >> MaxTenuringThreshold was recently changed to uint, so it would make sense change uintx above to uint. > > I couldn't change that one because there isn't a parse_uint() version of this: > if (!parse_uintx(tail, &max_tenuring_thresh, 0)) { > Which calls parse_integer into a 64 bit value. Isn't parse_integer() used to parse int flags? It's a template. >> src/hotspot/share/runtime/deoptimization.cpp line 255: >> >>> 253: result += frame_sizes()[index]; >>> 254: } >>> 255: return checked_cast(result); >> >> Isn't _caller_adjustment already an int? > > frame_sizes() returns intptr_t so I had to promote result, then demote it. frame_sizes() is a more difficult change. > > runtime/deoptimization.hpp: intptr_t* _frame_sizes; // Array of frame sizes, in bytes, for unrolling the stack OK, I missed the +=. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287836477 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287836596 From dlong at openjdk.org Wed Aug 9 01:44:35 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 01:44:35 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 00:12:13 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/objectMonitor.hpp line 238: >> >>> 236: // >>> 237: #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \ >>> 238: ((in_bytes(ObjectMonitor::f ## _offset())) - (unsigned)markWord::monitor_value) >> >> This makes it int vs uint (-Wsign-conversion warning), and assumes the range of monitor_value. >> One option is to narrow the type of monitor_value. Option 2, cast the lhs to uintptr_t. Option 3, use offset_of instead of signed ByteSize. > > I looked at option 1, but monitor_value is used for byte operations, and it seemed unsafe to make it smaller than uintptr_t, eg: > > oops/markWord.hpp: return markWord(tmp | monitor_value); > > The -Wconversion warning is complaining about OM_OFFSET_NO_MONITOR_VALUE_TAG is an long unsigned int because the expression is promoted to the size of markWord::monitor_value without the cast. > > Option 3 turns the address into a 64 bit int, but the Address constructor expects a 32 bit displacement. > > 88 | __ movptr(Address(mon, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), r15_thread); > > Should this convert to int instead of unsigned instead? Yes int would be more correct. The value could be negative if the order of the fields in ObjectMonitor (or the value of monitor_value) were changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287840806 From dlong at openjdk.org Wed Aug 9 01:52:43 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 01:52:43 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com> Message-ID: <9bzTnUcEvSuqdaVEr0XI2yR2SEf5OUZ8ro7WhtxDeHw=.cf065626-a648-4028-b997-280871690af6@github.com> On Wed, 9 Aug 2023 00:24:30 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 2348: >> >>> 2346: double sum = 0; >>> 2347: double weighted_sum = 0; >>> 2348: for (int i = 0; i <= n; i++) { sum += (double)histo[i]; weighted_sum += (double)(i*histo[i]); } >> >> So hist is a uint64_t*, why can't we make sum and weighted_sum just uint64_t? > > I think there were less casts this way, since sum and weighted sum had to be turned into double more than histo[i], but it does make more sense to use int for summing the numbers, and cast to double for printing. I don't know how big these values are, but if they were large then uint64_t sum could overflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1287844731 From dlong at openjdk.org Wed Aug 9 02:03:43 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 02:03:43 GMT Subject: RFR: 8310239: Add missing cross modifying fence in nmethod entry barriers [v2] In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 08:26:08 GMT, Erik ?sterlund wrote: >> In fact, there is a current race in the nmethod entry barriers, where what we are doing violates the AMD APM (cf. APM volume 2 section 7.6.1 https://www.amd.com/system/files/TechDocs/24593.pdf). >> In particular, if the compare instruction of the nmethod entry barrier is not yet patched and we call a slow path on thread 1, then before taking the nmethod entry lock, another thread 2 could fix and disarm the nmethod. Then thread 1 will observe *data* suggesting the nmethod has been patched, but never re-executes the patched compare (which might indeed still be stale), hence not qualifying for asynchronous cross modifying code, and neither do we run a serializing cpuid instruction, qualifying for synchronous cross modifying code. In this scenario, we can indeed start executing the nmethod instructions, while observing inconsistent concurrent patching effects, where some instructions will be updated and some not. >> >> The following patch ensures that x86 nmethod entry barriers execute cross modifying fence after calling into the VM, where another thread could have disarmed the nmethod. I also ensured the other platforms perform their fencing after the VM call, instead of before - including a cross_modify_fence in the shared code for OSR nmethod entries. While fencing before will flush out the instruction pipeline, and it shouldn't be populated with problematic instructions until after we start executing the nmethod again, it feels unnecessary to fence on the wrong side of the modifications it wishes to guard, and hence not strictly following the synchronous cross modifying fence recipe. >> >> I'm currently running tier1-5 and running performance testing in aurora. In the interest of time, I'm opening this PR before getting the final result, and will report the results when they come in. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Typo in comment I was thinking the issue Erik was worried about is patching of nmethod code as data at safepoints. I seem to recall there are certain kinds of stubs that need to patch more than one word, so it is done at a safepoint. I see code in SafepointMechanism::update_poll_values() that calls OrderAccess::cross_modify_fence() in certain cases, so maybe that's enough? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14543#issuecomment-1670545476 From jwaters at openjdk.org Wed Aug 9 04:02:43 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 9 Aug 2023 04:02:43 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com> On Tue, 8 Aug 2023 19:56:24 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: >> >> - Mismatched declaration in D3DGlyphCache.cpp >> - Fields in awt_TextComponent.cpp >> - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp >> - Qualifiers in awt_PrintDialog.h should be removed >> - Likewise for awt_DnDDT.cpp >> - awt_ole.h include order issue in awt_DnDDS.cpp >> - Revert awt_ole.h >> - Earlier fix in awt_ole.h was not complete >> - Merge branch 'openjdk:master' into patch-10 >> - Likewise for awt_Frame.cpp >> - ... and 12 more: https://git.openjdk.org/jdk/compare/9da8c164...51230f3d > > src/hotspot/os/windows/os_windows.cpp line 2888: > >> 2886: LONG WINAPI topLevelUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo) { >> 2887: if (!InterceptOSException) { >> 2888: DWORD exception_code = exceptionInfo->ExceptionRecord->ExceptionCode; > > I find this less clearer than the original code, that didn't use negation - it was clear that InterceptOSException leads to immediate bailout. > > What is the problem, the goto? is the compiler complaining? If so, I would vote for duplicating the return statement here (and this would count as an example where discarding out-of-fashion statements like goto actually makes the code worse). Hi Thomas, the goto jumps over a lot of variable initializations, which permissive- doesn't particularly like (the failing compilation can actually be seen in the earlier GHA logs) > src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp line 48: > >> 46: >> 47: #include "jlong.h" >> 48: #include "awt.h" > > Why the reordering of includes? This is a weird one, but in awt we #define malloc Do_Not_Use_Malloc... And so on. Without this reordering awt_ole.h (which includes comdef.h) also uses the redefined malloc somewhere (I could not find where in comip.h that it's used) which breaks compilation. I do find it strange that without permissive- it doesn't break though. Same applies to the other reordering of includes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287904601 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1287903377 From jwaters at openjdk.org Wed Aug 9 04:05:34 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 9 Aug 2023 04:05:34 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 8 Aug 2023 20:53:19 GMT, Thomas Stuefe wrote: > I think I see now that the added scopes were to prevent variable life scopes from intersecting goto's? Yes, that's why ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1670618830 From thartmann at openjdk.org Wed Aug 9 05:36:31 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 9 Aug 2023 05:36:31 GMT Subject: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v3] In-Reply-To: <9_aaKm7wC_9cQH2qHKbb5myvx7roacZJVzWRLZ8NdQM=.6dc482e0-c215-4a1b-b84a-d819f0ee3979@github.com> References: <9_aaKm7wC_9cQH2qHKbb5myvx7roacZJVzWRLZ8NdQM=.6dc482e0-c215-4a1b-b84a-d819f0ee3979@github.com> Message-ID: On Fri, 4 Aug 2023 19:45:56 GMT, Leonid Mesnik wrote: >> The fix adds posting VmObjectAlloc events by Unsafe.allocateInstance(Class cls). The previous attempt to post event directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance regression even if jvmti event is not enabled. Some optimizations have been disabled just because possible usage and escaping of newly allocated object. >> So event posting is doing by returning to interpreter if events are enabled. >> >> I verified that that performance (run locally only) of >> org.renaissance.jdk.streams.JmhScrabble.runOperation >> doesn't change if events are not enabled. >> >> There might be other intrinsics like 'LibraryCallKit::inline_unsafe_newArray()' where VM allocate memory. I'm going to file separate issue to find and fix them. >> >> Many thanks to Tobias H. for proposed solution. >> >> Testing with all tiers. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > The too many deopts check should be first. Looks good to me. src/hotspot/share/opto/library_call.cpp line 2845: > 2843: } > 2844: if (stopped()) > 2845: return true; Suggestion: if (stopped()) { return true; } ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15110#pullrequestreview-1568773710 PR Review Comment: https://git.openjdk.org/jdk/pull/15110#discussion_r1287968367 From lmesnik at openjdk.org Wed Aug 9 06:17:54 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 9 Aug 2023 06:17:54 GMT Subject: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v4] In-Reply-To: References: Message-ID: > The fix adds posting VmObjectAlloc events by Unsafe.allocateInstance(Class cls). The previous attempt to post event directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance regression even if jvmti event is not enabled. Some optimizations have been disabled just because possible usage and escaping of newly allocated object. > So event posting is doing by returning to interpreter if events are enabled. > > I verified that that performance (run locally only) of > org.renaissance.jdk.streams.JmhScrabble.runOperation > doesn't change if events are not enabled. > > There might be other intrinsics like 'LibraryCallKit::inline_unsafe_newArray()' where VM allocate memory. I'm going to file separate issue to find and fix them. > > Many thanks to Tobias H. for proposed solution. > > Testing with all tiers. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added braces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15110/files - new: https://git.openjdk.org/jdk/pull/15110/files/64871b91..4f52aa79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15110&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15110&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15110/head:pull/15110 PR: https://git.openjdk.org/jdk/pull/15110 From stefank at openjdk.org Wed Aug 9 06:18:41 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 9 Aug 2023 06:18:41 GMT Subject: RFR: 8313752: InstanceKlassFlags::print_on doesn't print the flag names [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 09:54:49 GMT, Stefan Karlsson wrote: >> I've found that our misc flags printing is broken. This can be seen in our hs_err files: >> >> RCX=0x00007f86bf0073c8 is a pointer to class: >> java.lang.Class {0x00007f86bf0073c8} >> - instance size: 22 >> - klass size: 97 >> - access: public final synchronized >> - flags: ##name ##name ##name ##name ##name ##name >> >> >> With this fix the flags are now printed as expected: >> >> java.util.Hashtable {0x00007f5fff00e8c0} >> - instance size: 8 >> - klass size: 123 >> - access: public synchronized >> - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method >> >> >> The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Tweak ouput Thanks for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15153#issuecomment-1670734819 From stefank at openjdk.org Wed Aug 9 06:18:42 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 9 Aug 2023 06:18:42 GMT Subject: Integrated: 8313752: InstanceKlassFlags::print_on doesn't print the flag names In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 11:28:50 GMT, Stefan Karlsson wrote: > I've found that our misc flags printing is broken. This can be seen in our hs_err files: > > RCX=0x00007f86bf0073c8 is a pointer to class: > java.lang.Class {0x00007f86bf0073c8} > - instance size: 22 > - klass size: 97 > - access: public final synchronized > - flags: ##name ##name ##name ##name ##name ##name > > > With this fix the flags are now printed as expected: > > java.util.Hashtable {0x00007f5fff00e8c0} > - instance size: 8 > - klass size: 123 > - access: public synchronized > - flags: rewritten has_nonstatic_fields has_nonstatic_concrete_methods is_shared_boot_class has_localvariable_table has_final_method > > > The indentation doesn't look that great, so if you want me to change it I can do so in this patch as well. This pull request has now been integrated. Changeset: 735b16a6 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/735b16a6969ba5998b4f809927e5ac42a7e72d2d Stats: 7 lines in 4 files changed: 3 ins; 1 del; 3 mod 8313752: InstanceKlassFlags::print_on doesn't print the flag names Reviewed-by: stuefe, shade, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/15153 From stuefe at openjdk.org Wed Aug 9 06:32:35 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Aug 2023 06:32:35 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com> Message-ID: On Wed, 9 Aug 2023 04:00:03 GMT, Julian Waters wrote: >> src/hotspot/os/windows/os_windows.cpp line 2888: >> >>> 2886: LONG WINAPI topLevelUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo) { >>> 2887: if (!InterceptOSException) { >>> 2888: DWORD exception_code = exceptionInfo->ExceptionRecord->ExceptionCode; >> >> I find this less clearer than the original code, that didn't use negation - it was clear that InterceptOSException leads to immediate bailout. >> >> What is the problem, the goto? is the compiler complaining? If so, I would vote for duplicating the return statement here (and this would count as an example where discarding out-of-fashion statements like goto actually makes the code worse). > > Hi Thomas, the goto jumps over a lot of variable initializations, which permissive- doesn't particularly like (the failing compilation can actually be seen in the earlier GHA logs) Ah, okay. Thanks for clarifying. >> src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp line 48: >> >>> 46: >>> 47: #include "jlong.h" >>> 48: #include "awt.h" >> >> Why the reordering of includes? > > This is a weird one, but in awt we #define malloc Do_Not_Use_Malloc... And so on. Without this reordering awt_ole.h (which includes comdef.h) also uses the redefined malloc somewhere (I could not find where in comip.h that it's used) which breaks compilation. I do find it strange that without permissive- it doesn't break though. Same applies to the other reordering of includes Oh. That's not good. Having such an undocumented reliance on order of include just begs to bitrot at some point. Any chance you could unravel that mystery, maybe in a later RFE? For now, can you please add a comment at those places where you changed include order for that reason? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288007914 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288009545 From lmesnik at openjdk.org Wed Aug 9 06:32:41 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 9 Aug 2023 06:32:41 GMT Subject: RFR: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects [v3] In-Reply-To: References: <9_aaKm7wC_9cQH2qHKbb5myvx7roacZJVzWRLZ8NdQM=.6dc482e0-c215-4a1b-b84a-d819f0ee3979@github.com> Message-ID: On Fri, 4 Aug 2023 20:37:00 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> The too many deopts check should be first. > > This looks okay to me. > It needs to be reviewed by someone from the compiler team. > Thanks, > Serguei @sspitsyn, @TobiHartmann Thank you for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15110#issuecomment-1670746545 From lmesnik at openjdk.org Wed Aug 9 06:32:43 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 9 Aug 2023 06:32:43 GMT Subject: Integrated: 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 19:49:51 GMT, Leonid Mesnik wrote: > The fix adds posting VmObjectAlloc events by Unsafe.allocateInstance(Class cls). The previous attempt to post event directly from 'LibraryCallKit::inline_unsafe_allocate()' cause performance regression even if jvmti event is not enabled. Some optimizations have been disabled just because possible usage and escaping of newly allocated object. > So event posting is doing by returning to interpreter if events are enabled. > > I verified that that performance (run locally only) of > org.renaissance.jdk.streams.JmhScrabble.runOperation > doesn't change if events are not enabled. > > There might be other intrinsics like 'LibraryCallKit::inline_unsafe_newArray()' where VM allocate memory. I'm going to file separate issue to find and fix them. > > Many thanks to Tobias H. for proposed solution. > > Testing with all tiers. This pull request has now been integrated. Changeset: 3fb4805b Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/3fb4805b1ad6d66924fd961f62126a91d188abab Stats: 37 lines in 6 files changed: 33 ins; 4 del; 0 mod 8307462: [REDO] VmObjectAlloc is not generated by intrinsics methods which allocate objects Reviewed-by: sspitsyn, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/15110 From stuefe at openjdk.org Wed Aug 9 06:41:40 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Aug 2023 06:41:40 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Mismatched declaration in D3DGlyphCache.cpp > - Fields in awt_TextComponent.cpp > - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp > - Qualifiers in awt_PrintDialog.h should be removed > - Likewise for awt_DnDDT.cpp > - awt_ole.h include order issue in awt_DnDDS.cpp > - Revert awt_ole.h > - Earlier fix in awt_ole.h was not complete > - Merge branch 'openjdk:master' into patch-10 > - Likewise for awt_Frame.cpp > - ... and 12 more: https://git.openjdk.org/jdk/compare/15f348cb...51230f3d src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1641: > 1639: } > 1640: } > 1641: A possible improvement later (and for a future RFE) would be to use RAII for deletion and then get rid of the labels. awt is one of the few places that uses C++ for native code, so why not. src/java.desktop/windows/native/libawt/windows/awt_TextComponent.cpp line 59: > 57: AwtTextComponent::OleCallback AwtTextComponent::sm_oleCallback; > 58: WNDPROC AwtTextComponent::sm_pDefWindowProc = NULL; > 59: Did the compiler complain here? I'm fine with the change, just wanted to know the reason. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288013587 PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288015274 From david.holmes at oracle.com Wed Aug 9 06:43:56 2023 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Aug 2023 16:43:56 +1000 Subject: Request for Bug Assignment: Test Timed Out Issue in ClhsdbSymbol.java In-Reply-To: <668719561.1071537.1691399909359.JavaMail.zimbra@imt-soft.com> References: <668719561.1071537.1691399909359.JavaMail.zimbra@imt-soft.com> Message-ID: <794132f1-53b9-da37-1602-b10636e59cda@oracle.com> Hi Tham, Welcome to the OpenJDK community! As this is a serviceability issue please take this to the serviceability-dev at openjdk.org mailing list. Thanks, David On 7/08/2023 7:23 pm, Tham To Thi Hong wrote: > Dear HotSpot Development Team, > > I hope this email finds you well. My name is Tham To, and I am a new contributor to the OpenJDK community. I am writing to seek your guidance and assistance regarding a bug that I have been tracking. > > Bug Details: > > Bug ID: JDK-8313814 > Bug Description: Test serviceability/sa/ClhsdbSymbol.java timed out after passing > Status: NEW > Priority: P4 > Resolution: Unresolved > Affects Version/s: 22 > Component/s: hotspot > Subcomponent: svc-agent > OS: Windows > Description: > I have been actively monitoring the aforementioned bug, which involves a test case timing out after passing. It appears to be a significant issue that may require attention. I believe that understanding and resolving this issue will not only contribute to the enhancement of the HotSpot component but also provide me with valuable learning opportunities as a new contributor to the OpenJDK community. > > I am eager to contribute to the community by assisting in identifying and addressing this bug. I kindly request to be assigned to this bug so that I can collaborate with the development team to investigate and resolve the root cause of the test timeout. > > As a new contributor, I am excited about the opportunity to learn from experienced developers and contribute my skills to the OpenJDK project. > > Thank you for considering my request. I am eager to contribute and learn from the community's expertise. > > Best regards, > > Tham To(Ms.) > Software Engineer I > ------------------ > IMT Solutions|Fostering IT Innovation > 55-57 Bau Cat 4 St., Tan Binh Dist, Ho Chi Minh City, Vietnam > Phone: +84 35 333 4110 > Skype: totham024 > http://www.imt-soft.com > From dholmes at openjdk.org Wed Aug 9 06:56:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 9 Aug 2023 06:56:35 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Tue, 8 Aug 2023 19:52:08 GMT, Thomas Stuefe wrote: >> I just checked and the value of the sentinel is ultimately the prvalue 88. I don't know if we'd want to replace all the weird char usages here with explicit values of 0 (and 88 for the sentinel). Maybe future reviews can help with that > > I wrote this code ages ago. I'm not sure what's weird or suspicious about it, though. The comment at the file's beginning explains this code's motivation. > > The buffer was never thought to be used for something different than HANDLEs or characters, where the assignment of integer literals work. I often use char constants for sentinels as debugging aid. As for `'\0'`, that indicates to the casual code reader that this is a termination of a string, better than had I used a plain 0. Because there is nothing to state what T may be, I found assigning character literals to be odd. If T is char and the buffer is meant to be a C string then it makes more sense. But for non-char T it just raised questions for me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288029698 From mbaesken at openjdk.org Wed Aug 9 06:57:42 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 9 Aug 2023 06:57:42 GMT Subject: RFR: JDK-8313691: use close after failing os::fdopen in vmError and ciEnv [v2] In-Reply-To: References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: On Fri, 4 Aug 2023 07:02:02 GMT, Matthias Baesken wrote: >> In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. >> The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). >> >> However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. > > Matthias Baesken 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: > > - Adjust ciEnv.cpp and comment > - Merge remote-tracking branch 'origin/master' into JDK-8313691 > - JDK-8313691 Hi David and Tobias, thanks for the reviews and for checking the tests on your side too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15139#issuecomment-1670771031 From mbaesken at openjdk.org Wed Aug 9 06:57:44 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 9 Aug 2023 06:57:44 GMT Subject: Integrated: JDK-8313691: use close after failing os::fdopen in vmError and ciEnv In-Reply-To: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> References: <5jkxxg-QT0Cieelloy3n6qG-ZowtW4RWNs8ZJo7pbe4=.206b56ec-88b5-482b-a151-a1ff549399dc@github.com> Message-ID: On Thu, 3 Aug 2023 14:02:22 GMT, Matthias Baesken wrote: > In vmError.cpp we use os::fdopen and in case this is successful pass the returned file pointer to a fileStream constructor. > The fileStream object calls fclose on our file pointer in destruction (and this closes also the underlying file descriptor fd). > > However in case of failing os::fdopen we do not create (and later destruct) a fileStream object so direct call to close might be needed. I also adjusted a comment to make it even clearer that the fileStream object fcloses the file pointer on the destructor. This pull request has now been integrated. Changeset: 96304f37 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/96304f37f8344b0c0e271ff9cda84961519d5109 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8313691: use close after failing os::fdopen in vmError and ciEnv Reviewed-by: dholmes, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/15139 From dholmes at openjdk.org Wed Aug 9 07:40:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 9 Aug 2023 07:40:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v3] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 12:21:53 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > backslash aligned I only checked the last two flags but in both cases found related changes. Please make sure all the uses of these flags has been checked. Thanks. src/hotspot/share/runtime/globals.hpp line 1311: > 1309: "Hit breakpoint when mallocing/freeing this pointer") \ > 1310: \ > 1311: develop(int, StackPrintLimit, 100, \ You can remove this cast now: ./share/utilities/vmError.cpp: const int limit = max_frames == -1 ? StackPrintLimit : MIN2(max_frames, (int)StackPrintLimit); src/hotspot/share/runtime/globals.hpp line 1748: > 1746: "Data sampling interval (in milliseconds)") \ > 1747: range(PeriodicTask::min_interval, max_jint) \ > 1748: constraint(PerfDataSamplingIntervalFunc, AfterErgo) \ You need to change the type of the `PerfDataSamplingIntervalFunc` as well. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1568895310 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288053102 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288049092 From dholmes at openjdk.org Wed Aug 9 07:41:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 9 Aug 2023 07:41:29 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v3] In-Reply-To: References: Message-ID: <2_ComSBzrXfSK7XOT3Fzzc616tXIHtR_7yaqM3c0sME=.19f45af2-161b-42bd-9f47-dbabbc66c863@github.com> On Mon, 7 Aug 2023 14:52:44 GMT, Coleen Phillimore wrote: >> Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms. > > This is complicated. BytecodeCounter::_counter_value is an int, and StopInterpreterAt compares to that in shared code, which is fine because it'll promote the former to intx. The cpu-specific code fetches the former as int and the latter as intx, except in one place so fixing either is going to be work. The one place that complains on x86 is > > src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp:1865:12: warning: conversion from 'intx' {aka 'long int'} to 'int32_t' {aka 'int'} may change value [-Wconversion] > 1865 | StopInterpreterAt, > | ^~~~~~~~~~~~~~~~~ > > > __ cmp32(ExternalAddress((address) &BytecodeCounter::_counter_value), > StopInterpreterAt, > rscratch1); > > We could just static_cast StopInterpreterAt to int here. > Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms. I thought this was the count within a method, in which case the bytecode limit is the same for 32-bit and 64-bit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288037015 From stuefe at openjdk.org Wed Aug 9 08:08:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 9 Aug 2023 08:08:28 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Wed, 9 Aug 2023 06:53:49 GMT, David Holmes wrote: >> I wrote this code ages ago. I'm not sure what's weird or suspicious about it, though. The comment at the file's beginning explains this code's motivation. >> >> The buffer was never thought to be used for something different than HANDLEs or characters, where the assignment of integer literals work. I often use char constants for sentinels as debugging aid. As for `'\0'`, that indicates to the casual code reader that this is a termination of a string, better than had I used a plain 0. > > Because there is nothing to state what T may be, I found assigning character literals to be odd. If T is char and the buffer is meant to be a C string then it makes more sense. But for non-char T it just raised questions for me. I see that. We can remove the sentinel stuff, which leaves us with the zero termination. Arguably, this could be done by sub classes that derive from the char instantiation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288083649 From shade at openjdk.org Wed Aug 9 08:36:38 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 9 Aug 2023 08:36:38 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg [v2] In-Reply-To: <7IOJ9HRfGvZJ_SD6hmIWbMpVxvfFFQqiAsfW85o2iDs=.d7f39560-252f-4b73-822d-dfce60f344e0@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> <7IOJ9HRfGvZJ_SD6hmIWbMpVxvfFFQqiAsfW85o2iDs=.d7f39560-252f-4b73-822d-dfce60f344e0@github.com> Message-ID: On Tue, 8 Aug 2023 13:20:55 GMT, Oli Gillespie wrote: >> According to the JNI spec for NewWeakGlobalRef: >> >>> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. >> >> The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. >> >> (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback > > Move test case to existing test, use .not_null() for null check. Looks good to me. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15188#pullrequestreview-1568996761 From mbaesken at openjdk.org Wed Aug 9 08:42:35 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 9 Aug 2023 08:42:35 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v2] In-Reply-To: References: Message-ID: > There is coding e.g. in > https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 > that deals with shared lib naming on different OS. > This code should be simplified. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: use Platform.sharedLibraryPrefix in more tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15151/files - new: https://git.openjdk.org/jdk/pull/15151/files/c99d984d..e708bb68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=00-01 Stats: 9 lines in 3 files changed: 0 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151 PR: https://git.openjdk.org/jdk/pull/15151 From tschatzl at openjdk.org Wed Aug 9 10:31:29 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 9 Aug 2023 10:31:29 GMT Subject: RFR: 8311508: ZGC: RAII use of IntelJccErratumAlignment In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 13:49:24 GMT, Axel Boldt-Christmas wrote: > Fixed the locations where unnamed IntelJccErratumAlignment circumvented the correctness asserts. > Also strengthened the asserts so that a IntelJccErratumAlignment RAII object scope must surround at least some instruction. > > Tested GHA and tier1,tier2 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15191#pullrequestreview-1569219187 From mbaesken at openjdk.org Wed Aug 9 11:06:04 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 9 Aug 2023 11:06:04 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v3] In-Reply-To: References: Message-ID: > There is coding e.g. in > https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 > that deals with shared lib naming on different OS. > This code should be simplified. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Introduce buildSharedLibraryName ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15151/files - new: https://git.openjdk.org/jdk/pull/15151/files/e708bb68..9f9c5b25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=01-02 Stats: 50 lines in 9 files changed: 10 ins; 25 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151 PR: https://git.openjdk.org/jdk/pull/15151 From mbaesken at openjdk.org Wed Aug 9 11:06:28 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 9 Aug 2023 11:06:28 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 08:42:35 GMT, Matthias Baesken wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > use Platform.sharedLibraryPrefix in more tests Hello, as suggested I introduced a Platform.buildSharedLibraryName; this can be used to simplify a lot of code in the mentioned tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15151#issuecomment-1671099342 From jwaters at openjdk.org Wed Aug 9 11:31:29 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 9 Aug 2023 11:31:29 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <3SFn8vguk4vb9YM46_-a4xNY-95z3gGBxOUwyXtzUGI=.a57a1663-6b34-4db9-bbae-3d9e4733dd02@github.com> On Wed, 9 Aug 2023 06:37:10 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: >> >> - Mismatched declaration in D3DGlyphCache.cpp >> - Fields in awt_TextComponent.cpp >> - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp >> - Qualifiers in awt_PrintDialog.h should be removed >> - Likewise for awt_DnDDT.cpp >> - awt_ole.h include order issue in awt_DnDDS.cpp >> - Revert awt_ole.h >> - Earlier fix in awt_ole.h was not complete >> - Merge branch 'openjdk:master' into patch-10 >> - Likewise for awt_Frame.cpp >> - ... and 12 more: https://git.openjdk.org/jdk/compare/7b4bc18a...51230f3d > > src/java.desktop/windows/native/libawt/windows/awt_TextComponent.cpp line 59: > >> 57: AwtTextComponent::OleCallback AwtTextComponent::sm_oleCallback; >> 58: WNDPROC AwtTextComponent::sm_pDefWindowProc = NULL; >> 59: > > Did the compiler complain here? I'm fine with the change, just wanted to know the reason. the latter two are inside an extern "C" block, meaning their initial C++ linkage (by virtue of them being static class members) conflicts with the now C linkage, also the comment there states the AwtComponent fields are supposed to be set here, and I have no idea why this was not done, so I moved them all to be under that comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1288325155 From stefank at openjdk.org Wed Aug 9 11:34:28 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 9 Aug 2023 11:34:28 GMT Subject: RFR: 8314019: Add gc logging to jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java Message-ID: Add GC logging to this test so that we can figure out why this is intermittently throwing OOME. ------------- Commit messages: - 8314019: Add gc logging to jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java Changes: https://git.openjdk.org/jdk/pull/15207/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15207&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314019 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15207/head:pull/15207 PR: https://git.openjdk.org/jdk/pull/15207 From azafari at openjdk.org Wed Aug 9 11:36:34 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 9 Aug 2023 11:36:34 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v4] In-Reply-To: References: Message-ID: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: checked all usages of changed options. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15164/files - new: https://git.openjdk.org/jdk/pull/15164/files/d88a1238..d7919b1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=02-03 Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15164/head:pull/15164 PR: https://git.openjdk.org/jdk/pull/15164 From duke at openjdk.org Wed Aug 9 11:47:58 2023 From: duke at openjdk.org (Richard Startin) Date: Wed, 9 Aug 2023 11:47:58 GMT Subject: Integrated: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer In-Reply-To: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> Message-ID: On Tue, 8 Aug 2023 15:02:59 GMT, Richard Startin wrote: > Makes AsyncGetCallTrace more resilient to method unloading. This pull request has now been integrated. Changeset: 0e2c72d7 Author: Richard Startin Committer: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/0e2c72d7a5206b7173af5bf69e21d21ea276bd94 Stats: 16 lines in 7 files changed: 11 ins; 0 del; 5 mod 8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer Reviewed-by: coleenp, aph, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/15193 From aboldtch at openjdk.org Wed Aug 9 11:59:28 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 9 Aug 2023 11:59:28 GMT Subject: RFR: 8314019: Add gc logging to jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 11:12:59 GMT, Stefan Karlsson wrote: > Add GC logging to this test so that we can figure out why this is intermittently throwing OOME. Marked as reviewed by aboldtch (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15207#pullrequestreview-1569376610 From coleenp at openjdk.org Wed Aug 9 12:00:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 12:00:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v4] In-Reply-To: <2_ComSBzrXfSK7XOT3Fzzc616tXIHtR_7yaqM3c0sME=.19f45af2-161b-42bd-9f47-dbabbc66c863@github.com> References: <2_ComSBzrXfSK7XOT3Fzzc616tXIHtR_7yaqM3c0sME=.19f45af2-161b-42bd-9f47-dbabbc66c863@github.com> Message-ID: On Wed, 9 Aug 2023 07:01:20 GMT, David Holmes wrote: >> This is complicated. BytecodeCounter::_counter_value is an int, and StopInterpreterAt compares to that in shared code, which is fine because it'll promote the former to intx. The cpu-specific code fetches the former as int and the latter as intx, except in one place so fixing either is going to be work. The one place that complains on x86 is >> >> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp:1865:12: warning: conversion from 'intx' {aka 'long int'} to 'int32_t' {aka 'int'} may change value [-Wconversion] >> 1865 | StopInterpreterAt, >> | ^~~~~~~~~~~~~~~~~ >> >> >> __ cmp32(ExternalAddress((address) &BytecodeCounter::_counter_value), >> StopInterpreterAt, >> rscratch1); >> >> We could just static_cast StopInterpreterAt to int here. > >> Actually this counts bytecodes, so it could easily become 64 bit on 64 bit platforms. > > I thought this was the count within a method, in which case the bytecode limit is the same for 32-bit and 64-bit. It is not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288371386 From coleenp at openjdk.org Wed Aug 9 12:20:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 12:20:58 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v3] In-Reply-To: References: Message-ID: <89uyh0jvDyytOfu-OI8Z2vO0v96FI0oK0uFTuLJ_HY8=.b44d6b53-67dd-4ad3-ba2d-86ae508e024e@github.com> > Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. > > src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] > 1802 | _thread->dec_held_monitor_count(rec + 1); > | ~~~~^~~ > > Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Dean's and Patricio's suggested changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15177/files - new: https://git.openjdk.org/jdk/pull/15177/files/a77884e4..1af1cfe5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=01-02 Stats: 18 lines in 5 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/15177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177 PR: https://git.openjdk.org/jdk/pull/15177 From azafari at openjdk.org Wed Aug 9 12:41:28 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 9 Aug 2023 12:41:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v5] In-Reply-To: References: Message-ID: <3xjlUAvmX9Vp4T4a0Q4OIrJuLs6eWUiQ6udipPiM_v8=.ba115f8a-ad56-4643-a1f1-cc0a223668f0@github.com> > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: Matched with master. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15164/files - new: https://git.openjdk.org/jdk/pull/15164/files/d7919b1b..361a3d9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15164/head:pull/15164 PR: https://git.openjdk.org/jdk/pull/15164 From coleenp at openjdk.org Wed Aug 9 12:51:03 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 12:51:03 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader Message-ID: Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. Tested with tier1-4 on linux-x64-debug and windows-x64-debug. ------------- Commit messages: - 8313905: Checked_cast assert in CDS compare_by_loader Changes: https://git.openjdk.org/jdk/pull/15208/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15208&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313905 Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15208/head:pull/15208 PR: https://git.openjdk.org/jdk/pull/15208 From coleenp at openjdk.org Wed Aug 9 13:23:40 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 13:23:40 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v4] In-Reply-To: References: Message-ID: > Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. > > src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] > 1802 | _thread->dec_held_monitor_count(rec + 1); > | ~~~~^~~ > > Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. Coleen Phillimore 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 17 additional commits since the last revision: - Merge branch 'master' into runtime-conversion - Change Arguments::parse_uintx to parse_uint and callers. - Dean's and Patricio's suggested changes. - Make bytecode.hpp index() functions return u2 not long. - Fix jvmci for held_monitor_count type. - Fix format strings for monitor_counts and fix arguments.cpp differently. - Fix gtests - Fix asserted files in runtime with one warning. - Fix signature.cpp - Fix continuationFreezeThaw.cpp - ... and 7 more: https://git.openjdk.org/jdk/compare/e4063a36...f4961655 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15177/files - new: https://git.openjdk.org/jdk/pull/15177/files/1af1cfe5..f4961655 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=02-03 Stats: 7972 lines in 425 files changed: 2632 ins; 2838 del; 2502 mod Patch: https://git.openjdk.org/jdk/pull/15177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177 PR: https://git.openjdk.org/jdk/pull/15177 From coleenp at openjdk.org Wed Aug 9 13:24:00 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 13:24:00 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 01:32:37 GMT, Dean Long wrote: >> I couldn't change that one because there isn't a parse_uint() version of this: >> if (!parse_uintx(tail, &max_tenuring_thresh, 0)) { >> Which calls parse_integer into a 64 bit value. > > Isn't parse_integer() used to parse int flags? It's a template. Ok, I fixed parse_uintx in Arguments to parse_uint then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288440009 From coleenp at openjdk.org Wed Aug 9 13:24:02 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 13:24:02 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: <9bzTnUcEvSuqdaVEr0XI2yR2SEf5OUZ8ro7WhtxDeHw=.cf065626-a648-4028-b997-280871690af6@github.com> References: <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com> <9bzTnUcEvSuqdaVEr0XI2yR2SEf5OUZ8ro7WhtxDeHw=.cf065626-a648-4028-b997-280871690af6@github.com> Message-ID: <8WXIOuCKXYoIfkmw14aQ36Wf2ZBm2lqYpxwcBnyxCQ8=.8f583a22-9ee4-4489-bef6-f4cca99564b3@github.com> On Wed, 9 Aug 2023 01:49:43 GMT, Dean Long wrote: >> I think there were less casts this way, since sum and weighted sum had to be turned into double more than histo[i], but it does make more sense to use int for summing the numbers, and cast to double for printing. > > I don't know how big these values are, but if they were large then uint64_t sum could overflow. uint64_t count = (uint64_t)method->compiled_invocation_count(); They seem to be a sum of compiled_invocation_count() so maybe double is best. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288453974 From ogillespie at openjdk.org Wed Aug 9 14:09:00 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Wed, 9 Aug 2023 14:09:00 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v2] In-Reply-To: References: Message-ID: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision: - Fix jcheck Whitespace - Review comments - add dedicated is_dead function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15137/files - new: https://git.openjdk.org/jdk/pull/15137/files/2be4f359..74c1a27a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=00-01 Stats: 53 lines in 9 files changed: 35 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/15137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15137/head:pull/15137 PR: https://git.openjdk.org/jdk/pull/15137 From ogillespie at openjdk.org Wed Aug 9 14:09:02 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Wed, 9 Aug 2023 14:09:02 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 11:21:27 GMT, Oli Gillespie wrote: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Thanks Coleen, I think the dedicated `is_dead` function looks good. Let me know what you think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1671370118 From coleenp at openjdk.org Wed Aug 9 14:14:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 14:14:28 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v5] In-Reply-To: References: Message-ID: > Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. > > src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] > 1802 | _thread->dec_held_monitor_count(rec + 1); > | ~~~~^~~ > > Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Revert histogram sum and weighted_sum changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15177/files - new: https://git.openjdk.org/jdk/pull/15177/files/f4961655..43665637 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=03-04 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/15177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177 PR: https://git.openjdk.org/jdk/pull/15177 From coleenp at openjdk.org Wed Aug 9 14:15:04 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 14:15:04 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com> References: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com> Message-ID: On Tue, 8 Aug 2023 20:10:48 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make bytecode.hpp index() functions return u2 not long. > > src/hotspot/share/runtime/arguments.cpp line 1215: > >> 1213: } >> 1214: } >> 1215: c = getc(stream); > > How about int c0 for the getc value, then the first line in the loop does > char c = checked_cast(c0); > No other changes should be needed. There was a reason that c had to be an int. Now I'll have to rebuild and figure it out again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288514952 From coleenp at openjdk.org Wed Aug 9 14:18:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 14:18:29 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: <8WXIOuCKXYoIfkmw14aQ36Wf2ZBm2lqYpxwcBnyxCQ8=.8f583a22-9ee4-4489-bef6-f4cca99564b3@github.com> References: <-hYtYgUY33A1nQ2s6T6AkPRhwurSk7AmqCm5S_4fU3I=.ed9c022f-87e2-44fb-a468-4ca42f47c9e9@github.com> <9bzTnUcEvSuqdaVEr0XI2yR2SEf5OUZ8ro7WhtxDeHw=.cf065626-a648-4028-b997-280871690af6@github.com> <8WXIOuCKXYoIfkmw14aQ36Wf2ZBm2lqYpxwcBnyxCQ8=.8f583a22-9ee4-4489-bef6-f4cca99564b3@github.com> Message-ID: On Wed, 9 Aug 2023 13:06:54 GMT, Coleen Phillimore wrote: >> I don't know how big these values are, but if they were large then uint64_t sum could overflow. > > uint64_t count = (uint64_t)method->compiled_invocation_count(); > > They seem to be a sum of compiled_invocation_count() so maybe double is best. I reverted this to change sum and weighed_sum back to double, and add the cast back to histo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288516748 From ogillespie at openjdk.org Wed Aug 9 14:24:09 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Wed, 9 Aug 2023 14:24:09 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v3] In-Reply-To: References: Message-ID: <9qhUuT_NhFOS5vMWjeMEzOnTcpuCK5_y7iolTouSkyI=.ab4750ef-5573-4d2d-af72-1cde6c575cf2@github.com> > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: Fix jcheck Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15137/files - new: https://git.openjdk.org/jdk/pull/15137/files/74c1a27a..6fd81bdb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15137/head:pull/15137 PR: https://git.openjdk.org/jdk/pull/15137 From duke at openjdk.org Wed Aug 9 14:37:28 2023 From: duke at openjdk.org (Richard Startin) Date: Wed, 9 Aug 2023 14:37:28 GMT Subject: RFR: JDK-8313796: AsyncGetCallTrace crash on unreadable interpreter method pointer [v5] In-Reply-To: <1y4jGhKb5JXPJZIwZFMS-WIaGGbxHFZsEVPXUcaOdkw=.6cc92de4-3a52-418f-b20f-a3dea4c331db@github.com> References: <2iWbTHY2w2paFSMOIb16Ro6BYaVdpiOiG7jw7ujiUec=.ddbfb05c-adcd-4cdf-97fd-c7b879b3e652@github.com> <1y4jGhKb5JXPJZIwZFMS-WIaGGbxHFZsEVPXUcaOdkw=.6cc92de4-3a52-418f-b20f-a3dea4c331db@github.com> Message-ID: On Tue, 8 Aug 2023 21:10:53 GMT, Richard Startin wrote: >> Makes AsyncGetCallTrace more resilient to method unloading. > > Richard Startin has updated the pull request incrementally with one additional commit since the last revision: > > nullptr can't be converted to intptr_t Thanks for the helpful reviews and for sponsoring ------------- PR Comment: https://git.openjdk.org/jdk/pull/15193#issuecomment-1671460332 From azafari at openjdk.org Wed Aug 9 14:54:04 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 9 Aug 2023 14:54:04 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v6] In-Reply-To: References: Message-ID: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into wconv_jvm_options - Matched with master. - checked all usages of changed options. - backslash aligned - Review comments applied. - Fixed intx->int for Wconversion warnings. ------------- Changes: https://git.openjdk.org/jdk/pull/15164/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=05 Stats: 20 lines in 7 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/15164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15164/head:pull/15164 PR: https://git.openjdk.org/jdk/pull/15164 From azafari at openjdk.org Wed Aug 9 14:54:30 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 9 Aug 2023 14:54:30 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v3] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 07:17:32 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> backslash aligned > > src/hotspot/share/runtime/globals.hpp line 1311: > >> 1309: "Hit breakpoint when mallocing/freeing this pointer") \ >> 1310: \ >> 1311: develop(int, StackPrintLimit, 100, \ > > You can remove this cast now: > > ./share/utilities/vmError.cpp: const int limit = max_frames == -1 ? StackPrintLimit : MIN2(max_frames, (int)StackPrintLimit); Fixed. > src/hotspot/share/runtime/globals.hpp line 1748: > >> 1746: "Data sampling interval (in milliseconds)") \ >> 1747: range(PeriodicTask::min_interval, max_jint) \ >> 1748: constraint(PerfDataSamplingIntervalFunc, AfterErgo) \ > > You need to change the type of the `PerfDataSamplingIntervalFunc` as well. I changed this and checked for the other options I changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288598106 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1288601635 From azafari at openjdk.org Wed Aug 9 15:05:28 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 9 Aug 2023 15:05:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v5] In-Reply-To: <3xjlUAvmX9Vp4T4a0Q4OIrJuLs6eWUiQ6udipPiM_v8=.ba115f8a-ad56-4643-a1f1-cc0a223668f0@github.com> References: <3xjlUAvmX9Vp4T4a0Q4OIrJuLs6eWUiQ6udipPiM_v8=.ba115f8a-ad56-4643-a1f1-cc0a223668f0@github.com> Message-ID: On Wed, 9 Aug 2023 12:41:28 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Matched with master. I also changed the type of LogEventsBufferEntries in `runtime/globals.hpp` which fixes the Wconversion warnings in `utilities/events.hpp`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1671531536 From coleenp at openjdk.org Wed Aug 9 15:20:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 15:20:29 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v3] In-Reply-To: <9qhUuT_NhFOS5vMWjeMEzOnTcpuCK5_y7iolTouSkyI=.ab4750ef-5573-4d2d-af72-1cde6c575cf2@github.com> References: <9qhUuT_NhFOS5vMWjeMEzOnTcpuCK5_y7iolTouSkyI=.ab4750ef-5573-4d2d-af72-1cde6c575cf2@github.com> Message-ID: <52vqMoTwERd4wu-nhhuSx2NYxEpElcVyqy-NK6EqKd8=.dfef7e6a-3f50-4c9f-ae80-e871176a3a44@github.com> On Wed, 9 Aug 2023 14:24:09 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Fix jcheck > > Whitespace Yes, I do think the is_dead() dedicated function looks like an improvement. The peek() call is correct for the WeakHandle entries. Thank you. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1569870173 From coleenp at openjdk.org Wed Aug 9 15:43:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 15:43:28 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6] In-Reply-To: References: Message-ID: > Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. > > src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] > 1802 | _thread->dec_held_monitor_count(rec + 1); > | ~~~~^~~ > > Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - put checked_cast around getc(). - put checked_cast around getc(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15177/files - new: https://git.openjdk.org/jdk/pull/15177/files/43665637..17eaec50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=04-05 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177 PR: https://git.openjdk.org/jdk/pull/15177 From ogillespie at openjdk.org Wed Aug 9 16:16:28 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Wed, 9 Aug 2023 16:16:28 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v4] In-Reply-To: References: Message-ID: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision: - Undo nullptr 'improvement' It's implemented wrong, and not sure it's worth doing anyway. - Remove .equals is_dead arg Better to use the new is_dead function. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15137/files - new: https://git.openjdk.org/jdk/pull/15137/files/6fd81bdb..6cd4aabc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=02-03 Stats: 25 lines in 9 files changed: 0 ins; 12 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/15137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15137/head:pull/15137 PR: https://git.openjdk.org/jdk/pull/15137 From ogillespie at openjdk.org Wed Aug 9 16:17:58 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Wed, 9 Aug 2023 16:17:58 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v3] In-Reply-To: <9qhUuT_NhFOS5vMWjeMEzOnTcpuCK5_y7iolTouSkyI=.ab4750ef-5573-4d2d-af72-1cde6c575cf2@github.com> References: <9qhUuT_NhFOS5vMWjeMEzOnTcpuCK5_y7iolTouSkyI=.ab4750ef-5573-4d2d-af72-1cde6c575cf2@github.com> Message-ID: On Wed, 9 Aug 2023 14:24:09 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Fix jcheck > > Whitespace Thanks for the review Coleen. Actually @shipilev suggested that with the new `is_dead` function we might as well clean up the is_dead return value from .equals altogether, and I think it makes sense. Please take a look at the latest commit if you can. If you don't like it or it's not worth adding to this change, I'll revert it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1671651888 From aph at openjdk.org Wed Aug 9 16:52:59 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 9 Aug 2023 16:52:59 GMT Subject: RFR: 8310239: Add missing cross modifying fence in nmethod entry barriers [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 02:00:57 GMT, Dean Long wrote: > I was thinking the issue Erik was worried about is patching of nmethod code as data at safepoints. I seem to recall there are certain kinds of stubs that need to patch more than one word, so it is done at a safepoint. I see code in SafepointMechanism::update_poll_values() that calls OrderAccess::cross_modify_fence() in certain cases, so maybe that's enough? It certainly should be. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14543#issuecomment-1671762440 From coleenp at openjdk.org Wed Aug 9 16:52:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 16:52:59 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v4] In-Reply-To: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> References: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> Message-ID: On Wed, 9 Aug 2023 16:16:28 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision: > > - Undo nullptr 'improvement' > > It's implemented wrong, and not sure it's worth doing anyway. > - Remove .equals is_dead arg > > Better to use the new is_dead function. I was wondering if it would be safe (ie, the dead test needed to be in equals) but appears safe because it's at the same time. It's a good suggestion and a nice cleanup as well. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1570102269 From coleenp at openjdk.org Wed Aug 9 16:52:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 16:52:59 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com> Message-ID: On Wed, 9 Aug 2023 13:49:20 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/arguments.cpp line 1215: >> >>> 1213: } >>> 1214: } >>> 1215: c = getc(stream); >> >> How about int c0 for the getc value, then the first line in the loop does >> char c = checked_cast(c0); >> No other changes should be needed. > > There was a reason that c had to be an int. Now I'll have to rebuild and figure it out again. No, it works and is a bit better, so I made this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1288883114 From sgibbons at openjdk.org Wed Aug 9 17:11:58 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Wed, 9 Aug 2023 17:11:58 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem Message-ID: Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. Tested tier1. ------------- Commit messages: - Fix register sage; compare against ah. - Windows changes - Accelerate fmod/dmod by reducing pathlength. Changes: https://git.openjdk.org/jdk/pull/15210/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15210&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314056 Stats: 146 lines in 6 files changed: 56 ins; 73 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/15210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15210/head:pull/15210 PR: https://git.openjdk.org/jdk/pull/15210 From cjplummer at openjdk.org Wed Aug 9 18:21:31 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 9 Aug 2023 18:21:31 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v3] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce buildSharedLibraryName Needs copyright updates, but otherwise looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1570274636 From shade at openjdk.org Wed Aug 9 18:52:29 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 9 Aug 2023 18:52:29 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v4] In-Reply-To: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> References: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> Message-ID: On Wed, 9 Aug 2023 16:16:28 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision: > > - Undo nullptr 'improvement' > > It's implemented wrong, and not sure it's worth doing anyway. > - Remove .equals is_dead arg > > Better to use the new is_dead function. I like this version. Yes, I think peeling off `is_dead` completely from `equals` is safe. The only place where it is used along with `equals` is `ConcurrentHashTable::get_node`, where we collect the "is_dead" info to trigger cleanup. The symbols that are dead stay dead, so if `equals` replied `is_dead = false` earlier for a `Symbol`, then it would report `is_dead(sym) == false` again later. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1570307143 From dlong at openjdk.org Wed Aug 9 19:51:58 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 19:51:58 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader In-Reply-To: References: Message-ID: <7vNnqAv33XqnqcaIcL2Tz-lPeIO7mQ0lU-ms-abkO3E=.58a232f8-823a-43e9-b279-c06036449b95@github.com> On Wed, 9 Aug 2023 12:28:50 GMT, Coleen Phillimore wrote: > Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. > Tested with tier1-4 on linux-x64-debug and windows-x64-debug. src/hotspot/share/utilities/globalDefinitions.hpp line 1341: > 1339: : ((uintptr_t)k0 == (uintptr_t)k1) ? 0 : 1); > 1340: } > 1341: I was thinking this would hurt performance, but on x86 and aarch64 the compiler generates conditional moves instead of conditional branches. I don't like using uintptr_t here. Can't we compare void* or better yet K*? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15208#discussion_r1289103850 From dlong at openjdk.org Wed Aug 9 19:51:59 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 19:51:59 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader In-Reply-To: <7vNnqAv33XqnqcaIcL2Tz-lPeIO7mQ0lU-ms-abkO3E=.58a232f8-823a-43e9-b279-c06036449b95@github.com> References: <7vNnqAv33XqnqcaIcL2Tz-lPeIO7mQ0lU-ms-abkO3E=.58a232f8-823a-43e9-b279-c06036449b95@github.com> Message-ID: <5AhFX1CrHa5uUIXHXmucyxKm3vwcC2pZH_rSnhyLECU=.d70cd7e1-5caf-4c5d-a7c3-3b8d72eec9b6@github.com> On Wed, 9 Aug 2023 19:29:35 GMT, Dean Long wrote: >> Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug. > > src/hotspot/share/utilities/globalDefinitions.hpp line 1341: > >> 1339: : ((uintptr_t)k0 == (uintptr_t)k1) ? 0 : 1); >> 1340: } >> 1341: > > I was thinking this would hurt performance, but on x86 and aarch64 the compiler generates conditional moves instead of conditional branches. > I don't like using uintptr_t here. Can't we compare void* or better yet K*? To match primitive_equals, we can just use k0 < k1, without the cast to uintptr_t, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15208#discussion_r1289108969 From pchilanomate at openjdk.org Wed Aug 9 19:52:58 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 9 Aug 2023 19:52:58 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 15:43:28 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - put checked_cast around getc(). > - put checked_cast around getc(). Thanks for the fixes. Looks good to me. src/hotspot/share/runtime/arguments.cpp line 1184: > 1182: > 1183: char c = checked_cast(getc(stream)); > 1184: while(c != EOF && pos < (int)(sizeof(token)-1)) { I see error in some builds due to the EOF comparison though now that c is a char. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1570400279 PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289118732 From dlong at openjdk.org Wed Aug 9 20:05:58 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 20:05:58 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 15:43:28 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - put checked_cast around getc(). > - put checked_cast around getc(). src/hotspot/share/runtime/arguments.cpp line 1183: > 1181: bool result = true; > 1182: > 1183: char c = checked_cast(getc(stream)); I think this only works if "char" is signed, because EOF is -1. What I meant was: int c0 = getc(stream); while (c0 != EOF ...) { char c = checked_cast(c0); ... c0 = getc(stream); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289134766 From pchilanomate at openjdk.org Wed Aug 9 20:07:28 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 9 Aug 2023 20:07:28 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com> Message-ID: <9_wskfUjYqTIOG27mpDmO_ltC1RDl_GclltIsfZOQPw=.1447c996-764a-4d7a-96c8-2bf6e72bd85e@github.com> On Wed, 9 Aug 2023 16:40:32 GMT, Coleen Phillimore wrote: >> There was a reason that c had to be an int. Now I'll have to rebuild and figure it out again. > > No, it works and is a bit better, so I made this change. I see error in some builds due to the EOF comparison though now that c is a char. I think Dean was suggesting doing the cast inside the loop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289124669 From coleenp at openjdk.org Wed Aug 9 20:23:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 20:23:28 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 20:02:31 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: >> >> - put checked_cast around getc(). >> - put checked_cast around getc(). > > src/hotspot/share/runtime/arguments.cpp line 1183: > >> 1181: bool result = true; >> 1182: >> 1183: char c = checked_cast(getc(stream)); > > I think this only works if "char" is signed, because EOF is -1. What I meant was: > > int c0 = getc(stream); > while (c0 != EOF ...) { > char c = checked_cast(c0); > ... > c0 = getc(stream); I don't see this as any cleaner than having the checked_cast in the place where we need to store a char. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289144572 From coleenp at openjdk.org Wed Aug 9 20:23:30 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 20:23:30 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: <9_wskfUjYqTIOG27mpDmO_ltC1RDl_GclltIsfZOQPw=.1447c996-764a-4d7a-96c8-2bf6e72bd85e@github.com> References: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com> <9_wskfUjYqTIOG27mpDmO_ltC1RDl_GclltIsfZOQPw=.1447c996-764a-4d7a-96c8-2bf6e72bd85e@github.com> Message-ID: On Wed, 9 Aug 2023 19:51:29 GMT, Patricio Chilano Mateo wrote: >> No, it works and is a bit better, so I made this change. > > I see error in some builds due to the EOF comparison though now that c is a char. I think Dean was suggesting doing the cast inside the loop. That must have been the error I was seeing but couldn't remember. I'm putting this back to the version I tested completely. I don't see the point of adding another local variable here and doing the checked_cast<> until we need the char to be stored. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289138719 From coleenp at openjdk.org Wed Aug 9 20:45:00 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 20:45:00 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v7] In-Reply-To: References: Message-ID: > Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. > > src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] > 1802 | _thread->dec_held_monitor_count(rec + 1); > | ~~~~^~~ > > Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Put arguments back to the tested version. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15177/files - new: https://git.openjdk.org/jdk/pull/15177/files/17eaec50..e254b2df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177 PR: https://git.openjdk.org/jdk/pull/15177 From dlong at openjdk.org Wed Aug 9 20:48:59 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 20:48:59 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 15:43:28 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - put checked_cast around getc(). > - put checked_cast around getc(). src/hotspot/share/runtime/objectMonitor.hpp line 238: > 236: // > 237: #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \ > 238: ((in_bytes(ObjectMonitor::f ## _offset())) - (int)markWord::monitor_value) Suggestion: ((in_bytes(ObjectMonitor::f ## _offset())) - (intptr_t)markWord::monitor_value) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289155570 From coleenp at openjdk.org Wed Aug 9 20:55:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 20:55:28 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader [v2] In-Reply-To: References: Message-ID: > Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. > Tested with tier1-4 on linux-x64-debug and windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Ha, didn't need the casts after all. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15208/files - new: https://git.openjdk.org/jdk/pull/15208/files/3e1484c3..eefcbf9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15208&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15208&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15208/head:pull/15208 PR: https://git.openjdk.org/jdk/pull/15208 From dlong at openjdk.org Wed Aug 9 20:55:31 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 20:55:31 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 20:37:29 GMT, Coleen Phillimore wrote: >> Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ha, didn't need the casts after all. src/hotspot/share/utilities/globalDefinitions.hpp line 1339: > 1337: template int primitive_compare(const K& k0, const K& k1) { > 1338: return (((uintptr_t)k0 < (uintptr_t)k1) ? -1 > 1339: : ((uintptr_t)k0 == (uintptr_t)k1) ? 0 : 1); Suggestion: return k0 < k1 ? -1 : k0 == k1 ? 0 : 1; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15208#discussion_r1289165581 From dlong at openjdk.org Wed Aug 9 20:55:31 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 20:55:31 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 20:33:55 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Ha, didn't need the casts after all. > > src/hotspot/share/utilities/globalDefinitions.hpp line 1339: > >> 1337: template int primitive_compare(const K& k0, const K& k1) { >> 1338: return (((uintptr_t)k0 < (uintptr_t)k1) ? -1 >> 1339: : ((uintptr_t)k0 == (uintptr_t)k1) ? 0 : 1); > > Suggestion: > > return k0 < k1 ? -1 : k0 == k1 ? 0 : 1; Also, if this is used for signed types, we need to preserve the sign for the comparison. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15208#discussion_r1289166541 From coleenp at openjdk.org Wed Aug 9 20:55:34 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 9 Aug 2023 20:55:34 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader [v2] In-Reply-To: <5AhFX1CrHa5uUIXHXmucyxKm3vwcC2pZH_rSnhyLECU=.d70cd7e1-5caf-4c5d-a7c3-3b8d72eec9b6@github.com> References: <7vNnqAv33XqnqcaIcL2Tz-lPeIO7mQ0lU-ms-abkO3E=.58a232f8-823a-43e9-b279-c06036449b95@github.com> <5AhFX1CrHa5uUIXHXmucyxKm3vwcC2pZH_rSnhyLECU=.d70cd7e1-5caf-4c5d-a7c3-3b8d72eec9b6@github.com> Message-ID: On Wed, 9 Aug 2023 19:35:24 GMT, Dean Long wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 1341: >> >>> 1339: : ((uintptr_t)k0 == (uintptr_t)k1) ? 0 : 1); >>> 1340: } >>> 1341: >> >> I was thinking this would hurt performance, but on x86 and aarch64 the compiler generates conditional moves instead of conditional branches. >> I don't like using uintptr_t here. Can't we compare void* or better yet K*? > > To match primitive_equals, we can just use k0 < k1, without the cast to uintptr_t, right? It compiles and passes the appcds tests so I'm surprised it doesn't need the casts. I didn't think InstanceKlass pointers could be compared like that directly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15208#discussion_r1289154370 From dlong at openjdk.org Wed Aug 9 20:55:35 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 20:55:35 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader [v2] In-Reply-To: References: <7vNnqAv33XqnqcaIcL2Tz-lPeIO7mQ0lU-ms-abkO3E=.58a232f8-823a-43e9-b279-c06036449b95@github.com> <5AhFX1CrHa5uUIXHXmucyxKm3vwcC2pZH_rSnhyLECU=.d70cd7e1-5caf-4c5d-a7c3-3b8d72eec9b6@github.com> Message-ID: On Wed, 9 Aug 2023 20:22:17 GMT, Coleen Phillimore wrote: >> To match primitive_equals, we can just use k0 < k1, without the cast to uintptr_t, right? > > It compiles and passes the appcds tests so I'm surprised it doesn't need the casts. I didn't think InstanceKlass pointers could be compared like that directly. Yes, comparing pointers directly should be fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15208#discussion_r1289164534 From dlong at openjdk.org Wed Aug 9 22:33:58 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 9 Aug 2023 22:33:58 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 20:55:28 GMT, Coleen Phillimore wrote: >> Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ha, didn't need the casts after all. Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15208#pullrequestreview-1570661795 From dholmes at openjdk.org Wed Aug 9 22:35:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 9 Aug 2023 22:35:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v6] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 14:54:04 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into wconv_jvm_options > - Matched with master. > - checked all usages of changed options. > - backslash aligned > - Review comments applied. > - Fixed intx->int for Wconversion warnings. Updates look good. Thanks src/hotspot/share/runtime/globals.hpp line 446: > 444: "Enable the various ring buffer event logs") \ > 445: \ > 446: product(int, LogEventsBufferEntries, 20, DIAGNOSTIC, \ I was going to say this should keep its unsignedness but it is treated as an `int` everywhere anyway. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1570650769 PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1289260865 From sspitsyn at openjdk.org Wed Aug 9 22:46:28 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Aug 2023 22:46:28 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v3] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce buildSharedLibraryName Thank you for the update. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1570707364 From dlong at openjdk.org Thu Aug 10 00:32:28 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 10 Aug 2023 00:32:28 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6] In-Reply-To: References: Message-ID: <-HOW_BRbv5A09m9N5cXRa6MunZHR-tYouRXZcZh6hpA=.9b6d3c82-22f2-4d8d-b75a-0b4517e0772b@github.com> On Thu, 10 Aug 2023 00:13:21 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/objectMonitor.hpp line 238: >> >>> 236: // >>> 237: #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \ >>> 238: ((in_bytes(ObjectMonitor::f ## _offset())) - (int)markWord::monitor_value) >> >> Suggestion: >> >> ((in_bytes(ObjectMonitor::f ## _offset())) - (intptr_t)markWord::monitor_value) > > If this is intptr_t, it'll get a Wconversion warning on the uses that expect int. OK, in that case checked_cast() would be more correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289388423 From coleenp at openjdk.org Thu Aug 10 00:31:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 00:31:58 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 20:23:38 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: >> >> - put checked_cast around getc(). >> - put checked_cast around getc(). > > src/hotspot/share/runtime/objectMonitor.hpp line 238: > >> 236: // >> 237: #define OM_OFFSET_NO_MONITOR_VALUE_TAG(f) \ >> 238: ((in_bytes(ObjectMonitor::f ## _offset())) - (int)markWord::monitor_value) > > Suggestion: > > ((in_bytes(ObjectMonitor::f ## _offset())) - (intptr_t)markWord::monitor_value) If this is intptr_t, it'll get a Wconversion warning on the uses that expect int. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289381020 From sgibbons at openjdk.org Thu Aug 10 00:49:59 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Thu, 10 Aug 2023 00:49:59 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v2] In-Reply-To: References: Message-ID: <-IX3BljB1GgGEkEahSITcmKZnYnkBiT-9-FgA9uDPFY=.69cc9293-84f6-40da-951c-9b078522a418@github.com> > Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. > > Tested tier1. Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Move mxcsr code after denom > num test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15210/files - new: https://git.openjdk.org/jdk/pull/15210/files/0bae5e93..5b1d251f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15210&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15210&range=00-01 Stats: 11 lines in 1 file changed: 6 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15210/head:pull/15210 PR: https://git.openjdk.org/jdk/pull/15210 From dholmes at openjdk.org Thu Aug 10 01:17:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 01:17:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v6] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 14:54:04 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into wconv_jvm_options > - Matched with master. > - checked all usages of changed options. > - backslash aligned > - Review comments applied. > - Fixed intx->int for Wconversion warnings. Just noticed that `AllocatePrefetchStyle` should also be included in this. Thanks ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1570828938 From coleenp at openjdk.org Thu Aug 10 01:26:00 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 01:26:00 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v8] In-Reply-To: References: Message-ID: > Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. > > src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] > 1802 | _thread->dec_held_monitor_count(rec + 1); > | ~~~~^~~ > > Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add a checked_cast. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15177/files - new: https://git.openjdk.org/jdk/pull/15177/files/e254b2df..0e21a929 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15177&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15177/head:pull/15177 PR: https://git.openjdk.org/jdk/pull/15177 From coleenp at openjdk.org Thu Aug 10 01:29:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 01:29:28 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v6] In-Reply-To: <-HOW_BRbv5A09m9N5cXRa6MunZHR-tYouRXZcZh6hpA=.9b6d3c82-22f2-4d8d-b75a-0b4517e0772b@github.com> References: <-HOW_BRbv5A09m9N5cXRa6MunZHR-tYouRXZcZh6hpA=.9b6d3c82-22f2-4d8d-b75a-0b4517e0772b@github.com> Message-ID: On Thu, 10 Aug 2023 00:22:57 GMT, Dean Long wrote: >> If this is intptr_t, it'll get a Wconversion warning on the uses that expect int. > > OK, in that case checked_cast() would be more correct. Ok. Added a checked_cast. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289404613 From dholmes at openjdk.org Thu Aug 10 01:30:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 01:30:58 GMT Subject: RFR: 8313874 - JNI NewWeakGlobalRef throws exception for null arg [v2] In-Reply-To: <7IOJ9HRfGvZJ_SD6hmIWbMpVxvfFFQqiAsfW85o2iDs=.d7f39560-252f-4b73-822d-dfce60f344e0@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> <7IOJ9HRfGvZJ_SD6hmIWbMpVxvfFFQqiAsfW85o2iDs=.d7f39560-252f-4b73-822d-dfce60f344e0@github.com> Message-ID: On Tue, 8 Aug 2023 13:20:55 GMT, Oli Gillespie wrote: >> According to the JNI spec for NewWeakGlobalRef: >> >>> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. >> >> The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. >> >> (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback > > Move test case to existing test, use .not_null() for null check. Looks good. Thanks. I will file a follow up RFE to look at the spec issue @stefank pointed out. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15188#pullrequestreview-1570841760 From amenkov at openjdk.org Thu Aug 10 02:03:28 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 10 Aug 2023 02:03:28 GMT Subject: RFR: JDK-8313656: assert(!JvmtiExport::can_support_virtual_threads()) with -XX:-DoJVMTIVirtualThreadTransitions Message-ID: The change fixes several issues with capability management: - handling can_support_virtual_threads capability. JvmtiExport::can_support_virtual_threads() should be set to true if we have one or more agent with can_support_virtual_threads capability; - JvmtiManageCapabilities (used by GetPotentialCapabilities/AddCapabilities/RelinquishCapabilities/GetCapabilities) is not thread safe; - SuspendAllVirtualThreads and ResumeAllVirtualThreads should check capability on the caller agent (and not JvmtiExport::can_support_virtual_threads()). Testing: tier1..5 ------------- Commit messages: - capabilities for VT Changes: https://git.openjdk.org/jdk/pull/15219/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15219&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313656 Stats: 53 lines in 3 files changed: 47 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15219.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15219/head:pull/15219 PR: https://git.openjdk.org/jdk/pull/15219 From coleenp at openjdk.org Thu Aug 10 02:06:38 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 02:06:38 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v6] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 14:54:04 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into wconv_jvm_options > - Matched with master. > - checked all usages of changed options. > - backslash aligned > - Review comments applied. > - Fixed intx->int for Wconversion warnings. The criteria for choosing flags was whether they were causing -Wconversion warnings, which this one doesn't. That said, it would be consistent to change this one since other AllocatePrefetch flags are changed. There are likely many other flags that can be int not intx. They can be changed in a different patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1672419781 From dlong at openjdk.org Thu Aug 10 02:06:39 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 10 Aug 2023 02:06:39 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v8] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 01:26:00 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a checked_cast. Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1570873804 From jwaters at openjdk.org Thu Aug 10 04:04:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Aug 2023 04:04:58 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Remove negation in os_windows.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/51230f3d..4e3329b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From dholmes at openjdk.org Thu Aug 10 05:08:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 05:08:29 GMT Subject: RFR: 8308850: Change JVM options with small ranges from 64 to 32 bits, for globals.hpp [v6] In-Reply-To: References: Message-ID: <-JgChGRgQXuQ6_l0crjDUNVMcuAkwuP192MSGj8GB7A=.a75445ba-6177-4021-9030-0dfbcaa11443@github.com> On Thu, 10 Aug 2023 01:50:45 GMT, Coleen Phillimore wrote: > The criteria for choosing flags was whether they were causing -Wconversion warnings, There is nothing in the PR or JBS to indicate this is the case. I assumed this would fix all oversized flags as the title indicates. If this is only a restricted subset perhaps the title and description should be updated to reflect that. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1672549503 From dholmes at openjdk.org Thu Aug 10 05:36:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 05:36:58 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Hotspot test changes look fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1571033557 From dholmes at openjdk.org Thu Aug 10 05:51:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 05:51:28 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v4] In-Reply-To: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> References: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> Message-ID: On Wed, 9 Aug 2023 16:16:28 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision: > > - Undo nullptr 'improvement' > > It's implemented wrong, and not sure it's worth doing anyway. > - Remove .equals is_dead arg > > Better to use the new is_dead function. Based on @coleenp 's explanation of why the increment to the ref count is done, I expected to see it removed now that `equals(Symbol* value)` no longer cares about `is_dead`. I still find it very surprising that `equals` would have this side-effect of bumping the ref-count. At the very least there should be an explanatory comment as to why it is there and some guidance on when the caller should decrement again. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1571050496 From dholmes at openjdk.org Thu Aug 10 06:34:59 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 06:34:59 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: <9-LtWZiG4OVsEdz0yxqYKYvIqXSFQTKZJBlnjsXglnk=.907abaaa-5ce2-45fb-9184-e404831f9dd0@github.com> <9_wskfUjYqTIOG27mpDmO_ltC1RDl_GclltIsfZOQPw=.1447c996-764a-4d7a-96c8-2bf6e72bd85e@github.com> Message-ID: On Wed, 9 Aug 2023 20:06:58 GMT, Coleen Phillimore wrote: >> I see error in some builds due to the EOF comparison though now that c is a char. I think Dean was suggesting doing the cast inside the loop. > > That must have been the error I was seeing but couldn't remember. I'm putting this back to the version I tested completely. I don't see the point of adding another local variable here and doing the checked_cast<> until we need the char to be stored. `getc` returns an int because it has to be able to return all valid char values plus EOF. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289606432 From dholmes at openjdk.org Thu Aug 10 07:18:07 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 07:18:07 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v8] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 01:26:00 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a checked_cast. Overall seems okay. A couple of minor comments. Thanks. Clicked wrong button :) ------------- PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1571161170 Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15177#pullrequestreview-1571163699 From dholmes at openjdk.org Thu Aug 10 07:19:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 07:19:58 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 20:09:56 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make bytecode.hpp index() functions return u2 not long. src/hotspot/share/runtime/javaThread.hpp line 599: > 597: > 598: void inc_held_monitor_count(intx i = 1, bool jni = false); > 599: void dec_held_monitor_count(intx i = 1, bool jni = false); Does the parameter type need to be changed? AFAICS we never increment by other than one in any case (and inc/dec imply one - else they should be add/sub). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1289651653 From aboldtch at openjdk.org Thu Aug 10 07:38:03 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 10 Aug 2023 07:38:03 GMT Subject: Integrated: 8311508: ZGC: RAII use of IntelJccErratumAlignment In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 13:49:24 GMT, Axel Boldt-Christmas wrote: > Fixed the locations where unnamed IntelJccErratumAlignment circumvented the correctness asserts. > Also strengthened the asserts so that a IntelJccErratumAlignment RAII object scope must surround at least some instruction. > > Tested GHA and tier1,tier2 This pull request has now been integrated. Changeset: e080a0b4 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/e080a0b4c0878dc19f40ef0f51e645f3a4708c62 Stats: 6 lines in 3 files changed: 3 ins; 0 del; 3 mod 8311508: ZGC: RAII use of IntelJccErratumAlignment Reviewed-by: stefank, shade, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/15191 From mbaesken at openjdk.org Thu Aug 10 07:44:58 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 10 Aug 2023 07:44:58 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v4] In-Reply-To: References: Message-ID: > There is coding e.g. in > https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 > that deals with shared lib naming on different OS. > This code should be simplified. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust COPYRIGHT headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15151/files - new: https://git.openjdk.org/jdk/pull/15151/files/9f9c5b25..5e8dfa79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=02-03 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151 PR: https://git.openjdk.org/jdk/pull/15151 From mbaesken at openjdk.org Thu Aug 10 07:48:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 10 Aug 2023 07:48:02 GMT Subject: Integrated: JDK-8313670: Simplify shared lib name handling code in some tests In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 09:59:41 GMT, Matthias Baesken wrote: > There is coding e.g. in > https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 > that deals with shared lib naming on different OS. > This code should be simplified. This pull request has now been integrated. Changeset: 6dba2026 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/6dba2026d72de6a67aa0209749ded8174b088904 Stats: 130 lines in 9 files changed: 22 ins; 87 del; 21 mod 8313670: Simplify shared lib name handling code in some tests Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/15151 From mbaesken at openjdk.org Thu Aug 10 07:47:58 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 10 Aug 2023 07:47:58 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v3] In-Reply-To: References: Message-ID: <8CSDWiLaG1Ny0Z81n2R_qsVUbF-URNetXDfoCclLXUU=.5c6d9e7a-de4f-41bf-9ed8-2c2fb48f8f31@github.com> On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce buildSharedLibraryName Hi Chris and Serguei, thanks for the reviews ! I adjusted the COPYRIGHT years. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15151#issuecomment-1672693986 From dholmes at openjdk.org Thu Aug 10 08:06:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 08:06:58 GMT Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v4] In-Reply-To: References: Message-ID: <-ozXnVe5STjD6ltTvUVIxOzTbAs0YN8dD9rq0iBCKQA=.e2e1a087-47ad-4103-811d-4b693eec23ab@github.com> On Thu, 10 Aug 2023 07:44:58 GMT, Matthias Baesken wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust COPYRIGHT headers A belated thumbs up from me too. Thanks. ------------- PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1571269550 From stuefe at openjdk.org Thu Aug 10 08:17:03 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 10 Aug 2023 08:17:03 GMT Subject: RFR: 8310160: Make GC APIs for handling archive heap objects agnostic of GC policy [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 20:29:46 GMT, Dan Heidinga wrote: >>> I hope to implement a fast path for relocation that avoids using the hash tables at all. If we can get the total alloc + reloc time to be about 1.5ms, then it would be just as fast as before when relocation is enabled. >> >> I've implemented a fast relocation lookup. It currently uses a table of the same size as the archived heap objects, but I can reduce that to 1/2 the size. >> >> See https://github.com/openjdk/jdk/compare/master...iklam:jdk:8310823-materialize-cds-heap-with-regular-alloc?expand=1 >> >> This is implemented by about 330 lines of code in archiveHeapLoader.cpp. The code is templatized to try out different approaches (like `-XX:+NahlRawAlloc` and `-XX:+NahlUseAccessAPI`), so it can be further simplified. >> >> There's only one thing that's not yet implemented -- the equivalent of `ArchiveHeapLoader::patch_native_pointers()`. I'll do that next. >> >> >> $ java -XX:+NewArchiveHeapLoading -Xmx128m -Xlog:cds+gc --version >> [0.004s][info][cds,gc] Delayed allocation records alloced: 640 >> [0.004s][info][cds,gc] Load Time: 1388458 >> >> >> The whole allocation + reloc takes about 1.4ms. It's about 1.25ms slower in the worst case (when the "old" code doesn't have to relocate -- see the `(**)` in the table below). It's 0.8ms slower when the "old" code has to relocate. >> >> >> All times are in ms, for "java --version" >> >> ==================================== >> Dump: java -Xshare:dump -Xmx128m >> >> G1 old new diff >> 128m 14.476 15.754 +1.277 (**) >> 8192m 15.359 16.085 +0.726 >> >> >> Serial old new >> 128m 13.442 14.241 +0.798 >> 8192m 13.740 14.532 +0.791 >> >> ==================================== >> Dump: java -Xshare:dump -Xmx8192m >> >> G1 old new diff >> 128m 14.975 15.787 +0.812 >> 2048m 16.239 17.035 +0.796 >> 8192m 14.821 16.042 +1.221 (**) >> >> >> Serial old new >> 128m 13.444 14.167 +0.723 >> 8192m 13.717 14.502 +0.785 >> >> >> While the code is slower than before, it's a lot simpler. It works on all collectors. I tested on ZGC, but I think Shenandoah should work as well. >> >> The cost is about 1.3 ms per MB of archived heap objects. This may be acceptable as it's a small fraction of JVM bootstrap. We have about 1MB of archived objects now, and we don't expect this size to drastically increase in the near future. >> >> The extra memory cost is: >> >> - a temporary in-memory copy of the archived heap o... > >> The cost is about 1.3 ms per MB of archived heap objects. This may be acceptable as it's a small fraction of JVM bootstrap. We have about 1MB of archived objects now, and we don't expect this size to drastically increase in the near future. > > Looking ahead to Project Leyden, I wouldn't be surprised if the current 1MB of archived heap became much larger. Demo apps on Graal Native Image are often ~4MB of image heap, and while it's not an apples-to-apples comparison, it suggests that somewhere between 5MB & 10MB isn't unreasonable for Leyden. > > Using 10MB as a baseline for easy math, 1.3ms/MB * 10MB = 13 ms for the new code? And (1.3ms-0.8ms) = 0.5ms/MB * 10MB = 5ms for the old code? Assuming I've interpreted the numbers correctly and importably that they scale linearly, it seems worth preserving the mmap approach for collectors that can support it. > > Does that seem reasonable? And justify preserving the mmap approach? I share @DanHeidinga 's concern about scaling. Is it just me or is 1.3ms/MB rather high? Even without mmap, do we have to allocate memory for each object individually? Could we not allocate a large block of memory for all objects, and copy them over linearly? Or allow the heap to overprovision, such that heaps with humongous limits can observe internal limits like that? E.g. Universe::heap()->mem_allocate_maybe_more(minsize, maxsize, &result_size). One nice effect Ioi's approach has is that we could finally eliminate the requirement of "if you map archived heap objects, the narrow Klass encoding base has to be *exactly* the start of the shared metaspace region". Because when we copy the objects, we can now, at little additional cost, recompute the narrow Klass IDs too. That could allow us to use unscaled nKlass encoding at CDS runtime, which we could not do before. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1672747936 From ogillespie at openjdk.org Thu Aug 10 09:10:01 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 10 Aug 2023 09:10:01 GMT Subject: Integrated: 8313874 - JNI NewWeakGlobalRef throws exception for null arg In-Reply-To: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> References: <32VpsBuP5tanAmtKud89NyAmyd2HoN66yN59xeLIhiU=.2ce6f1b4-7d99-4c44-bb21-60f725d12fb6@github.com> Message-ID: On Tue, 8 Aug 2023 10:40:30 GMT, Oli Gillespie wrote: > According to the JNI spec for NewWeakGlobalRef: > >> Returns NULL if obj refers to null, or if obj was a weak global reference, or if the VM runs out of memory. If the VM runs out of memory, an OutOfMemoryError will be thrown. > > The current behaviour is that `NewWeakGlobalRef(nullptr)` throws an OutOfMemoryError, which it should not. > > (Thanks @dholmes-ora for confirming the issue and suggesting a fix.) This pull request has now been integrated. Changeset: 028b3ae1 Author: Oli Gillespie Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/028b3ae1b162bd8f7c340bfa6e9487ca83697955 Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod 8313874: JNI NewWeakGlobalRef throws exception for null arg Reviewed-by: dholmes, kbarrett, shade ------------- PR: https://git.openjdk.org/jdk/pull/15188 From ogillespie at openjdk.org Thu Aug 10 09:36:01 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 10 Aug 2023 09:36:01 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v4] In-Reply-To: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> References: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> Message-ID: On Wed, 9 Aug 2023 16:16:28 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision: > > - Undo nullptr 'improvement' > > It's implemented wrong, and not sure it's worth doing anyway. > - Remove .equals is_dead arg > > Better to use the new is_dead function. Thanks all. @dholmes-ora : Along with the is_dead return, Coleen also mentioned: > Moving [increment refcount] to the Get class (SymbolTableGet) might be too late - ie something may have discovered that the refcount went to zero before incrementing it. Which I understand to mean it's safest to keep it in equals, if possible. That being said, as far as I can tell, LOOKUP_FUNC (SymbolTableLookup) and FOUND_FUNC (SymbolTableGet) do *seem* to always be called within the same critical section, with no is_dead cleanup in-between so maybe it would be okay with the current code to move it to FOUND_FUNC. But I suppose ensuring nobody relies on the is_dead value between those two functions in the future is tricky. Equally I'm happy to add a comment, though I'm not sure I understand it perfectly so happy to take suggestions. How about something like: When this returns true (i.e. the value matches this symbol, and this symbol is not dead), the symbol's reference count is incremented. This is to ensure that as soon as a symbol is found in the table, it is kept alive for the caller - otherwise another thread could consider it dead and clean it up, before the caller has a chance to strongly reference it. The caller is responsible for calling `Symbol::decrement_refcount` when finished with the symbol. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1672853746 From fbredberg at openjdk.org Thu Aug 10 10:25:35 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 10 Aug 2023 10:25:35 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v2] In-Reply-To: References: Message-ID: > Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. > Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. > > By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. Fredrik Bredberg has updated the pull request incrementally with two additional commits since the last revision: - Updated linux-ppc64le after review - Updated after review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14545/files - new: https://git.openjdk.org/jdk/pull/14545/files/f7488cba..e54b7090 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14545&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14545&range=00-01 Stats: 58 lines in 13 files changed: 1 ins; 43 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/14545.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14545/head:pull/14545 PR: https://git.openjdk.org/jdk/pull/14545 From fbredberg at openjdk.org Thu Aug 10 10:25:37 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 10 Aug 2023 10:25:37 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames In-Reply-To: <-c8g0jAXEsNr6LEMupIBRiAzCceOWD66779zJYv7KpA=.e0f9f1ce-1d03-4dba-82a9-11eededcb50c@github.com> References: <-c8g0jAXEsNr6LEMupIBRiAzCceOWD66779zJYv7KpA=.e0f9f1ce-1d03-4dba-82a9-11eededcb50c@github.com> Message-ID: On Mon, 7 Aug 2023 14:48:48 GMT, Martin Doerr wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > I'd use `Rtemp2`. Note that one of the computations can be simplified: > > > diff --git a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp > index 00722171058..721a1467ed8 100644 > --- a/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp > +++ b/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp > @@ -1994,10 +1994,10 @@ void InterpreterMacroAssembler::add_monitor_to_stack(bool stack_is_empty, Regist > "size of a monitor must respect alignment of SP"); > > resize_frame(-monitor_size, /*temp*/esp); // Allocate space for new monitor > - sub(R11_scratch1, R1_SP, esp); // esp contains fp > - sradi(R11_scratch1, R11_scratch1, Interpreter::logStackElementSize); > + subf(Rtemp2, esp, R1_SP); // esp contains fp > + sradi(Rtemp2, Rtemp2, Interpreter::logStackElementSize); > // Store relativized top_frame_sp > - std(R11_scratch1, _ijava_state_neg(top_frame_sp), esp); // esp contains fp > + std(Rtemp2, _ijava_state_neg(top_frame_sp), esp); // esp contains fp > > // Shuffle expression stack down. Recall that stack_base points > // just above the new expression stack bottom. Old_tos and new_tos > diff --git a/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp b/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp > index 7df95d5672e..e3a8b3fbd94 100644 > --- a/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp > +++ b/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp > @@ -1061,9 +1061,8 @@ void TemplateInterpreterGenerator::generate_fixed_frame(bool native_call, Regist > __ std(R0, _ijava_state_neg(oop_tmp), R1_SP); // only used for native_call > > // Store sender's SP and this frame's top SP. > - __ subf(R12_scratch2, Rtop_frame_size, R1_SP); > __ std(R21_sender_SP, _ijava_state_neg(sender_sp), R1_SP); > - __ sub(R12_scratch2, R12_scratch2, R1_SP); > + __ neg(R12_scratch2, Rtop_frame_size); > __ sradi(R12_scratch2, R12_scratch2, Interpreter::logStackElementSize); > // Store relativized top_frame_sp > __ std(R12_scratch2, _ijava_state_neg(top_frame_sp), R1_SP); > > > Testing: tier1 and TestOptionsWithRangesDynamic.java have passed. Yea Rtemp2 seems to work fine @TheRealMDoerr. Since Rtemp1 is used as an in-parameter (esp) and therefore not usable for me, I thought that Rtemp2 was also an in-parameter and not usable for me (the declaration of slot is very similar to esp). But after your comment I realized that Rtemp2 is not an in-parameter, so it's usable for me as a temp register. Also thankyou for drawing my attention to the fact that one of the computations could be simplified. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1672926063 From coleenp at openjdk.org Thu Aug 10 12:06:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 12:06:29 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v4] In-Reply-To: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> References: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> Message-ID: On Wed, 9 Aug 2023 16:16:28 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision: > > - Undo nullptr 'improvement' > > It's implemented wrong, and not sure it's worth doing anyway. > - Remove .equals is_dead arg > > Better to use the new is_dead function. The comment seems fine. Bit verbose but that's ok. Don't move the refcount out of equals into the lookup function. When we implemented this, this was where we thought this needed to be for safety, and this code has not changed to change that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1673070715 From coleenp at openjdk.org Thu Aug 10 12:07:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 12:07:59 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v8] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 01:26:00 GMT, Coleen Phillimore wrote: >> Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. >> >> src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] >> 1802 | _thread->dec_held_monitor_count(rec + 1); >> | ~~~~^~~ >> >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a checked_cast. Thanks for the reviews, Patricio, Dean and David. I believe I addressed all the comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15177#issuecomment-1673078895 From coleenp at openjdk.org Thu Aug 10 12:09:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 12:09:29 GMT Subject: RFR: 8313882: Fix -Wconversion warnings in runtime code [v2] In-Reply-To: References: Message-ID: <2EPJzGnsBYxehzOGMWH4KkKzh6XMRNioQvM8ov21d-g=.42af4d3e-ed1b-4de8-b844-62893e0982ae@github.com> On Thu, 10 Aug 2023 07:02:35 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make bytecode.hpp index() functions return u2 not long. > > src/hotspot/share/runtime/javaThread.hpp line 599: > >> 597: >> 598: void inc_held_monitor_count(intx i = 1, bool jni = false); >> 599: void dec_held_monitor_count(intx i = 1, bool jni = false); > > Does the parameter type need to be changed? AFAICS we never increment by other than one in any case (and inc/dec imply one - else they should be add/sub). Yes, the parameter type needed to be changed because: void do_monitor(ObjectMonitor* mid) { intx rec = mid->complete_exit(_thread); _thread->dec_held_monitor_count(rec + 1); } In general, I only widen things when there's a warning produced. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15177#discussion_r1290010985 From coleenp at openjdk.org Thu Aug 10 12:26:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 12:26:28 GMT Subject: Integrated: 8313882: Fix -Wconversion warnings in runtime code In-Reply-To: References: Message-ID: <8fsAx47Xb01FdWOZXnrWwgYx-29Kv3iPkKxJcC0rR3c=.1b4a33c6-cdac-4929-93c7-edec59186dec@github.com> On Mon, 7 Aug 2023 12:57:35 GMT, Coleen Phillimore wrote: > Here are fixes to silence -Wconversion warnings in runtime code. Use direct cast for 64 bit int to double, otherwise default to checked_cast<>. I changed the declaration of _held_monitor_count and _jni_monitor count to intx to fix cascade of warnings coming from this. > > src/hotspot/share/runtime/synchronizer.cpp:1802:41: warning: conversion from 'intx' {aka 'long int'} to 'int' may change value [-Wconversion] > 1802 | _thread->dec_held_monitor_count(rec + 1); > | ~~~~^~~ > > Tested with tier1-4 on linux-x64-debug and windows-x64-debug and tier1 on Oracle supported platforms. This pull request has now been integrated. Changeset: f47767ff Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/f47767ffef29c777e2da0262fa3299564d59f461 Stats: 138 lines in 26 files changed: 3 ins; 9 del; 126 mod 8313882: Fix -Wconversion warnings in runtime code Reviewed-by: pchilanomate, dlong, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/15177 From ogillespie at openjdk.org Thu Aug 10 12:28:03 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 10 Aug 2023 12:28:03 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v5] In-Reply-To: References: Message-ID: <2IlGruyfA0-0zNGC3whxZsvHNJ39w2chxAVnUXrWDqI=.bce16d75-915f-4137-937e-b1369b9f1e4f@github.com> On Thu, 10 Aug 2023 12:11:13 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie 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: > > - Add comment for equals() behaviour > - Merge remote-tracking branch 'origin/master' into 8313678 > > Hopefully fix GHA for RISC cross-compilation > - Undo nullptr 'improvement' > > It's implemented wrong, and not sure it's worth doing anyway. > - Remove .equals is_dead arg > > Better to use the new is_dead function. > - Fix jcheck > > Whitespace > - Fix jcheck > > Whitespace > - Review comments - add dedicated is_dead function > - 8313678 - SymbolTable can leak Symbols during cleanup > > The cleanup routine of concurrentHashTable uses the lookup > function for its secondary effect of checking whether any > particular value is dead or not. It does not actually care about > the main purpose of the lookup function, i.e. checking if a particular > value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of > incrementing the Symbol refcount when the lookup succeeds. This is > presumably with the assumption that a successful lookup will result > in a newly held reference. concurrentHashTable's delete_in_bucket > can break this assumption by completing a successful lookup without > retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new > test case), a newly inserted Symbol can have a refcount of 2 instead > of 1. Even if all legitimate references to this Symbol are removed, > it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to > use the value after the lookup, or not, allowing SymbolTable to > only increment the refcount when appropriate. Thanks. Added a trimmed version of the comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1673102066 From ogillespie at openjdk.org Thu Aug 10 12:28:02 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 10 Aug 2023 12:28:02 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v5] In-Reply-To: References: Message-ID: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Oli Gillespie 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: - Add comment for equals() behaviour - Merge remote-tracking branch 'origin/master' into 8313678 Hopefully fix GHA for RISC cross-compilation - Undo nullptr 'improvement' It's implemented wrong, and not sure it's worth doing anyway. - Remove .equals is_dead arg Better to use the new is_dead function. - Fix jcheck Whitespace - Fix jcheck Whitespace - Review comments - add dedicated is_dead function - 8313678 - SymbolTable can leak Symbols during cleanup The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15137/files - new: https://git.openjdk.org/jdk/pull/15137/files/6cd4aabc..a8445534 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=03-04 Stats: 8386 lines in 370 files changed: 3457 ins; 2111 del; 2818 mod Patch: https://git.openjdk.org/jdk/pull/15137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15137/head:pull/15137 PR: https://git.openjdk.org/jdk/pull/15137 From dholmes at openjdk.org Thu Aug 10 13:06:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Aug 2023 13:06:58 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v5] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 12:28:02 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie 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: > > - Add comment for equals() behaviour > - Merge remote-tracking branch 'origin/master' into 8313678 > > Hopefully fix GHA for RISC cross-compilation > - Undo nullptr 'improvement' > > It's implemented wrong, and not sure it's worth doing anyway. > - Remove .equals is_dead arg > > Better to use the new is_dead function. > - Fix jcheck > > Whitespace > - Fix jcheck > > Whitespace > - Review comments - add dedicated is_dead function > - 8313678 - SymbolTable can leak Symbols during cleanup > > The cleanup routine of concurrentHashTable uses the lookup > function for its secondary effect of checking whether any > particular value is dead or not. It does not actually care about > the main purpose of the lookup function, i.e. checking if a particular > value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of > incrementing the Symbol refcount when the lookup succeeds. This is > presumably with the assumption that a successful lookup will result > in a newly held reference. concurrentHashTable's delete_in_bucket > can break this assumption by completing a successful lookup without > retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new > test case), a newly inserted Symbol can have a refcount of 2 instead > of 1. Even if all legitimate references to this Symbol are removed, > it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to > use the value after the lookup, or not, allowing SymbolTable to > only increment the refcount when appropriate. src/hotspot/share/classfile/symbolTable.cpp line 378: > 376: } > 377: // Note: When equals() returns "true", the symbol's refcount is incremented. > 378: // This is need to ensure that symbol is kept alive before equals() returns to caller, nit: needed nit: the caller Thanks for adding the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15137#discussion_r1290086245 From ogillespie at openjdk.org Thu Aug 10 13:41:06 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 10 Aug 2023 13:41:06 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v6] In-Reply-To: References: Message-ID: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: Tweak comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15137/files - new: https://git.openjdk.org/jdk/pull/15137/files/a8445534..dd5ee5fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15137/head:pull/15137 PR: https://git.openjdk.org/jdk/pull/15137 From azafari at openjdk.org Thu Aug 10 14:45:30 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 10 Aug 2023 14:45:30 GMT Subject: RFR: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: References: Message-ID: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: Fixed a missed option. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15164/files - new: https://git.openjdk.org/jdk/pull/15164/files/2e25bbf8..51df0d35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15164&range=05-06 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15164/head:pull/15164 PR: https://git.openjdk.org/jdk/pull/15164 From coleenp at openjdk.org Thu Aug 10 15:05:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 15:05:29 GMT Subject: RFR: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> References: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> Message-ID: On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a missed option. Still good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1572120640 From jvernee at openjdk.org Thu Aug 10 15:05:58 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Aug 2023 15:05:58 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: <7K7n7ahPfknWU6q5Wu9upiPKhMmXzwA5jthvvJmt7A4=.3072efdc-e2cc-4250-a5b1-feabe104ae30@github.com> On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Thanks for the reviews so far. That also reminds me to mention: while there are a lot of files touched, most of the updates a simple 1 line changes to test files removing the `@enablePreview` tag from the jtreg test information. So, probably most of this is easy to review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673384016 From iklam at openjdk.org Thu Aug 10 15:20:37 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 10 Aug 2023 15:20:37 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 20:55:28 GMT, Coleen Phillimore wrote: >> Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ha, didn't need the casts after all. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15208#pullrequestreview-1572133703 From coleenp at openjdk.org Thu Aug 10 15:39:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 15:39:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux Message-ID: This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. ------------- Commit messages: - Fix cgroupSubsystem_linux.cpp - Unset Wconversion for testing. - Fix signals to take int buflen, fixed return types of syscalls - Fix attachListener.cpp warnings. - change send/recv parameter type to match OS. - Fix -Wconversion warnings in os_linux. Changes: https://git.openjdk.org/jdk/pull/15229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314114 Stats: 125 lines in 21 files changed: 0 ins; 0 del; 125 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From coleenp at openjdk.org Thu Aug 10 15:40:30 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 15:40:30 GMT Subject: RFR: 8313905: Checked_cast assert in CDS compare_by_loader [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 20:55:28 GMT, Coleen Phillimore wrote: >> Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. >> Tested with tier1-4 on linux-x64-debug and windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Ha, didn't need the casts after all. Thanks Dean and Ioi. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15208#issuecomment-1673440390 From coleenp at openjdk.org Thu Aug 10 15:40:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 15:40:31 GMT Subject: Integrated: 8313905: Checked_cast assert in CDS compare_by_loader In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 12:28:50 GMT, Coleen Phillimore wrote: > Fix a checked_cast<> assert caused by changes to CDS code, but not using address calculations for comparison operators for class loaders or InstanceKlass pointers. > Tested with tier1-4 on linux-x64-debug and windows-x64-debug. This pull request has now been integrated. Changeset: bd1b9427 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/bd1b9427410c458215e9e89eeff6e4d30592a4a4 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod 8313905: Checked_cast assert in CDS compare_by_loader Reviewed-by: dlong, iklam ------------- PR: https://git.openjdk.org/jdk/pull/15208 From iklam at openjdk.org Thu Aug 10 16:20:06 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 10 Aug 2023 16:20:06 GMT Subject: RFR: 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> References: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> Message-ID: On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a missed option. src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 261: > 259: do_int_flag(AllocatePrefetchLines) \ > 260: do_int_flag(AllocatePrefetchStepSize) \ > 261: do_int_flag(AllocatePrefetchStyle) \ Why is AllocatePrefetchInstr not changed? It seems to use 0-3 only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1290366462 From coleenp at openjdk.org Thu Aug 10 17:20:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 17:20:29 GMT Subject: RFR: 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: References: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> Message-ID: On Thu, 10 Aug 2023 16:07:14 GMT, Ioi Lam wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed a missed option. > > src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 261: > >> 259: do_int_flag(AllocatePrefetchLines) \ >> 260: do_int_flag(AllocatePrefetchStepSize) \ >> 261: do_int_flag(AllocatePrefetchStyle) \ > > Why is AllocatePrefetchInstr not changed? It seems to use 0-3 only. Looks like from the constraints, it's allowed to be max_intx on some platforms, so changing this would be a functional change. JVMFlag::Error AllocatePrefetchInstrConstraintFunc(intx value, bool verbose) { intx max_value = max_intx; #if defined(X86) max_value = 3; #endif ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1290427987 From jvernee at openjdk.org Thu Aug 10 17:57:01 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Aug 2023 17:57:01 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v2] In-Reply-To: References: Message-ID: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - 8313894: Rename isTrivial linker option to critical Reviewed-by: pminborg, mcimadamore - 8313680: Disallow combining caputreCallState with isTrivial Reviewed-by: mcimadamore - Merge branch 'master' into JEP22 - use immutable map for fallback linker canonical layouts - 8313265: Move the FFM API out of preview Reviewed-by: mcimadamore - 8313005: Ensure native access check can fold away Reviewed-by: mcimadamore - 8312981: Make the linker API required Reviewed-by: mcimadamore - 8312615: Ensure jdk_foreign tests pass on linux-x86 Reviewed-by: mcimadamore - 8312186: TestStringEncodingFails for UTF-32 Reviewed-by: mcimadamore - 8312059: Clarify the documention for variadic functions 8310646: Javadoc around prototype-less functions might be incorrect Reviewed-by: mcimadamore - ... and 7 more: https://git.openjdk.org/jdk/compare/23fe2ece...74bbe721 ------------- Changes: https://git.openjdk.org/jdk/pull/15103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=01 Stats: 2817 lines in 230 files changed: 1239 ins; 894 del; 684 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From jvernee at openjdk.org Thu Aug 10 17:57:03 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Aug 2023 17:57:03 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Addressing some offline review comments. Two more (small) changes have been added: - Disallow combining the `captureCallState` and `isTrivial` (see https://github.com/openjdk/panama-foreign/pull/856) - Rename `isTrivial` to `critical` (see https://github.com/openjdk/panama-foreign/pull/859) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673627002 From iklam at openjdk.org Thu Aug 10 18:07:28 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 10 Aug 2023 18:07:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: References: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> Message-ID: On Thu, 10 Aug 2023 16:59:00 GMT, Coleen Phillimore wrote: >> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 261: >> >>> 259: do_int_flag(AllocatePrefetchLines) \ >>> 260: do_int_flag(AllocatePrefetchStepSize) \ >>> 261: do_int_flag(AllocatePrefetchStyle) \ >> >> Why is AllocatePrefetchInstr not changed? It seems to use 0-3 only. > > Looks like from the constraints, it's allowed to be max_intx on some platforms, so changing this would be a functional change. > > JVMFlag::Error AllocatePrefetchInstrConstraintFunc(intx value, bool verbose) { > intx max_value = max_intx; > #if defined(X86) > max_value = 3; > #endif OK, that sounds reasonable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1290492755 From dlong at openjdk.org Thu Aug 10 19:25:31 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 10 Aug 2023 19:25:31 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 15:22:07 GMT, Coleen Phillimore wrote: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. src/hotspot/os/aix/attachListener_aix.cpp line 289: > 287: > 288: ssize_t off = 0; > 289: ssize_t left = max_len; Doesn't this cause a sign-conversion warning because read expects size_t? src/hotspot/os/aix/os_aix.cpp line 3026: > 3024: time_t t1 = get_mtime(file1); > 3025: time_t t2 = get_mtime(file2); > 3026: return checked_cast(t1 - t2); It seems like checked_cast<> could fail if the file has a bad timestamp far in the future. Suggestion: return primitive_compare(t1, t2); src/hotspot/os/bsd/os_bsd.cpp line 2211: > 2209: struct timespec filetime1 = get_mtime(file1); > 2210: struct timespec filetime2 = get_mtime(file2); > 2211: time_t diff = filetime1.tv_sec - filetime2.tv_sec; Is time_t guaranteed to be signed? Suggestion: int diff = primitive_compare(filetime1.tv_sec, filetime2.tv_sec); src/hotspot/os/bsd/os_bsd.cpp line 2213: > 2211: time_t diff = filetime1.tv_sec - filetime2.tv_sec; > 2212: if (diff == 0) { > 2213: diff = filetime1.tv_nsec - filetime2.tv_nsec; Suggestion: diff = primitive_compare(filetime1.tv_nsec, filetime2.tv_nsec); src/hotspot/os/bsd/os_bsd.cpp line 2215: > 2213: diff = filetime1.tv_nsec - filetime2.tv_nsec; > 2214: } > 2215: return checked_cast(diff); Suggestion: return diff; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290561229 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290567457 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290569988 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290570883 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290571285 From dlong at openjdk.org Thu Aug 10 20:20:59 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 10 Aug 2023 20:20:59 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux In-Reply-To: References: Message-ID: <9adGJpUsZXsKoTDvYpcG_SdNKdVEwAXxkocxhuNdjlE=.ce13e296-42cc-48d8-bc05-81102caf3838@github.com> On Thu, 10 Aug 2023 15:22:07 GMT, Coleen Phillimore wrote: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 497: > 495: > 496: if (quota > -1 && period > 0) { > 497: quota_count = (int)ceilf((float)quota / (float)period); Should be OK except for the pathological case of quota near INT_MAX and period == 1. src/hotspot/os/linux/os_linux.cpp line 1604: > 1602: > 1603: Elf32_Ehdr elf_head; > 1604: size_t diag_msg_max_length=ebuflen-strlen(ebuf); Underflow will result in very large unsigned number. Do we need helper functions for unsigned math that checks for underflow/overflow? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290605284 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290619501 From coleenp at openjdk.org Thu Aug 10 20:35:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 20:35:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 18:58:19 GMT, Dean Long wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > src/hotspot/os/aix/attachListener_aix.cpp line 289: > >> 287: >> 288: ssize_t off = 0; >> 289: ssize_t left = max_len; > > Doesn't this cause a sign-conversion warning because read expects size_t? I don't have -Wsign-conversion on, only -Wconversion, so I don't get -Wsign-conversion warnings for hotspot files. This same change is made to os/linux/attachListener_linux.cpp. Suggestions how to fix? > src/hotspot/os/aix/os_aix.cpp line 3026: > >> 3024: time_t t1 = get_mtime(file1); >> 3025: time_t t2 = get_mtime(file2); >> 3026: return checked_cast(t1 - t2); > > It seems like checked_cast<> could fail if the file has a bad timestamp far in the future. > Suggestion: > > return primitive_compare(t1, t2); This is a good idea to use primitive_compare. > src/hotspot/os/linux/os_linux.cpp line 1604: > >> 1602: >> 1603: Elf32_Ehdr elf_head; >> 1604: size_t diag_msg_max_length=ebuflen-strlen(ebuf); > > Underflow will result in very large unsigned number. Do we need helper functions for unsigned math that checks for underflow/overflow? I could have just checked_cast(strlen(ebuf)); since it's 100% unlikely that the buffer is 2,147,483,647 chars long. I don't understand why strlen returns a size_t tbh. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290627670 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290629641 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290644112 From coleenp at openjdk.org Thu Aug 10 20:33:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 20:33:31 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 15:22:07 GMT, Coleen Phillimore wrote: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Thanks for the quick feedback. ------------- PR Review: https://git.openjdk.org/jdk/pull/15229#pullrequestreview-1572651359 From jvernee at openjdk.org Thu Aug 10 20:43:28 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Aug 2023 20:43:28 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: Message-ID: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - enable fallback linker on linux x86 in GHA - make Arena::allocate abstract ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/74bbe721..147e79d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=01-02 Stats: 20 lines in 4 files changed: 9 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From dlong at openjdk.org Thu Aug 10 21:36:28 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 10 Aug 2023 21:36:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 20:07:47 GMT, Coleen Phillimore wrote: >> src/hotspot/os/aix/attachListener_aix.cpp line 289: >> >>> 287: >>> 288: ssize_t off = 0; >>> 289: ssize_t left = max_len; >> >> Doesn't this cause a sign-conversion warning because read expects size_t? > > I don't have -Wsign-conversion on, only -Wconversion, so I don't get -Wsign-conversion warnings for hotspot files. This same change is made to os/linux/attachListener_linux.cpp. Suggestions how to fix? checked_cast() where necessary, unfortunately. >> src/hotspot/os/linux/os_linux.cpp line 1604: >> >>> 1602: >>> 1603: Elf32_Ehdr elf_head; >>> 1604: size_t diag_msg_max_length=ebuflen-strlen(ebuf); >> >> Underflow will result in very large unsigned number. Do we need helper functions for unsigned math that checks for underflow/overflow? > > I could have just checked_cast(strlen(ebuf)); since it's 100% unlikely that the buffer is 2,147,483,647 chars long. I don't understand why strlen returns a size_t tbh. I was more concerned about missing a buffer overflow, resulting in strlen(ebuf) > ebuflen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290694809 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290696399 From dlong at openjdk.org Thu Aug 10 21:48:58 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 10 Aug 2023 21:48:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux In-Reply-To: References: Message-ID: <_dAJdu-ZGg7csi0fNJ0alvmzQSJK3GYaGF1XMaeI6k4=.6af79954-0069-40e1-978e-f8e809afd1e6@github.com> On Thu, 10 Aug 2023 15:22:07 GMT, Coleen Phillimore wrote: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. src/hotspot/os/linux/os_linux.cpp line 3204: > 3202: for (int j = 0; j < cpu_map_valid_size; j++) { > 3203: if (cpu_map[j] != 0) { > 3204: for (int k = 0; k < BitsPerCLong; k++) { For changes to lines 3145 to 3204, wouldn't it be better to keep using size_t? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290708439 From bpb at openjdk.org Thu Aug 10 21:49:58 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 10 Aug 2023 21:49:58 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 20:43:28 GMT, Jorn Vernee wrote: >> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: >> >> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. >> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. >> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. >> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. >> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. >> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) >> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. >> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. >> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO... > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - enable fallback linker on linux x86 in GHA > - make Arena::allocate abstract The few, simple NIO changes are fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673943826 From dlong at openjdk.org Thu Aug 10 22:02:58 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 10 Aug 2023 22:02:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux In-Reply-To: References: Message-ID: <5ZhW9hqn8N2xeUlkgOn8yLXIcpqDFI27K9J14cUgCGo=.81e0e200-8be7-4d58-8a46-be5286854d99@github.com> On Thu, 10 Aug 2023 15:22:07 GMT, Coleen Phillimore wrote: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 59: > 57: }; > 58: > 59: static int64_t membarrier(int cmd, unsigned int flags, int cpu_id) { Seems OK, but if syscall returns `long` then intrptr_t seems a better fit for 32-bit platforms. Or we could narrow to int here, as long as membarrier (and futex) aren't returning pointers or memory addresses. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290721898 From coleenp at openjdk.org Thu Aug 10 22:52:30 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 22:52:30 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: Message-ID: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore 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: - Dean's suggested changes. - Merge branch 'master' into os-conversion - Fix cgroupSubsystem_linux.cpp - Unset Wconversion for testing. - Fix signals to take int buflen, fixed return types of syscalls - Fix attachListener.cpp warnings. - change send/recv parameter type to match OS. - Fix -Wconversion warnings in os_linux. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/d289f15b..fd5464d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=00-01 Stats: 435 lines in 29 files changed: 163 ins; 209 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From coleenp at openjdk.org Thu Aug 10 22:52:33 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 10 Aug 2023 22:52:33 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <_dAJdu-ZGg7csi0fNJ0alvmzQSJK3GYaGF1XMaeI6k4=.6af79954-0069-40e1-978e-f8e809afd1e6@github.com> References: <_dAJdu-ZGg7csi0fNJ0alvmzQSJK3GYaGF1XMaeI6k4=.6af79954-0069-40e1-978e-f8e809afd1e6@github.com> Message-ID: On Thu, 10 Aug 2023 21:38:28 GMT, Dean Long wrote: >> Coleen Phillimore 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: >> >> - Dean's suggested changes. >> - Merge branch 'master' into os-conversion >> - Fix cgroupSubsystem_linux.cpp >> - Unset Wconversion for testing. >> - Fix signals to take int buflen, fixed return types of syscalls >> - Fix attachListener.cpp warnings. >> - change send/recv parameter type to match OS. >> - Fix -Wconversion warnings in os_linux. > > src/hotspot/os/linux/os_linux.cpp line 3204: > >> 3202: for (int j = 0; j < cpu_map_valid_size; j++) { >> 3203: if (cpu_map[j] != 0) { >> 3204: for (int k = 0; k < BitsPerCLong; k++) { > > For changes to lines 3145 to 3204, wouldn't it be better to keep using size_t? I started that way and it required more casts. This was the path of least cast-ness. > src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 59: > >> 57: }; >> 58: >> 59: static int64_t membarrier(int cmd, unsigned int flags, int cpu_id) { > > Seems OK, but if syscall returns `long` then intrptr_t seems a better fit for 32-bit platforms. Or we could narrow to int here, as long as membarrier (and futex) aren't returning pointers or memory addresses. I think intptr_t is a better choice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290740835 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290741805 From dlong at openjdk.org Thu Aug 10 23:46:29 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 10 Aug 2023 23:46:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 22:52:30 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore 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: > > - Dean's suggested changes. > - Merge branch 'master' into os-conversion > - Fix cgroupSubsystem_linux.cpp > - Unset Wconversion for testing. > - Fix signals to take int buflen, fixed return types of syscalls > - Fix attachListener.cpp warnings. > - change send/recv parameter type to match OS. > - Fix -Wconversion warnings in os_linux. src/hotspot/os/linux/attachListener_linux.cpp line 270: > 268: > 269: size_t off = 0; > 270: size_t left = max_len; It might be better to use ssize_t here, because of code like ` left -= n;` below. If that underflows as unsigned then the loop won't terminate like it should. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290773295 From liach at openjdk.org Thu Aug 10 23:46:58 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 10 Aug 2023 23:46:58 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 20:43:28 GMT, Jorn Vernee wrote: >> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: >> >> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. >> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. >> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. >> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. >> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. >> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) >> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. >> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. >> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO... > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - enable fallback linker on linux x86 in GHA > - make Arena::allocate abstract Just curious, what's the rationale for finalizing the API when there are significant changes from the last preview? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1674051619 From dlong at openjdk.org Fri Aug 11 00:16:28 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 11 Aug 2023 00:16:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 22:52:30 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore 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: > > - Dean's suggested changes. > - Merge branch 'master' into os-conversion > - Fix cgroupSubsystem_linux.cpp > - Unset Wconversion for testing. > - Fix signals to take int buflen, fixed return types of syscalls > - Fix attachListener.cpp warnings. > - change send/recv parameter type to match OS. > - Fix -Wconversion warnings in os_linux. src/hotspot/share/runtime/os.hpp line 781: > 779: static void print_siginfo(outputStream* st, const void* siginfo); > 780: static void print_signal_handlers(outputStream* st, char* buf, int buflen); > 781: static void print_date_and_time(outputStream* st, char* buf, size_t buflen); I understand you are trying to minimize changes, but these functions all used size_t consistently. It seems odd to change the type of just this one function. src/hotspot/share/utilities/decoder_elf.cpp line 70: > 68: filepath[JVM_MAXPATHLEN - 1] = '\0'; > 69: int offset_in_library = -1; > 70: if (!os::dll_address_to_library_name(pc, filepath, (int)sizeof(filepath), &offset_in_library)) { How about fixing dll_address_to_library_name to use size_t like all the rest of the os:: functions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290784155 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290784640 From coleenp at openjdk.org Fri Aug 11 01:03:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 01:03:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 23:34:37 GMT, Dean Long wrote: >> Coleen Phillimore 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: >> >> - Dean's suggested changes. >> - Merge branch 'master' into os-conversion >> - Fix cgroupSubsystem_linux.cpp >> - Unset Wconversion for testing. >> - Fix signals to take int buflen, fixed return types of syscalls >> - Fix attachListener.cpp warnings. >> - change send/recv parameter type to match OS. >> - Fix -Wconversion warnings in os_linux. > > src/hotspot/os/linux/attachListener_linux.cpp line 270: > >> 268: >> 269: size_t off = 0; >> 270: size_t left = max_len; > > It might be better to use ssize_t here, because of code like > ` left -= n;` > below. If that underflows as unsigned then the loop won't terminate like it should. Theoretically but we assert that n <= left. > src/hotspot/share/runtime/os.hpp line 781: > >> 779: static void print_siginfo(outputStream* st, const void* siginfo); >> 780: static void print_signal_handlers(outputStream* st, char* buf, int buflen); >> 781: static void print_date_and_time(outputStream* st, char* buf, size_t buflen); > > I understand you are trying to minimize changes, but these functions all used size_t consistently. It seems odd to change the type of just this one function. The reason I narrowed the types is because none of the callers pass size_t and widening dll_address_to_library_name requires platform dependent changes, and also changing the Decoder::decode() functions (or adding checked_casts<> somewhere along the way) and its subtypes. It's not simply to minimize changes, but it is. It's to minimize casting, or checked_casting which is also not pleasant to look at in the code everywhere. This is why I chose passing int as buflen. There's other functions that pass int as buflen. Also, there's no world where we pass in a buffer that's greater than 32,000. It's used for error reporting. > src/hotspot/share/utilities/decoder_elf.cpp line 70: > >> 68: filepath[JVM_MAXPATHLEN - 1] = '\0'; >> 69: int offset_in_library = -1; >> 70: if (!os::dll_address_to_library_name(pc, filepath, (int)sizeof(filepath), &offset_in_library)) { > > How about fixing dll_address_to_library_name to use size_t like all the rest of the os:: functions? It's painful. See above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290803875 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290801182 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290801365 From dholmes at openjdk.org Fri Aug 11 01:30:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 11 Aug 2023 01:30:28 GMT Subject: RFR: 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> References: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> Message-ID: On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a missed option. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1572903552 From dholmes at openjdk.org Fri Aug 11 02:14:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 11 Aug 2023 02:14:28 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v6] In-Reply-To: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> References: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> Message-ID: On Thu, 10 Aug 2023 13:41:06 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Tweak comment Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1572920131 From dholmes at openjdk.org Fri Aug 11 02:42:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 11 Aug 2023 02:42:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: Message-ID: <8ZfzGf8NPyxvcjzfSlvOST0eToJzpuMJDVQ28rOqgBQ=.3c4a1bc7-fe99-4ada-8b63-0c1aae550c59@github.com> On Fri, 11 Aug 2023 00:40:21 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/os.hpp line 781: >> >>> 779: static void print_siginfo(outputStream* st, const void* siginfo); >>> 780: static void print_signal_handlers(outputStream* st, char* buf, int buflen); >>> 781: static void print_date_and_time(outputStream* st, char* buf, size_t buflen); >> >> I understand you are trying to minimize changes, but these functions all used size_t consistently. It seems odd to change the type of just this one function. > > The reason I narrowed the types is because none of the callers pass size_t and widening dll_address_to_library_name requires platform dependent changes, and also changing the Decoder::decode() functions (or adding checked_casts<> somewhere along the way) and its subtypes. > It's not simply to minimize changes, but it is. It's to minimize casting, or checked_casting which is also not pleasant to look at in the code everywhere. This is why I chose passing int as buflen. There's other functions that pass int as buflen. > Also, there's no world where we pass in a buffer that's greater than 32,000. It's used for error reporting. I counted (via grep) 62 occurrences of `int buflen` and 47 occurrences of `size_t` buflen in the hotspot code. So while it does look odd to have two different forms right next to each other, there is at least established precedent for each. Unfortunately these `-Wconversion` changes in general seem the antithesis of code-cleanup and consistency as they force changes in limited contexts, resulting in inconsistencies unless we let the changes fan out to extreme degrees. I would have preferred in many cases to handle overflow/underflow via assertions rather than via the primitive type system. This quest for `-Wconversion` compliance is causing a great deal of pain - hats off to @coleenp for enduring that pain to put these PRs together. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290836647 From dholmes at openjdk.org Fri Aug 11 03:44:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 11 Aug 2023 03:44:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 22:52:30 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore 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: > > - Dean's suggested changes. > - Merge branch 'master' into os-conversion > - Fix cgroupSubsystem_linux.cpp > - Unset Wconversion for testing. > - Fix signals to take int buflen, fixed return types of syscalls > - Fix attachListener.cpp warnings. > - change send/recv parameter type to match OS. > - Fix -Wconversion warnings in os_linux. Sorry Coleen lots of comments/queries - many of which apply to multiple sites (I didn't flag them all). Thanks. src/hotspot/os/aix/attachListener_aix.cpp line 279: > 277: // name ("load", "datadump", ...), and is an argument > 278: int expected_str_count = 2 + AttachOperation::arg_count_max; > 279: const unsigned max_len = (sizeof(ver_str) + 1) + (AttachOperation::name_length_max + 1) + size_t instead? src/hotspot/os/aix/attachListener_aix.cpp line 296: > 294: // hang in the clean-up when shutting down. > 295: n = read(s, buf+off, left); > 296: assert(n <= checked_cast(left), "buffer was too small, impossible!"); why ssize_t here? src/hotspot/os/bsd/attachListener_bsd.cpp line 273: > 271: > 272: do { > 273: ssize_t n; Why ssize_t here but int in the AIX version? src/hotspot/os/linux/os_linux.cpp line 404: > 402: // thread id is used to access /proc. > 403: pid_t os::Linux::gettid() { > 404: int64_t rslt = syscall(SYS_gettid); syscall returns an int src/hotspot/os/linux/os_linux.cpp line 426: > 424: > 425: void os::Linux::initialize_system_info() { > 426: set_processor_count(checked_cast(sysconf(_SC_NPROCESSORS_CONF))); checked_cast seems excessive here and on other sysconf calls. src/hotspot/os/linux/os_linux.cpp line 745: > 743: Monitor* sync = osthread->startThread_lock(); > 744: > 745: osthread->set_thread_id(checked_cast(os::current_thread_id())); This doesn't look right: `current_thread_id()` returns `intx` and `set_thread_id` takes `thread_id_t` src/hotspot/os/linux/os_linux.cpp line 1272: > 1270: fp = os::fopen("/proc/self/stat", "r"); > 1271: if (fp) { > 1272: statlen = checked_cast(fread(stat, 1, 2047, fp)); checked_cast seems unnecessary given we're reading max 2047 elements. src/hotspot/os/linux/os_linux.cpp line 1604: > 1602: > 1603: Elf32_Ehdr elf_head; > 1604: int diag_msg_max_length=ebuflen-checked_cast(strlen(ebuf)); can we add spaces around operators while changing this please. src/hotspot/os/linux/os_linux.cpp line 2669: > 2667: // determine if this is a legacy image or modules image > 2668: // modules image doesn't have "jre" subdirectory > 2669: len = (int)strlen(buf); Why raw cast here when other uses of strlen have had checked_cast applied? src/hotspot/os/linux/os_linux.cpp line 2991: > 2989: #endif > 2990: > 2991: return (retval == -1) ? checked_cast(retval) : cpu; If retval is -1 you can just return -1. And if cpu is uint and the function returns int then surely we need a cast on cpu here? src/hotspot/os/linux/waitBarrier_linux.cpp line 40: > 38: #endif > 39: > 40: static intptr_t futex(volatile int *addr, int futex_op, int op_arg) { Why do this? syscall returns an int. src/hotspot/os/linux/waitBarrier_linux.cpp line 54: > 52: assert(_futex_barrier != 0, "Should be armed/non-zero."); > 53: _futex_barrier = 0; > 54: intptr_t s = futex(&_futex_barrier, futex returns an int src/hotspot/os/posix/os_posix.cpp line 92: > 90: static jlong initial_time_count = 0; > 91: > 92: static int64_t clock_tics_per_sec = 100; why do we need to do this? It would get promoted in any expression using 64-bit variables src/hotspot/os/posix/os_posix.cpp line 448: > 446: void os::Posix::print_uptime_info(outputStream* st) { > 447: int bootsec = -1; > 448: int64_t currsec = time(nullptr); We should probably cast here even if the compiler doesn't complain, as we don't know what a time_t actually is. src/hotspot/os/posix/os_posix.cpp line 803: > 801: > 802: ssize_t os::recv(int fd, char* buf, size_t nBytes, uint flags) { > 803: RESTARTABLE_RETURN_INT(::recv(fd, buf, nBytes, flags)); Note the name of the macro: this is supposed to return int. We need a new macro for RESTARTABLE_RETURN_SSIZE_T src/hotspot/os/posix/os_posix.cpp line 1335: > 1333: static void to_abstime(timespec* abstime, jlong timeout, > 1334: bool isAbsolute, bool isRealtime) { > 1335: DEBUG_ONLY(int64_t max_secs = MAX_SECS;) Actually I think this should be a time_t. src/hotspot/os/posix/os_posix.hpp line 48: > 46: > 47: #define RESTARTABLE_RETURN_INT(_cmd) do { \ > 48: ssize_t _result; \ Ah no - please don't do this. Please define a new macro. src/hotspot/os/posix/signals_posix.cpp line 1732: > 1730: if (sig > MAX2(SIGSEGV, SIGBUS) && // See 4355769. > 1731: sig < NSIG) { // Must be legal signal and fit into sigflags[]. > 1732: PosixSignals::SR_signum = checked_cast(sig); checked cast seems unnecessary given the range check ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15229#pullrequestreview-1572936556 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290841203 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290841532 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290843224 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290846602 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290847411 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290848989 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290849910 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290850648 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290851238 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290852797 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290854029 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290854138 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290854821 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290855178 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290855777 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290856533 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290856892 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290857533 From dholmes at openjdk.org Fri Aug 11 03:45:00 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 11 Aug 2023 03:45:00 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <9adGJpUsZXsKoTDvYpcG_SdNKdVEwAXxkocxhuNdjlE=.ce13e296-42cc-48d8-bc05-81102caf3838@github.com> References: <9adGJpUsZXsKoTDvYpcG_SdNKdVEwAXxkocxhuNdjlE=.ce13e296-42cc-48d8-bc05-81102caf3838@github.com> Message-ID: <7PnQf12I-HCecZHMoCj7g0LobvUXmJPpiG5n81ga5fI=.b06bbfb8-44b7-435a-a364-5e06879e3876@github.com> On Thu, 10 Aug 2023 19:43:37 GMT, Dean Long wrote: >> Coleen Phillimore 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: >> >> - Dean's suggested changes. >> - Merge branch 'master' into os-conversion >> - Fix cgroupSubsystem_linux.cpp >> - Unset Wconversion for testing. >> - Fix signals to take int buflen, fixed return types of syscalls >> - Fix attachListener.cpp warnings. >> - change send/recv parameter type to match OS. >> - Fix -Wconversion warnings in os_linux. > > src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 497: > >> 495: >> 496: if (quota > -1 && period > 0) { >> 497: quota_count = (int)ceilf((float)quota / (float)period); > > Should be OK except for the pathological case of quota near INT_MAX and period == 1. Are you concerned that the float representation of INT_MAX/1 could be INT_MAX+epsilon so the ceil function increases it to INT_MAX+1? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290846093 From dholmes at openjdk.org Fri Aug 11 03:45:02 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 11 Aug 2023 03:45:02 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <_dAJdu-ZGg7csi0fNJ0alvmzQSJK3GYaGF1XMaeI6k4=.6af79954-0069-40e1-978e-f8e809afd1e6@github.com> Message-ID: On Thu, 10 Aug 2023 22:30:55 GMT, Coleen Phillimore wrote: >> src/hotspot/os/linux/os_linux.cpp line 3204: >> >>> 3202: for (int j = 0; j < cpu_map_valid_size; j++) { >>> 3203: if (cpu_map[j] != 0) { >>> 3204: for (int k = 0; k < BitsPerCLong; k++) { >> >> For changes to lines 3145 to 3204, wouldn't it be better to keep using size_t? > > I started that way and it required more casts. This was the path of least cast-ness. For some reason I have an aversion to seeing a `size_t` loop index variable. These changes to `int` are a pleasant surprise. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290853385 From haosun at openjdk.org Fri Aug 11 04:11:58 2023 From: haosun at openjdk.org (Hao Sun) Date: Fri, 11 Aug 2023 04:11:58 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 10:25:35 GMT, Fredrik Bredberg wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with two additional commits since the last revision: > > - Updated linux-ppc64le after review > - Updated after review src/hotspot/share/runtime/frame.cpp line 1624: > 1622: st->print_cr(" %s %s %s", spacer, spacer, fv.description); > 1623: } else { > 1624: if (on_heap Along with the removal of this check, `on_heap` is not used in this function. Should we remove this parameter? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14545#discussion_r1290855139 From thomas.stuefe at gmail.com Fri Aug 11 06:13:10 2023 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 11 Aug 2023 08:13:10 +0200 Subject: Why is HeapBaseMinAddress by default so large? In-Reply-To: References: Message-ID: Answering my question to the best of my ability: There are two aspects to it; the aforementioned sbrk blockage on platforms whose libc's implement malloc solely based on brk(); and safety against accidental NULL dereferences. The OSes have limits too. Linux has vm.mmap_min_addr, typically set to 64 KB. MacOS forbids mappings below 4 GB completely since M1. In all cases, safety against NULL dereferencing has been cited as the reason for these limits. Unless I miss a third reason, I believe it would be fine to lower HeapBaseMinAddress to low-MB values. Larger than the largest possible fixed structure in the JVM (e.g. Klass can be > 4 MB in rare cases) to make us crash reliably on NULL dereferences. But low enough to still afford us a much larger part of the valuable low-address range below 4 GB. Cheers, Thomas On Fri, Jul 21, 2023 at 8:29?AM Thomas St?fe wrote: > Hi, > > I am trying to understand why the default value for HeapBaseMinAddress is > so large (2G on all of our platforms). When attempting to allocate heap or > class space for unscaled encoding, this denies us half of the valuable > space below 4G. I think it is unnecessary. Using lower address ranges is > absolutely possible (e.g. Shenandoah reserves collection sets as low as > 0x10000, and that works fine). > > One answer had been "because we don't want to obstruct sbrk() and cause > malloc OOMs". But to my knowledge, the only platforms that had that > particular problem were Solaris and AIX. > > Solaris is no more. AIX solves it differently and much smarter by > declaring a configurable "no-reserve-zone" atop the sbrk() and preventing > os::reserve_memory from mmap'ing there. That works wherever sbrk happens to > be, and for every mapping the JVM reserves, not just for the heap. > > Looking through the history, I see that HeapBaseMinAddress was introduced > by Vladimir in 2009 with 6791178: "Specialize for zero as the compressed > oop vm heap base". From the start, the default values were mostly 2G. I > could find no RFR thread for that change that discussed the > patch. @Vladimir : do you maybe still know how you came up with the > default? > > Thanks, Thomas > > [1] https://github.com/openjdk/jdk/commit/69f9ddee905f > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlong at openjdk.org Fri Aug 11 07:03:31 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 11 Aug 2023 07:03:31 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <7PnQf12I-HCecZHMoCj7g0LobvUXmJPpiG5n81ga5fI=.b06bbfb8-44b7-435a-a364-5e06879e3876@github.com> References: <9adGJpUsZXsKoTDvYpcG_SdNKdVEwAXxkocxhuNdjlE=.ce13e296-42cc-48d8-bc05-81102caf3838@github.com> <7PnQf12I-HCecZHMoCj7g0LobvUXmJPpiG5n81ga5fI=.b06bbfb8-44b7-435a-a364-5e06879e3876@github.com> Message-ID: On Fri, 11 Aug 2023 02:48:47 GMT, David Holmes wrote: >> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 497: >> >>> 495: >>> 496: if (quota > -1 && period > 0) { >>> 497: quota_count = (int)ceilf((float)quota / (float)period); >> >> Should be OK except for the pathological case of quota near INT_MAX and period == 1. > > Are you concerned that the float representation of INT_MAX/1 could be INT_MAX+epsilon so the ceil function increases it to INT_MAX+1? Yes, exactly, and we have hit similar bugs before. But the bug seems harmless here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1290960192 From dlong at openjdk.org Fri Aug 11 07:04:29 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 11 Aug 2023 07:04:29 GMT Subject: RFR: 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> References: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> Message-ID: On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a missed option. Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15164#pullrequestreview-1573080897 From tschatzl at openjdk.org Fri Aug 11 07:34:59 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 11 Aug 2023 07:34:59 GMT Subject: RFR: 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: References: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> Message-ID: On Thu, 10 Aug 2023 17:57:12 GMT, Ioi Lam wrote: >> Looks like from the constraints, it's allowed to be max_intx on some platforms, so changing this would be a functional change. >> >> JVMFlag::Error AllocatePrefetchInstrConstraintFunc(intx value, bool verbose) { >> intx max_value = max_intx; >> #if defined(X86) >> max_value = 3; >> #endif > > OK, that sounds reasonable. Fwiw, only x86 uses `AllocatePrefetchInstr`. Other platforms never use it, so its value for those is meaningless. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15164#discussion_r1290976345 From jwaters at openjdk.org Fri Aug 11 08:02:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 11 Aug 2023 08:02:58 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com> Message-ID: On Wed, 9 Aug 2023 06:30:08 GMT, Thomas Stuefe wrote: >> This is a weird one, but in awt we #define malloc Do_Not_Use_Malloc... And so on. Without this reordering awt_ole.h (which includes comdef.h) also uses the redefined malloc somewhere (I could not find where in comip.h that it's used) which breaks compilation. I do find it strange that without permissive- it doesn't break though. Same applies to the other reordering of includes > > Oh. That's not good. Having such an undocumented reliance on order of include just begs to bitrot at some point. Any chance you could unravel that mystery, maybe in a later RFE? For now, can you please add a comment at those places where you changed include order for that reason? I can try doing that, yes. There was actually a commit before this one that addressed the same issue in awt, but it missed this one since without -permissive- this error isn't caught, see [8241087](https://bugs.openjdk.org/browse/JDK-8241087) Looking at the error logs, I believe this may be due to an issue this causes with templates in the comip.h header, but I don't think that's the main problem to be worried about, rather it's that malloc (and calloc and realloc and the JDK's ExceptionOccured method too by the way) is redefined like this in the first place. I don't have any ideas for how to deal with that at the moment unfortunately ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1291004217 From mdoerr at openjdk.org Fri Aug 11 09:17:29 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 11 Aug 2023 09:17:29 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v2] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 10:25:35 GMT, Fredrik Bredberg wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with two additional commits since the last revision: > > - Updated linux-ppc64le after review > - Updated after review Thanks for taking care of PPC64! Test results look good so far. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1674418120 From jvernee at openjdk.org Fri Aug 11 12:37:59 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 11 Aug 2023 12:37:59 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v4] In-Reply-To: References: Message-ID: <2oLXen9Xs8SSrIgV9q_2KV0CA0ioUIdUZDqtsSkQ-BI=.b30a8a5b-1f03-480e-8d53-9f107ab35d64@github.com> > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: remove spurious imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/147e79d3..141096b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From coleenp at openjdk.org Fri Aug 11 13:19:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 13:19:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: References: Message-ID: <7yarX3P667rC9TOG1GoZRuQlfuj_93mHPFlXyymvaOw=.d7b33422-c080-4713-8e75-a15fc305a715@github.com> > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: David's suggested changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/fd5464d7..6777a2a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=01-02 Stats: 17 lines in 4 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From coleenp at openjdk.org Fri Aug 11 13:30:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 13:30:59 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: References: <9adGJpUsZXsKoTDvYpcG_SdNKdVEwAXxkocxhuNdjlE=.ce13e296-42cc-48d8-bc05-81102caf3838@github.com> <7PnQf12I-HCecZHMoCj7g0LobvUXmJPpiG5n81ga5fI=.b06bbfb8-44b7-435a-a364-5e06879e3876@github.com> Message-ID: On Fri, 11 Aug 2023 06:53:54 GMT, Dean Long wrote: >> Are you concerned that the float representation of INT_MAX/1 could be INT_MAX+epsilon so the ceil function increases it to INT_MAX+1? > > Yes, exactly, and we have hit similar bugs before. But the bug seems harmless here. So, comment? What should it say? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291256785 From coleenp at openjdk.org Fri Aug 11 13:29:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 13:29:59 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: Message-ID: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> On Fri, 11 Aug 2023 02:34:35 GMT, David Holmes wrote: >> Coleen Phillimore 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: >> >> - Dean's suggested changes. >> - Merge branch 'master' into os-conversion >> - Fix cgroupSubsystem_linux.cpp >> - Unset Wconversion for testing. >> - Fix signals to take int buflen, fixed return types of syscalls >> - Fix attachListener.cpp warnings. >> - change send/recv parameter type to match OS. >> - Fix -Wconversion warnings in os_linux. > > src/hotspot/os/aix/attachListener_aix.cpp line 279: > >> 277: // name ("load", "datadump", ...), and is an argument >> 278: int expected_str_count = 2 + AttachOperation::arg_count_max; >> 279: const unsigned max_len = (sizeof(ver_str) + 1) + (AttachOperation::name_length_max + 1) + > > size_t instead? The reason I changed it was to assign into size_t below without sign conversion. > src/hotspot/os/aix/attachListener_aix.cpp line 296: > >> 294: // hang in the clean-up when shutting down. >> 295: n = read(s, buf+off, left); >> 296: assert(n <= checked_cast(left), "buffer was too small, impossible!"); > > why ssize_t here? This gets a sign comparison warning without the cast, which thankfully we do enable. > src/hotspot/os/bsd/attachListener_bsd.cpp line 273: > >> 271: >> 272: do { >> 273: ssize_t n; > > Why ssize_t here but int in the AIX version? I was trying to be consistent with linux and failed. This code is duplicated or mostly duplicated for aix, bsd and linux. Somebody should fix that. > src/hotspot/os/linux/os_linux.cpp line 404: > >> 402: // thread id is used to access /proc. >> 403: pid_t os::Linux::gettid() { >> 404: int64_t rslt = syscall(SYS_gettid); > > syscall returns an int It doesn't. I got a Wconversion warning converting to int here. I wouldn't have changed it otherwise. src/hotspot/os/linux/os_linux.cpp:404:21: warning: conversion from 'long int' to 'int' may change value [-Wconversion] 404 | int rslt = syscall(SYS_gettid); | ~~~~~~~^~~~~~~~~~~~ > src/hotspot/os/linux/os_linux.cpp line 426: > >> 424: >> 425: void os::Linux::initialize_system_info() { >> 426: set_processor_count(checked_cast(sysconf(_SC_NPROCESSORS_CONF))); > > checked_cast seems excessive here and on other sysconf calls. One of you wants checked_cast<> everywhere and another of you doesn't. Given that we don't know from local code inspection that the result fits in an int, I chose checked_cast<> for these calls. > src/hotspot/os/linux/os_linux.cpp line 745: > >> 743: Monitor* sync = osthread->startThread_lock(); >> 744: >> 745: osthread->set_thread_id(checked_cast(os::current_thread_id())); > > This doesn't look right: `current_thread_id()` returns `intx` and `set_thread_id` takes `thread_id_t` src/hotspot/os/linux/os_linux.cpp:745:48: warning: conversion from 'intx' {aka 'long int'} to 'OSThread::thread_id_t' {aka 'int'} may change value [-Wconversion] 745 | osthread->set_thread_id(os::current_thread_id()); | ~~~~~~~~~~~~~~~~~~~~~^~ > src/hotspot/os/linux/os_linux.cpp line 1272: > >> 1270: fp = os::fopen("/proc/self/stat", "r"); >> 1271: if (fp) { >> 1272: statlen = checked_cast(fread(stat, 1, 2047, fp)); > > checked_cast seems unnecessary given we're reading max 2047 elements. Made statlen size_t to match fread return. > src/hotspot/os/linux/os_linux.cpp line 1604: > >> 1602: >> 1603: Elf32_Ehdr elf_head; >> 1604: int diag_msg_max_length=ebuflen-checked_cast(strlen(ebuf)); > > can we add spaces around operators while changing this please. ok > src/hotspot/os/linux/os_linux.cpp line 2669: > >> 2667: // determine if this is a legacy image or modules image >> 2668: // modules image doesn't have "jre" subdirectory >> 2669: len = (int)strlen(buf); > > Why raw cast here when other uses of strlen have had checked_cast applied? Most of the vm code casts strlen result to int because it's always an int. strlen returning size_t for a small buffer is really annoying. Maybe a checked_cast<> would catch overflow though and maybe it's a good idea. It's weird how fgets takes int and not size_t. > src/hotspot/os/linux/os_linux.cpp line 2991: > >> 2989: #endif >> 2990: >> 2991: return (retval == -1) ? checked_cast(retval) : cpu; > > If retval is -1 you can just return -1. And if cpu is uint and the function returns int then surely we need a cast on cpu here? I don't have -Wsign-conversion on. I'm not that much of a masochist. Fixed return value though. > src/hotspot/os/linux/waitBarrier_linux.cpp line 40: > >> 38: #endif >> 39: >> 40: static intptr_t futex(volatile int *addr, int futex_op, int op_arg) { > > Why do this? syscall returns an int. It does not. > src/hotspot/os/linux/waitBarrier_linux.cpp line 54: > >> 52: assert(_futex_barrier != 0, "Should be armed/non-zero."); >> 53: _futex_barrier = 0; >> 54: intptr_t s = futex(&_futex_barrier, > > futex returns an int src/hotspot/os/linux/waitBarrier_linux.cpp:41:17: warning: conversion from 'long int' to 'int' may change value [-Wconversion] 41 | return syscall(SYS_futex, addr, futex_op, op_arg, nullptr, nullptr, 0); | ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/hotspot/os/posix/os_posix.cpp line 92: > >> 90: static jlong initial_time_count = 0; >> 91: >> 92: static int64_t clock_tics_per_sec = 100; > > why do we need to do this? It would get promoted in any expression using 64-bit variables src/hotspot/os/posix/os_posix.cpp:1211:31: warning: conversion from 'long int' to 'int' may change value [-Wconversion] 1211 | clock_tics_per_sec = sysconf(_SC_CLK_TCK); | ~~~~~~~^~~~~~~~~~~~~ > src/hotspot/os/posix/os_posix.cpp line 448: > >> 446: void os::Posix::print_uptime_info(outputStream* st) { >> 447: int bootsec = -1; >> 448: int64_t currsec = time(nullptr); > > We should probably cast here even if the compiler doesn't complain, as we don't know what a time_t actually is. seeing if time_t will compile, that would be better. > src/hotspot/os/posix/os_posix.cpp line 803: > >> 801: >> 802: ssize_t os::recv(int fd, char* buf, size_t nBytes, uint flags) { >> 803: RESTARTABLE_RETURN_INT(::recv(fd, buf, nBytes, flags)); > > Note the name of the macro: this is supposed to return int. We need a new macro for RESTARTABLE_RETURN_SSIZE_T I renamed the macro, since the callers all return size_t. > src/hotspot/os/posix/os_posix.cpp line 1335: > >> 1333: static void to_abstime(timespec* abstime, jlong timeout, >> 1334: bool isAbsolute, bool isRealtime) { >> 1335: DEBUG_ONLY(int64_t max_secs = MAX_SECS;) > > Actually I think this should be a time_t. agree. > src/hotspot/os/posix/os_posix.hpp line 48: > >> 46: >> 47: #define RESTARTABLE_RETURN_INT(_cmd) do { \ >> 48: ssize_t _result; \ > > Ah no - please don't do this. Please define a new macro. Given that the three functions that use this return ssize_t, I've renamed the macro. > src/hotspot/os/posix/signals_posix.cpp line 1732: > >> 1730: if (sig > MAX2(SIGSEGV, SIGBUS) && // See 4355769. >> 1731: sig < NSIG) { // Must be legal signal and fit into sigflags[]. >> 1732: PosixSignals::SR_signum = checked_cast(sig); > > checked cast seems unnecessary given the range check I agree but I added it to make other reviewers happy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291254942 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291255326 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291283317 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291258484 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291259017 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291259541 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291289074 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291269177 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291266749 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291270521 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291271264 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291282135 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291275060 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291277737 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291272464 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291278408 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291281519 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291290714 From coleenp at openjdk.org Fri Aug 11 13:31:00 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 13:31:00 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: References: <_dAJdu-ZGg7csi0fNJ0alvmzQSJK3GYaGF1XMaeI6k4=.6af79954-0069-40e1-978e-f8e809afd1e6@github.com> Message-ID: <8dnlIMbOyrm8t36kuNOwwI1ez7PRaAvZYIZgrZry8js=.49d78835-1fad-4ba1-820a-35fd0c3d8f1b@github.com> On Fri, 11 Aug 2023 03:09:46 GMT, David Holmes wrote: >> I started that way and it required more casts. This was the path of least cast-ness. > > For some reason I have an aversion to seeing a `size_t` loop index variable. These changes to `int` are a pleasant surprise. :) I figured if the value fits in an int and it's complaining about casting to an int, then I can just use int. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291271068 From coleenp at openjdk.org Fri Aug 11 13:31:02 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 13:31:02 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: On Fri, 11 Aug 2023 12:22:19 GMT, Coleen Phillimore wrote: >> src/hotspot/os/posix/os_posix.cpp line 92: >> >>> 90: static jlong initial_time_count = 0; >>> 91: >>> 92: static int64_t clock_tics_per_sec = 100; >> >> why do we need to do this? It would get promoted in any expression using 64-bit variables > > src/hotspot/os/posix/os_posix.cpp:1211:31: warning: conversion from 'long int' to 'int' may change value [-Wconversion] > 1211 | clock_tics_per_sec = sysconf(_SC_CLK_TCK); > | ~~~~~~~^~~~~~~~~~~~~ Although I did the opposite for the linux version (ie casted the result of sysconf instead). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291276552 From coleenp at openjdk.org Fri Aug 11 13:31:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 13:31:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <8ZfzGf8NPyxvcjzfSlvOST0eToJzpuMJDVQ28rOqgBQ=.3c4a1bc7-fe99-4ada-8b63-0c1aae550c59@github.com> References: <8ZfzGf8NPyxvcjzfSlvOST0eToJzpuMJDVQ28rOqgBQ=.3c4a1bc7-fe99-4ada-8b63-0c1aae550c59@github.com> Message-ID: On Fri, 11 Aug 2023 02:22:18 GMT, David Holmes wrote: >> The reason I narrowed the types is because none of the callers pass size_t and widening dll_address_to_library_name requires platform dependent changes, and also changing the Decoder::decode() functions (or adding checked_casts<> somewhere along the way) and its subtypes. >> It's not simply to minimize changes, but it is. It's to minimize casting, or checked_casting which is also not pleasant to look at in the code everywhere. This is why I chose passing int as buflen. There's other functions that pass int as buflen. >> Also, there's no world where we pass in a buffer that's greater than 32,000. It's used for error reporting. > > I counted (via grep) 62 occurrences of `int buflen` and 47 occurrences of `size_t` buflen in the hotspot code. So while it does look odd to have two different forms right next to each other, there is at least established precedent for each. > > Unfortunately these `-Wconversion` changes in general seem the antithesis of code-cleanup and consistency as they force changes in limited contexts, resulting in inconsistencies unless we let the changes fan out to extreme degrees. I would have preferred in many cases to handle overflow/underflow via assertions rather than via the primitive type system. This quest for `-Wconversion` compliance is causing a great deal of pain - hats off to @coleenp for enduring that pain to put these PRs together. Thank you for this comment. This work has become soul crushing. I was optimistic at one point that we could cleanly work through these warnings by making int type consistent, and in many cases, that is possible. And there have been some local improvements to the code that have come out of this (like primitive_compare). But this work is hampered by 1. wanting to improve the code further than fixing the warnings, and 2. disagreements and questions about how to fix avoiding C style casts, and whether the fixes are needed, for every fix. I'm now no longer optimistic that we'll be able to finish this. We'll see how @dean-long does with the compiler warnings. There are a lot more of them. There are also a lot of warnings in the gc code. Also, that doesn't include test code or libraries code, like java.deskop. We need to find a way to enable/disable these on a per component basis or even a per file basis, which requires build changes I think. When I started this around June 2, there were 424 files with 73396 warnings in hotspot (due to multiple inclusion). After this patch, there are 259 files with 5717 warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291305563 From dcubed at openjdk.org Fri Aug 11 14:13:58 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 11 Aug 2023 14:13:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <8ZfzGf8NPyxvcjzfSlvOST0eToJzpuMJDVQ28rOqgBQ=.3c4a1bc7-fe99-4ada-8b63-0c1aae550c59@github.com> Message-ID: On Fri, 11 Aug 2023 12:54:40 GMT, Coleen Phillimore wrote: >> I counted (via grep) 62 occurrences of `int buflen` and 47 occurrences of `size_t` buflen in the hotspot code. So while it does look odd to have two different forms right next to each other, there is at least established precedent for each. >> >> Unfortunately these `-Wconversion` changes in general seem the antithesis of code-cleanup and consistency as they force changes in limited contexts, resulting in inconsistencies unless we let the changes fan out to extreme degrees. I would have preferred in many cases to handle overflow/underflow via assertions rather than via the primitive type system. This quest for `-Wconversion` compliance is causing a great deal of pain - hats off to @coleenp for enduring that pain to put these PRs together. > > Thank you for this comment. This work has become soul crushing. I was optimistic at one point that we could cleanly work through these warnings by making int type consistent, and in many cases, that is possible. And there have been some local improvements to the code that have come out of this (like primitive_compare). But this work is hampered by 1. wanting to improve the code further than fixing the warnings, and 2. disagreements and questions about how to fix avoiding C style casts, and whether the fixes are needed, for every fix. > > I'm now no longer optimistic that we'll be able to finish this. We'll see how @dean-long does with the compiler warnings. There are a lot more of them. There are also a lot of warnings in the gc code. Also, that doesn't include test code or libraries code, like java.deskop. We need to find a way to enable/disable these on a per component basis or even a per file basis, which requires build changes I think. > > When I started this around June 2, there were 424 files with 73396 warnings in hotspot (due to multiple inclusion). After this patch, there are 259 files with 5717 warnings. Those statistics are absolutely impressive! You have done outstanding work on a task that probably also feels unending and your efforts are very much appreciated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291379386 From fbredberg at openjdk.org Fri Aug 11 14:15:30 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 11 Aug 2023 14:15:30 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v2] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 03:15:09 GMT, Hao Sun wrote: >> Fredrik Bredberg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Updated linux-ppc64le after review >> - Updated after review > > src/hotspot/share/runtime/frame.cpp line 1624: > >> 1622: st->print_cr(" %s %s %s", spacer, spacer, fv.description); >> 1623: } else { >> 1624: if (on_heap > > Along with the removal of this check, `on_heap` is not used in this function. > Should we remove this parameter? Thank you for pointing that out @shqking. Yes I think we should remove the parameter. I'll fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14545#discussion_r1291377072 From fbredberg at openjdk.org Fri Aug 11 14:15:34 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 11 Aug 2023 14:15:34 GMT Subject: RFR: 8313419: Template interpreter produces no safepoint check for return bytecodes In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 13:22:19 GMT, Fredrik Bredberg wrote: > The template interpreter produces a safepoint check for return bytecodes (TemplateTable::_return(TosState state)) on x86, ppc64le and s390, but not on aarch64, arm32, and riscv64. > > This PR adds the missing safepoint check to aarch64, arm32, and riscv64. > > Tested tier1-tier7 on aarch64. Both arm32, and riscv64 was sanity tested using Qemu. I've done basic testing on riscv64 and arm32 using Qemu, but would appreciate if @RealFYang and @bulasevich could take it for a real test drive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15248#issuecomment-1674827460 From fbredberg at openjdk.org Fri Aug 11 14:15:33 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 11 Aug 2023 14:15:33 GMT Subject: RFR: 8313419: Template interpreter produces no safepoint check for return bytecodes Message-ID: The template interpreter produces a safepoint check for return bytecodes (TemplateTable::_return(TosState state)) on x86, ppc64le and s390, but not on aarch64, arm32, and riscv64. This PR adds the missing safepoint check to aarch64, arm32, and riscv64. Tested tier1-tier7 on aarch64. Both arm32, and riscv64 was sanity tested using Qemu. ------------- Commit messages: - 8313419: Template interpreter produces no safepoint check for return bytecodes Changes: https://git.openjdk.org/jdk/pull/15248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313419 Stats: 35 lines in 3 files changed: 35 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15248.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15248/head:pull/15248 PR: https://git.openjdk.org/jdk/pull/15248 From shade at openjdk.org Fri Aug 11 14:26:30 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 11 Aug 2023 14:26:30 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v4] In-Reply-To: References: <4CgdQZOOUU4pKMI7zf9jSy685HVylAzsYKkagQhRxdY=.b03a46db-f5b0-4589-b122-155fd5039a98@github.com> Message-ID: On Thu, 10 Aug 2023 11:49:05 GMT, Coleen Phillimore wrote: >> Oli Gillespie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Undo nullptr 'improvement' >> >> It's implemented wrong, and not sure it's worth doing anyway. >> - Remove .equals is_dead arg >> >> Better to use the new is_dead function. > > The comment seems fine. Bit verbose but that's ok. Don't move the refcount out of equals into the lookup function. When we implemented this, this was where we thought this needed to be for safety, and this code has not changed to change that. @coleenp, @dholmes-ora -- want to run it via your testing systems before we integrate, or? This passes tests on our side. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1674847825 From coleenp at openjdk.org Fri Aug 11 14:56:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 14:56:58 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v6] In-Reply-To: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> References: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> Message-ID: On Thu, 10 Aug 2023 13:41:06 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Tweak comment I could run tests over the weekend if you want. We have some closed tests that can be displeased when Symbol refcounts unexpectedly go to zero. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1674893346 From shade at openjdk.org Fri Aug 11 14:56:59 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 11 Aug 2023 14:56:59 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v6] In-Reply-To: References: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> Message-ID: On Fri, 11 Aug 2023 14:33:27 GMT, Coleen Phillimore wrote: > I could run tests over the weekend if you want. We have some closed tests that can be displeased when Symbol refcounts unexpectedly go to zero. Yes, I think that would be helpful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1674895973 From stuefe at openjdk.org Fri Aug 11 16:11:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 11 Aug 2023 16:11:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: On Fri, 11 Aug 2023 12:03:01 GMT, Coleen Phillimore wrote: >> src/hotspot/os/linux/os_linux.cpp line 426: >> >>> 424: >>> 425: void os::Linux::initialize_system_info() { >>> 426: set_processor_count(checked_cast(sysconf(_SC_NPROCESSORS_CONF))); >> >> checked_cast seems excessive here and on other sysconf calls. > > One of you wants checked_cast<> everywhere and another of you doesn't. Given that we don't know from local code inspection that the result fits in an int, I chose checked_cast<> for these calls. What are the costs of checked_cast? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291531511 From stuefe at openjdk.org Fri Aug 11 16:13:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 11 Aug 2023 16:13:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: <7yarX3P667rC9TOG1GoZRuQlfuj_93mHPFlXyymvaOw=.d7b33422-c080-4713-8e75-a15fc305a715@github.com> References: <7yarX3P667rC9TOG1GoZRuQlfuj_93mHPFlXyymvaOw=.d7b33422-c080-4713-8e75-a15fc305a715@github.com> Message-ID: On Fri, 11 Aug 2023 13:19:28 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > David's suggested changes. src/hotspot/os/posix/signals_posix.cpp line 1432: > 1430: // are not chained (e.g. if chaining is off), print that one too. > 1431: void PosixSignals::print_signal_handler(outputStream* st, int sig, > 1432: char* buf, int buflen) { This feels weird and wrong to me. Why change what are clearly memory sizes from size_t to a signed int? These are fed from both literals (OBUFLEN) and from sizeof(buf). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291537347 From coleenp at openjdk.org Fri Aug 11 16:40:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 16:40:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: <75kdLIEw_BPJO866cnPRd6yNWBTZt6NSN-VgeIyiSwQ=.c87caece-5717-4560-bf1e-527cc8be51f9@github.com> On Fri, 11 Aug 2023 15:52:42 GMT, Thomas Stuefe wrote: >> One of you wants checked_cast<> everywhere and another of you doesn't. Given that we don't know from local code inspection that the result fits in an int, I chose checked_cast<> for these calls. > > What are the costs of checked_cast? checked_cast instantiates a template or two. I haven't measured code bloat. It carries risk of asserting for odd inputs that used to be truncated. In this case, it seems like a good place to have the assert. In obvious places, it seems like noise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291569289 From coleenp at openjdk.org Fri Aug 11 16:41:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 16:41:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: References: <7yarX3P667rC9TOG1GoZRuQlfuj_93mHPFlXyymvaOw=.d7b33422-c080-4713-8e75-a15fc305a715@github.com> Message-ID: On Fri, 11 Aug 2023 15:57:33 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> David's suggested changes. > > src/hotspot/os/posix/signals_posix.cpp line 1432: > >> 1430: // are not chained (e.g. if chaining is off), print that one too. >> 1431: void PosixSignals::print_signal_handler(outputStream* st, int sig, >> 1432: char* buf, int buflen) { > > This feels weird and wrong to me. Why change what are clearly memory sizes from size_t to a signed int? These are fed from both literals (OBUFLEN) and from sizeof(buf). Yes, both literals are easily represented as an int, since the buffer we give to error reporting is never 30k long. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291558943 From jvernee at openjdk.org Fri Aug 11 16:53:58 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 11 Aug 2023 16:53:58 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v3] In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 23:31:57 GMT, Chen Liang wrote: > Just curious, what's the rationale for finalizing the API when there are significant changes from the last preview? A preview API is finalized when it is ready. The preview process, as outlined by [JEP 12](https://bugs.openjdk.org/browse/JDK-8195734), does not place a mandate on the amount of changes that a JEP that finalizes a preview API should or should not contain. It only requires that the changes since the last preview iteration are noted (which we have done). Though, the amount of changes can be used to inform the decision to finalize. We feel that the FFM API is ready for finalization, and does not require another round of preview. In this case in particular: previous iterations contained significant changes to the API, including re-shuffling of some of the core APIs. (See e.g. https://github.com/openjdk/jdk/pull/13079#issuecomment-1476648707) In contrast this JEP contains mostly superficial changes to the API, that are not likely to impact how a client would write a program using the FFM API. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1675057357 From uschindler at openjdk.org Fri Aug 11 17:23:28 2023 From: uschindler at openjdk.org (Uwe Schindler) Date: Fri, 11 Aug 2023 17:23:28 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v4] In-Reply-To: <2oLXen9Xs8SSrIgV9q_2KV0CA0ioUIdUZDqtsSkQ-BI=.b30a8a5b-1f03-480e-8d53-9f107ab35d64@github.com> References: <2oLXen9Xs8SSrIgV9q_2KV0CA0ioUIdUZDqtsSkQ-BI=.b30a8a5b-1f03-480e-8d53-9f107ab35d64@github.com> Message-ID: On Fri, 11 Aug 2023 12:37:59 GMT, Jorn Vernee wrote: >> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: >> >> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. >> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. >> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. >> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. >> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. >> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) >> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. >> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. >> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO... > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > remove spurious imports > > Just curious, what's the rationale for finalizing the API when there are significant changes from the last preview? > > A preview API is finalized when it is ready. The preview process, as outlined by [JEP 12](https://bugs.openjdk.org/browse/JDK-8195734), does not place a mandate on the amount of changes that a JEP that finalizes a preview API should or should not contain. It only requires that the changes since the last preview iteration are noted (which we have done). Though, the amount of changes can be used to inform the decision to finalize. We feel that the FFM API is ready for finalization, and does not require another round of preview. > > In this case in particular: previous iterations contained significant changes to the API, including re-shuffling of some of the core APIs. (See e.g. [#13079 (comment)](https://github.com/openjdk/jdk/pull/13079#issuecomment-1476648707)) In contrast this JEP contains mostly superficial changes to the API, that are not likely to impact how a client would write a program using the FFM API. In addition if somebody wrote code against the preview API, heshe needs to update it anyways because the class files are marked by preview flag. So all is fine. We just make API ready to use for everybody and therefor all early adopters need to adapt. t won't affect anybox else. To me it would be strange if code goes out of preview without changes, because if there are no changes why was it in preview then in the last JDK feature version? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1675101701 From aph at openjdk.org Fri Aug 11 17:23:28 2023 From: aph at openjdk.org (Andrew Haley) Date: Fri, 11 Aug 2023 17:23:28 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 08:44:13 GMT, Andrew Haley wrote: > I think you need to correct `frame::describe` to make it print the relativized SP in an easy-to-understand form. Ping. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1675100442 From stuefe at openjdk.org Fri Aug 11 18:07:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 11 Aug 2023 18:07:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: References: <7yarX3P667rC9TOG1GoZRuQlfuj_93mHPFlXyymvaOw=.d7b33422-c080-4713-8e75-a15fc305a715@github.com> Message-ID: On Fri, 11 Aug 2023 16:22:20 GMT, Coleen Phillimore wrote: >> src/hotspot/os/posix/signals_posix.cpp line 1432: >> >>> 1430: // are not chained (e.g. if chaining is off), print that one too. >>> 1431: void PosixSignals::print_signal_handler(outputStream* st, int sig, >>> 1432: char* buf, int buflen) { >> >> This feels weird and wrong to me. Why change what are clearly memory sizes from size_t to a signed int? These are fed from both literals (OBUFLEN) and from sizeof(buf). > > Yes, both literals are easily represented as an int, since the buffer we give to error reporting is never 30k long. Sorry, I don't like this, nor do I understand what this solves. `size_t` is, by a deeply ingrained convention, used for memory sizes. It signals that intent clearly to the casual reader of the function declaration. `int` as size for an output buffer is away from conventions and just reads odd. Now this change perforates through all callers up to vmError and other call sites and just makes them all slightly worse, and it is pretty invasive (wrt merging changes to downports). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291630801 From stuefe at openjdk.org Fri Aug 11 18:07:29 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 11 Aug 2023 18:07:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: References: <7yarX3P667rC9TOG1GoZRuQlfuj_93mHPFlXyymvaOw=.d7b33422-c080-4713-8e75-a15fc305a715@github.com> Message-ID: On Fri, 11 Aug 2023 17:45:20 GMT, Thomas Stuefe wrote: >> Yes, both literals are easily represented as an int, since the buffer we give to error reporting is never 30k long. > > Sorry, I don't like this, nor do I understand what this solves. > > `size_t` is, by a deeply ingrained convention, used for memory sizes. It signals that intent clearly to the casual reader of the function declaration. `int` as size for an output buffer is away from conventions and just reads odd. Now this change perforates through all callers up to vmError and other call sites and just makes them all slightly worse, and it is pretty invasive (wrt merging changes to downports). I just read the other comment as well. Hats off to your pain tolerance, Coleen, I don't aim to belittle your work. I'm just really unhappy with these size_t->int changes. Is there really no better way to solve this? This seems to be an example where solving warnings actually makes the code base worse. Coding against conventions makes the code base brittle (because experienced developers will always use size_t and fall over this). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291634841 From rkennke at openjdk.org Fri Aug 11 18:40:36 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 11 Aug 2023 18:40:36 GMT Subject: RFR: 8305898: Alternative self-forwarding mechanism [v19] In-Reply-To: References: Message-ID: <9KKpqN3GBvUxwDZPz68AmuWoTTGglMX9fK7iMZ74fPA=.03ac87b0-b3e2-4b88-9509-8940c4cd21a7@github.com> > Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers, when compaction fails, to indicate that the object has been looked at, but failed compaction into to-space. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the bit #3 (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored. Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge branch 'JDK-8305896' into JDK-8305898 - Merge branch 'JDK-8305896' into JDK-8305898 - Merge branch 'JDK-8305896' into JDK-8305898 - Update comment about mark-word layout - Merge branch 'JDK-8305896' into JDK-8305898 - Fix tests on 32bit builds - Merge branch 'JDK-8305896' into JDK-8305898 - Merge branch 'JDK-8305896' into JDK-8305898 - wqRevert "Rename self-forwarded -> forward-failed" This reverts commit 4d9713ca239da8e294c63887426bfb97240d3130. - Merge branch 'JDK-8305896' into JDK-8305898 - ... and 21 more: https://git.openjdk.org/jdk/compare/d2b41e25...cd5f2374 ------------- Changes: https://git.openjdk.org/jdk/pull/13779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13779&range=18 Stats: 101 lines in 8 files changed: 85 ins; 2 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/13779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13779/head:pull/13779 PR: https://git.openjdk.org/jdk/pull/13779 From coleenp at openjdk.org Fri Aug 11 19:12:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 19:12:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v4] In-Reply-To: References: Message-ID: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Put back size_t parameter for print_signal_handlers and add a checked_cast<> future could fix the dll_address_to_x functions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/6777a2a2..ab81b2ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=02-03 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From coleenp at openjdk.org Fri Aug 11 19:38:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 19:38:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: References: <7yarX3P667rC9TOG1GoZRuQlfuj_93mHPFlXyymvaOw=.d7b33422-c080-4713-8e75-a15fc305a715@github.com> Message-ID: On Fri, 11 Aug 2023 17:50:33 GMT, Thomas Stuefe wrote: >> Sorry, I don't like this, nor do I understand what this solves. >> >> `size_t` is, by a deeply ingrained convention, used for memory sizes. It signals that intent clearly to the casual reader of the function declaration. `int` as size for an output buffer is away from conventions and just reads odd. Now this change perforates through all callers up to vmError and other call sites and just makes them all slightly worse, and it is pretty invasive (wrt merging changes to downports). > > I just read the other comment as well. Hats off to your pain tolerance, Coleen, I don't aim to belittle your work. I'm just really unhappy with these size_t->int changes. > > Is there really no better way to solve this? This seems to be an example where solving warnings actually makes the code base worse. Coding against conventions makes the code base brittle (because experienced developers will always use size_t and fall over this). Ok, I put the size_t parameter back and added the checked cast to the call to print_function_and_library_name. Propagating size_t lower is going to require another RFE. Too much fan-out to be part of this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291708245 From dlong at openjdk.org Fri Aug 11 19:53:58 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 11 Aug 2023 19:53:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v4] In-Reply-To: References: <9adGJpUsZXsKoTDvYpcG_SdNKdVEwAXxkocxhuNdjlE=.ce13e296-42cc-48d8-bc05-81102caf3838@github.com> <7PnQf12I-HCecZHMoCj7g0LobvUXmJPpiG5n81ga5fI=.b06bbfb8-44b7-435a-a364-5e06879e3876@github.com> Message-ID: On Fri, 11 Aug 2023 12:00:22 GMT, Coleen Phillimore wrote: >> Yes, exactly, and we have hit similar bugs before. But the bug seems harmless here. > > So, comment? What should it say? I think it makes sense to have something like checked_cast here, maybe call it double_to_int(), that checks against INT_MIN and INT_MAX. Also, using double instead of float removes the round-up problem as long as the input is <= 32 bits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291723348 From coleenp at openjdk.org Fri Aug 11 19:53:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 19:53:58 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v6] In-Reply-To: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> References: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> Message-ID: On Thu, 10 Aug 2023 13:41:06 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Tweak comment It was helpful. This test failed: make test TEST=runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java java.lang.RuntimeException: '17 3: jdk/test/lib/apps ' missing from stdout/stderr It may be that we decremented a refcount in this symbol during cleanup. Edit: yes, I think that's the case, the output has: 17 2: jdk/test/lib/apps ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1675271777 From dlong at openjdk.org Fri Aug 11 20:08:58 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 11 Aug 2023 20:08:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <75kdLIEw_BPJO866cnPRd6yNWBTZt6NSN-VgeIyiSwQ=.c87caece-5717-4560-bf1e-527cc8be51f9@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <75kdLIEw_BPJO866cnPRd6yNWBTZt6NSN-VgeIyiSwQ=.c87caece-5717-4560-bf1e-527cc8be51f9@github.com> Message-ID: On Fri, 11 Aug 2023 16:33:41 GMT, Coleen Phillimore wrote: >> What are the costs of checked_cast? > > checked_cast instantiates a template or two. I haven't measured code bloat. It carries risk of asserting for odd inputs that used to be truncated. In this case, it seems like a good place to have the assert. In obvious places, it seems like noise. There are a few ways to fix code like this without changing the call site: 1. overflow func() to take the alternative type, and do the checked_cast there 2. change func() to a template function 3. Change func() to take a user-defined type whose constructor accepts both types I've experimented with all 3 in the compiler code, but I don't know what others think of tricks like these. I think 2) is already used it HotSpot. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291730408 From coleenp at openjdk.org Fri Aug 11 20:22:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 20:22:59 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v4] In-Reply-To: References: <9adGJpUsZXsKoTDvYpcG_SdNKdVEwAXxkocxhuNdjlE=.ce13e296-42cc-48d8-bc05-81102caf3838@github.com> <7PnQf12I-HCecZHMoCj7g0LobvUXmJPpiG5n81ga5fI=.b06bbfb8-44b7-435a-a364-5e06879e3876@github.com> Message-ID: On Fri, 11 Aug 2023 19:50:20 GMT, Dean Long wrote: >> So, comment? What should it say? > > I think it makes sense to have something like checked_cast here, maybe call it double_to_int(), that checks against INT_MIN and INT_MAX. Also, using double instead of float removes the round-up problem as long as the input is <= 32 bits. I'm going to revert this change to fix at a later time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291743252 From coleenp at openjdk.org Fri Aug 11 20:40:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Aug 2023 20:40:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: Message-ID: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Put back size_t parameter for print_signal_handlers and add a checked_cast<> future could fix the dll_address_to_x functions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/ab81b2ed..e29c997d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From dlong at openjdk.org Fri Aug 11 21:07:58 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 11 Aug 2023 21:07:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: Message-ID: <-FbUxcZUISaSr_6Xk6ZDShTi5hNAjiXgdKhEKLT2LPQ=.c5614314-f150-429f-b033-a36262c59d54@github.com> On Fri, 11 Aug 2023 20:40:28 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Put back size_t parameter for print_signal_handlers and add a checked_cast<> future could fix the dll_address_to_x functions. src/hotspot/os/linux/os_linux.cpp line 404: > 402: // thread id is used to access /proc. > 403: pid_t os::Linux::gettid() { > 404: int64_t rslt = syscall(SYS_gettid); Suggestion: long rslt = syscall(SYS_gettid); src/hotspot/os/posix/signals_posix.hpp line 2: > 1: /* > 2: * Copyright (c) 2020, 2023, Oracle and/or its affiliates. All rights reserved. This file has no changes currently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291769022 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291771491 From dlong at openjdk.org Fri Aug 11 21:08:01 2023 From: dlong at openjdk.org (Dean Long) Date: Fri, 11 Aug 2023 21:08:01 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: <55ec_4ajYWDRJP9QCGqJzZhWtT-JWDmm69o4aSNDslw=.d1616817-af8e-4a15-8085-c455f22afb75@github.com> On Fri, 11 Aug 2023 12:39:21 GMT, Coleen Phillimore wrote: >> src/hotspot/os/posix/signals_posix.cpp line 1732: >> >>> 1730: if (sig > MAX2(SIGSEGV, SIGBUS) && // See 4355769. >>> 1731: sig < NSIG) { // Must be legal signal and fit into sigflags[]. >>> 1732: PosixSignals::SR_signum = checked_cast(sig); >> >> checked cast seems unnecessary given the range check > > I agree but I added it to make other reviewers happy. An alternative would be to use parse_integer() instead of strtol to get the value as an int. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1291771225 From stuefe at openjdk.org Sat Aug 12 06:15:59 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 12 Aug 2023 06:15:59 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v3] In-Reply-To: References: <7yarX3P667rC9TOG1GoZRuQlfuj_93mHPFlXyymvaOw=.d7b33422-c080-4713-8e75-a15fc305a715@github.com> Message-ID: On Fri, 11 Aug 2023 19:27:40 GMT, Coleen Phillimore wrote: >> I just read the other comment as well. Hats off to your pain tolerance, Coleen, I don't aim to belittle your work. I'm just really unhappy with these size_t->int changes. >> >> Is there really no better way to solve this? This seems to be an example where solving warnings actually makes the code base worse. Coding against conventions makes the code base brittle (because experienced developers will always use size_t and fall over this). > > Ok, I put the size_t parameter back and added the checked cast to the call to print_function_and_library_name. Propagating size_t lower is going to require another RFE. Too much fan-out to be part of this. Thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292095769 From stuefe at openjdk.org Sat Aug 12 06:58:58 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 12 Aug 2023 06:58:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: <3iwWmu4wOB-sRwfThnExs3UsQox3H67rKNaLDk6UJBg=.3421ba15-8ac3-4152-8f5b-d6379c6502c8@github.com> On Fri, 11 Aug 2023 11:58:28 GMT, Coleen Phillimore wrote: >> src/hotspot/os/aix/attachListener_aix.cpp line 296: >> >>> 294: // hang in the clean-up when shutting down. >>> 295: n = read(s, buf+off, left); >>> 296: assert(n <= checked_cast(left), "buffer was too small, impossible!"); >> >> why ssize_t here? > > This gets a sign comparison warning without the cast, which thankfully we do enable. I'm curious, who is warning here? Is this a static code analysis? Since I don't think Oracle builds AIX, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292117246 From stuefe at openjdk.org Sat Aug 12 06:57:58 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 12 Aug 2023 06:57:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 20:40:28 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Put back size_t parameter for print_signal_handlers and add a checked_cast<> future could fix the dll_address_to_x functions. Hi Coleen, I had a read through these changes. Remarks inline. This is an immense work, respect. When and where I had been grumbling, it was because whatever we change must be maintainable in the future. So, if we now do X in various places, X must not be arbitrary but be a consistent rule we can follow in the future, lest all this work bitrots quickly. One proposal, possibly for a future RFE: could we maybe make checked_cast a smaller name? One gripe with C++ cast expressions I have is that they look ugly and give me RSI. Since this is our own name, and it is really omnipresent now, could we not shorten it (similar to macro names like "p2i")? For example `cc`. As in size_t len foo_takes_int(cc(len)) or even better as a macro foo_takes_int(cc(int, len)) Cheers, Thomas src/hotspot/os/linux/os_linux.cpp line 3151: > 3149: // are more reasonable) we'll just hardcode the number they use > 3150: // in the library. > 3151: const int BitsPerCLong = (int)sizeof(long) * CHAR_BIT; suggestion here and above: constexpr? src/hotspot/os/linux/os_linux.cpp line 3352: > 3350: for (int index = 0; index < loops && !found_range; index ++) { > 3351: assert(pages > 0, "Nothing to do"); > 3352: size_t pages_to_query = (pages >= stripe) ? stripe : pages; Pre-existing: Could you instead make `pages` and `pages_to_query` and below `vecIdx` an uintx? Should be the same and give you no new errors, but size_t as "number of things" is not right. ------------- PR Review: https://git.openjdk.org/jdk/pull/15229#pullrequestreview-1574842059 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292114968 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292115407 From stuefe at openjdk.org Sat Aug 12 06:59:58 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 12 Aug 2023 06:59:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: <-FbUxcZUISaSr_6Xk6ZDShTi5hNAjiXgdKhEKLT2LPQ=.c5614314-f150-429f-b033-a36262c59d54@github.com> References: <-FbUxcZUISaSr_6Xk6ZDShTi5hNAjiXgdKhEKLT2LPQ=.c5614314-f150-429f-b033-a36262c59d54@github.com> Message-ID: On Fri, 11 Aug 2023 20:58:19 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Put back size_t parameter for print_signal_handlers and add a checked_cast<> future could fix the dll_address_to_x functions. > > src/hotspot/os/linux/os_linux.cpp line 404: > >> 402: // thread id is used to access /proc. >> 403: pid_t os::Linux::gettid() { >> 404: int64_t rslt = syscall(SYS_gettid); > > Suggestion: > > long rslt = syscall(SYS_gettid); I am in favour of `long` too, since that is what syscall returns. int64_t does not seem to have any obvious relation to the call. And there is no reason to need 64-bit on 32-bit Linux. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292102288 From stuefe at openjdk.org Sat Aug 12 06:59:58 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 12 Aug 2023 06:59:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <75kdLIEw_BPJO866cnPRd6yNWBTZt6NSN-VgeIyiSwQ=.c87caece-5717-4560-bf1e-527cc8be51f9@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <75kdLIEw_BPJO866cnPRd6yNWBTZt6NSN-VgeIyiSwQ=.c87caece-5717-4560-bf1e-527cc8be51f9@github.com> Message-ID: On Fri, 11 Aug 2023 16:33:41 GMT, Coleen Phillimore wrote: >> What are the costs of checked_cast? > > checked_cast instantiates a template or two. I haven't measured code bloat. It carries risk of asserting for odd inputs that used to be truncated. In this case, it seems like a good place to have the assert. In obvious places, it seems like noise. @coleenp: The only case where sysconf could be not a small positive integer is when it returns an error, -1, and checked_cast will not catch that since it still fits an int. Up to you, but I'd either leave this unchecked, or convert the parameter for set_processor_count to unsigned. @dean-long: > change func() to a template function I hope we don't do that, that sounds terrible. I still have to find a modern IDE that can work well with all the template code we have. The more templates we use, the worse features like call graph display work in IDEs like CDT or CLion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292107207 From stuefe at openjdk.org Sat Aug 12 07:00:00 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 12 Aug 2023 07:00:00 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: <8dnlIMbOyrm8t36kuNOwwI1ez7PRaAvZYIZgrZry8js=.49d78835-1fad-4ba1-820a-35fd0c3d8f1b@github.com> References: <_dAJdu-ZGg7csi0fNJ0alvmzQSJK3GYaGF1XMaeI6k4=.6af79954-0069-40e1-978e-f8e809afd1e6@github.com> <8dnlIMbOyrm8t36kuNOwwI1ez7PRaAvZYIZgrZry8js=.49d78835-1fad-4ba1-820a-35fd0c3d8f1b@github.com> Message-ID: On Fri, 11 Aug 2023 12:17:56 GMT, Coleen Phillimore wrote: >> For some reason I have an aversion to seeing a `size_t` loop index variable. These changes to `int` are a pleasant surprise. :) > > I figured if the value fits in an int and it's complaining about casting to an int, then I can just use int. I like these changes too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292114909 From coleenp at openjdk.org Sat Aug 12 13:41:59 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 12 Aug 2023 13:41:59 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <3iwWmu4wOB-sRwfThnExs3UsQox3H67rKNaLDk6UJBg=.3421ba15-8ac3-4152-8f5b-d6379c6502c8@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <3iwWmu4wOB-sRwfThnExs3UsQox3H67rKNaLDk6UJBg=.3421ba15-8ac3-4152-8f5b-d6379c6502c8@github.com> Message-ID: On Sat, 12 Aug 2023 06:42:53 GMT, Thomas Stuefe wrote: >> This gets a sign comparison warning without the cast, which thankfully we do enable. > > I'm curious, who is warning here? Is this a static code analysis? Since I don't think Oracle builds AIX, right? The AIX code is a copy of the linux code. I got a sign conversion warning on the linux code. src/hotspot/os/linux/attachListener_linux.cpp:275:14: warning: comparison of integer expressions of different signedness: 'ssize_t' {aka 'long int'} and 'size_t' {aka 'long unsigned int'} [-Wsign-compare] 275 | assert(n <= left, "buffer was too small, impossible!"); | ~~^~~~~~~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292279308 From coleenp at openjdk.org Sat Aug 12 13:42:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 12 Aug 2023 13:42:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: Message-ID: On Sat, 12 Aug 2023 06:35:19 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Put back size_t parameter for print_signal_handlers and add a checked_cast<> future could fix the dll_address_to_x functions. > > src/hotspot/os/linux/os_linux.cpp line 3151: > >> 3149: // are more reasonable) we'll just hardcode the number they use >> 3150: // in the library. >> 3151: const int BitsPerCLong = (int)sizeof(long) * CHAR_BIT; > > suggestion here and above: constexpr? ? They're already const . Isn't that the same? > src/hotspot/os/linux/os_linux.cpp line 3352: > >> 3350: for (int index = 0; index < loops && !found_range; index ++) { >> 3351: assert(pages > 0, "Nothing to do"); >> 3352: size_t pages_to_query = (pages >= stripe) ? stripe : pages; > > Pre-existing: Could you instead make `pages` and `pages_to_query` and below `vecIdx` an uintx? Should be the same and give you no new errors, but size_t as "number of things" is not right. This seems to not complain. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292284440 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292301082 From coleenp at openjdk.org Sat Aug 12 13:42:01 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 12 Aug 2023 13:42:01 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <75kdLIEw_BPJO866cnPRd6yNWBTZt6NSN-VgeIyiSwQ=.c87caece-5717-4560-bf1e-527cc8be51f9@github.com> Message-ID: On Sat, 12 Aug 2023 06:15:09 GMT, Thomas Stuefe wrote: >> checked_cast instantiates a template or two. I haven't measured code bloat. It carries risk of asserting for odd inputs that used to be truncated. In this case, it seems like a good place to have the assert. In obvious places, it seems like noise. > > @coleenp: The only case where sysconf could be not a small positive integer is when it returns an error, -1, and checked_cast will not catch that since it still fits an int. > > Up to you, but I'd either leave this unchecked, or convert the parameter for set_processor_count to unsigned. > > @dean-long: >> change func() to a template function > > I hope we don't do that, that sounds terrible. I still have to find a modern IDE that can work well with all the template code we have. The more templates we use, the worse features like call graph display work in IDEs like CDT or CLion. I'm also not in favor of additional templates to hide our use of wrongly sized integers. There's already enough time-consuming decoding in places and terrible error messages. I'd rather the integers be the right size. I don't like tricks. I'm not opposed at all to direct C style casts where we know they fit. Seems simplest. I'll change this one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292284262 From coleenp at openjdk.org Sat Aug 12 13:42:00 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 12 Aug 2023 13:42:00 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: <-FbUxcZUISaSr_6Xk6ZDShTi5hNAjiXgdKhEKLT2LPQ=.c5614314-f150-429f-b033-a36262c59d54@github.com> Message-ID: On Sat, 12 Aug 2023 06:05:48 GMT, Thomas Stuefe wrote: >> src/hotspot/os/linux/os_linux.cpp line 404: >> >>> 402: // thread id is used to access /proc. >>> 403: pid_t os::Linux::gettid() { >>> 404: int64_t rslt = syscall(SYS_gettid); >> >> Suggestion: >> >> long rslt = syscall(SYS_gettid); > > I am in favour of `long` too, since that is what syscall returns. int64_t does not seem to have any obvious relation to the call. And there is no reason to need 64-bit on 32-bit Linux. We try to avoid using long in the hotspot source code, at least in the shared code since long is a different size on windows. The preference is to use int64_t. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292279483 From coleenp at openjdk.org Sat Aug 12 13:42:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 12 Aug 2023 13:42:31 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <55ec_4ajYWDRJP9QCGqJzZhWtT-JWDmm69o4aSNDslw=.d1616817-af8e-4a15-8085-c455f22afb75@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <55ec_4ajYWDRJP9QCGqJzZhWtT-JWDmm69o4aSNDslw=.d1616817-af8e-4a15-8085-c455f22afb75@github.com> Message-ID: On Fri, 11 Aug 2023 21:01:52 GMT, Dean Long wrote: >> I agree but I added it to make other reviewers happy. > > An alternative would be to use parse_integer() instead of strtol to get the value as an int. parse_integer is nicer so I did that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292301035 From coleenp at openjdk.org Sat Aug 12 13:42:32 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 12 Aug 2023 13:42:32 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: Message-ID: <1FE8DIG2CAGdwpxsy9lv8MGtPUYqghXZbm1-bOYbvNs=.c3120d71-bd43-4c92-be2d-72e3ac19c3f4@github.com> On Fri, 11 Aug 2023 00:40:48 GMT, Coleen Phillimore wrote: >> src/hotspot/share/utilities/decoder_elf.cpp line 70: >> >>> 68: filepath[JVM_MAXPATHLEN - 1] = '\0'; >>> 69: int offset_in_library = -1; >>> 70: if (!os::dll_address_to_library_name(pc, filepath, (int)sizeof(filepath), &offset_in_library)) { >> >> How about fixing dll_address_to_library_name to use size_t like all the rest of the os:: functions? > > It's painful. See above. I didn't need that cast. reverting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292300951 From coleenp at openjdk.org Sat Aug 12 14:03:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 12 Aug 2023 14:03:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v6] In-Reply-To: References: Message-ID: <6WkhIRusY9IEP4X4_os2NqHwhC87fBLtQE8FFeyP7ZQ=.86572ecf-5632-4f33-880d-bab93790ea93@github.com> > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - Thomas Stuefe and Dean's suggestions, turn Wconversion back off. - revert copyright change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/e29c997d..c4c4584d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=04-05 Stats: 12 lines in 4 files changed: 2 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From coleenp at openjdk.org Sat Aug 12 14:06:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 12 Aug 2023 14:06:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 20:40:28 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Put back size_t parameter for print_signal_handlers and add a checked_cast<> future could fix the dll_address_to_x functions. Thanks for reviewing, Thomas. I like your idea of renaming checked_cast to cc or something shorter. I'd love for the error message to be improved since I seem to be now hitting when testing a lot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15229#issuecomment-1675919737 From stuefe at openjdk.org Sat Aug 12 17:31:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 12 Aug 2023 17:31:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: Message-ID: On Sat, 12 Aug 2023 13:02:40 GMT, Coleen Phillimore wrote: >> src/hotspot/os/linux/os_linux.cpp line 3151: >> >>> 3149: // are more reasonable) we'll just hardcode the number they use >>> 3150: // in the library. >>> 3151: const int BitsPerCLong = (int)sizeof(long) * CHAR_BIT; >> >> suggestion here and above: constexpr? > > ? They're already const . Isn't that the same? They are most const :-) constexpr is for things that are compile-time const. The advantage is, apart from documentation, that the compiler checks your assumption about compile-time-constness. In this case, it probably does not matter much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292393502 From aph at openjdk.org Mon Aug 14 02:23:58 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 14 Aug 2023 02:23:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: Message-ID: <7kWXDyszuJKOQe-hrfQk-PAn0gy5e-cCvRbvE2ZvhRs=.9b844ed5-3b6b-4d41-bd20-4fcf1d78ece6@github.com> On Sat, 12 Aug 2023 06:51:39 GMT, Thomas Stuefe wrote: > One proposal, possibly for a future RFE: could we maybe make checked_cast a smaller name? One gripe with C++ cast expressions I have is that they look ugly and give me RSI. Since this is our own name, and it is really omnipresent now, could we not shorten it (similar to macro names like "p2i")? For example `cc` There's a C++ style that goes with idiomatic C++ programs. I chose `checked_cast` because it is almost obvious to the reader familiar with C++ idioms what it's likely to do. In general, where there is precedent, I think we should go with existing C++ style. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15229#issuecomment-1676565704 From dholmes at openjdk.org Mon Aug 14 02:24:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Aug 2023 02:24:31 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: On Fri, 11 Aug 2023 11:58:01 GMT, Coleen Phillimore wrote: >> src/hotspot/os/aix/attachListener_aix.cpp line 279: >> >>> 277: // name ("load", "datadump", ...), and is an argument >>> 278: int expected_str_count = 2 + AttachOperation::arg_count_max; >>> 279: const unsigned max_len = (sizeof(ver_str) + 1) + (AttachOperation::name_length_max + 1) + >> >> size_t instead? > > The reason I changed it was to assign into size_t below without sign conversion. Sure, but can't it be size_t itself in the first place? >> src/hotspot/os/linux/os_linux.cpp line 404: >> >>> 402: // thread id is used to access /proc. >>> 403: pid_t os::Linux::gettid() { >>> 404: int64_t rslt = syscall(SYS_gettid); >> >> syscall returns an int > > It doesn't. I got a Wconversion warning converting to int here. I wouldn't have changed it otherwise. > > src/hotspot/os/linux/os_linux.cpp:404:21: warning: conversion from 'long int' to 'int' may change value [-Wconversion] > 404 | int rslt = syscall(SYS_gettid); > | ~~~~~~~^~~~~~~~~~~~ I have to prove I'm not an idiot here :). This is from the Linux manpage: NAME syscall - indirect system call SYNOPSIS #define _GNU_SOURCE /* See feature_test_macros(7) */ #include #include /* For SYS_xxx definitions */ int syscall(int number, ...); But yes the definition in unistd.h is `long int'. In platform specific code such as this, when a function returns a long then perhaps we should type the result variable as a long as well, rather than forcing to a 64-bit type? >> src/hotspot/os/linux/os_linux.cpp line 745: >> >>> 743: Monitor* sync = osthread->startThread_lock(); >>> 744: >>> 745: osthread->set_thread_id(checked_cast(os::current_thread_id())); >> >> This doesn't look right: `current_thread_id()` returns `intx` and `set_thread_id` takes `thread_id_t` > > src/hotspot/os/linux/os_linux.cpp:745:48: warning: conversion from 'intx' {aka 'long int'} to 'OSThread::thread_id_t' {aka 'int'} may change value [-Wconversion] > 745 | osthread->set_thread_id(os::current_thread_id()); > | ~~~~~~~~~~~~~~~~~~~~~^~ I understand there is a conversion warning, but it seems wrong to `check_cast` when the expected type is `thread_id_t` (which just happens to be an `int`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292910754 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292914563 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292916137 From dholmes at openjdk.org Mon Aug 14 02:24:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Aug 2023 02:24:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <3iwWmu4wOB-sRwfThnExs3UsQox3H67rKNaLDk6UJBg=.3421ba15-8ac3-4152-8f5b-d6379c6502c8@github.com> Message-ID: On Sat, 12 Aug 2023 12:54:21 GMT, Coleen Phillimore wrote: >> I'm curious, who is warning here? Is this a static code analysis? Since I don't think Oracle builds AIX, right? > > The AIX code is a copy of the linux code. I got a sign conversion warning on the linux code. > > src/hotspot/os/linux/attachListener_linux.cpp:275:14: warning: comparison of integer expressions of different signedness: 'ssize_t' {aka 'long int'} and 'size_t' {aka 'long unsigned int'} [-Wsign-compare] > 275 | assert(n <= left, "buffer was too small, impossible!"); > | ~~^~~~~~~ This is an example of how the basic integer type system is broken. You define size variables as `size_t` but then get `ssize_t` back from functions like `read`, and then you get warnings if you combine them in particular ways. In this particular case I don't even understand the conversion warning as semantically a maximum `ssize_t` must be < the maximum `size_t` so where is the loss? It also seems to me that the strictly correct way to address this would be to ensure the `ssize_t` variable is not -1 and then cast it to `size_t`, rather than downcasting the `size_t` variable to `ssize_t`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292912898 From dholmes at openjdk.org Mon Aug 14 02:24:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Aug 2023 02:24:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <75kdLIEw_BPJO866cnPRd6yNWBTZt6NSN-VgeIyiSwQ=.c87caece-5717-4560-bf1e-527cc8be51f9@github.com> Message-ID: <4GHRyVFHlbQNDyvGPQAwDAA33bABglAknD4oPzfs4Yk=.b0ba8ba8-0397-4ed0-849c-f7296d12d701@github.com> On Sat, 12 Aug 2023 13:01:08 GMT, Coleen Phillimore wrote: >> @coleenp: The only case where sysconf could be not a small positive integer is when it returns an error, -1, and checked_cast will not catch that since it still fits an int. >> >> Up to you, but I'd either leave this unchecked, or convert the parameter for set_processor_count to unsigned. >> >> @dean-long: >>> change func() to a template function >> >> I hope we don't do that, that sounds terrible. I still have to find a modern IDE that can work well with all the template code we have. The more templates we use, the worse features like call graph display work in IDEs like CDT or CLion. > > I'm also not in favor of additional templates to hide our use of wrongly sized integers. There's already enough time-consuming decoding in places and terrible error messages. I'd rather the integers be the right size. > I don't like tricks. I'm not opposed at all to direct C style casts where we know they fit. Seems simplest. I'll change this one. I think checked_cast should be used when the variable is potentially unconstrained, but as Thomas confirms these sysconf calls are only ever going to return small integers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292915210 From dholmes at openjdk.org Mon Aug 14 02:37:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Aug 2023 02:37:28 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: <80lRJvZChKfoYyEleacqeh8rWN_WxtcqSUPccKq7kqA=.64277ba8-097b-463a-a683-f737c07548ac@github.com> On Fri, 11 Aug 2023 12:17:18 GMT, Coleen Phillimore wrote: >> src/hotspot/os/linux/os_linux.cpp line 2991: >> >>> 2989: #endif >>> 2990: >>> 2991: return (retval == -1) ? checked_cast(retval) : cpu; >> >> If retval is -1 you can just return -1. And if cpu is uint and the function returns int then surely we need a cast on cpu here? > > I don't have -Wsign-conversion on. I'm not that much of a masochist. Fixed return value though. So `-Wconversion` is mainly of use in detecting overflow/overflow when dealing with variables of different size, yet unsigned to signed conversion can result in the exact the same problem, but that only gets detected by a separate `-Wsign-conversion` flag? >> src/hotspot/os/linux/waitBarrier_linux.cpp line 54: >> >>> 52: assert(_futex_barrier != 0, "Should be armed/non-zero."); >>> 53: _futex_barrier = 0; >>> 54: intptr_t s = futex(&_futex_barrier, >> >> futex returns an int > > src/hotspot/os/linux/waitBarrier_linux.cpp:41:17: warning: conversion from 'long int' to 'int' may change value [-Wconversion] > 41 | return syscall(SYS_futex, addr, futex_op, op_arg, nullptr, nullptr, 0); > | ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I was again referring to: SYNOPSIS #include #include int futex(int *uaddr, int op, int val, const struct timespec *timeout, int *uaddr2, int val3); But why `intptr_t` here, but `int64_t` in the earlier syscall case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292917490 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292918182 From dholmes at openjdk.org Mon Aug 14 02:37:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Aug 2023 02:37:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: <7PcVsJTuhdbER3x3OFX_Ol0DUUo9QE95KGf8-D1Kzrg=.33a3cb95-13cd-4a23-abf9-7ca4215a2893@github.com> On Fri, 11 Aug 2023 12:23:55 GMT, Coleen Phillimore wrote: >> src/hotspot/os/posix/os_posix.cpp:1211:31: warning: conversion from 'long int' to 'int' may change value [-Wconversion] >> 1211 | clock_tics_per_sec = sysconf(_SC_CLK_TCK); >> | ~~~~~~~^~~~~~~~~~~~~ > > Although I did the opposite for the linux version (ie casted the result of sysconf instead). I'm really starting to think we should just be using `long` in platform specific code, given it acts the same as `intx` on this platform. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292918965 From dholmes at openjdk.org Mon Aug 14 02:48:59 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Aug 2023 02:48:59 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: On Mon, 14 Aug 2023 02:21:22 GMT, David Holmes wrote: >> src/hotspot/os/linux/os_linux.cpp:745:48: warning: conversion from 'intx' {aka 'long int'} to 'OSThread::thread_id_t' {aka 'int'} may change value [-Wconversion] >> 745 | osthread->set_thread_id(os::current_thread_id()); >> | ~~~~~~~~~~~~~~~~~~~~~^~ > > I understand there is a conversion warning, but it seems wrong to `check_cast` when the expected type is `thread_id_t` (which just happens to be an `int`). I see this has been changed now - thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1292923264 From duke at openjdk.org Mon Aug 14 02:51:58 2023 From: duke at openjdk.org (duke) Date: Mon, 14 Aug 2023 02:51:58 GMT Subject: Withdrawn: JDK-8300582: Introduce interface for unaligned memory accesses In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:22:35 GMT, Justin King wrote: > Introduce interface for unaligned memory accesses `UnalignedAccess`, consolidate the byte swapping implementation to `byteswap`, and switch to a generic implementation of `Bytes`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/12078 From jwaters at openjdk.org Mon Aug 14 03:48:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Aug 2023 03:48:58 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove negation in os_windows.cpp Bumping, anything from security and awt folk? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1676618114 From jwaters at openjdk.org Mon Aug 14 04:28:31 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Aug 2023 04:28:31 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v3] In-Reply-To: References: <1W3XYadOwbC1ENELwpfdDpowgOmwnSRLnFd0F4W74Xo=.7d3f4b91-7f1f-41ba-9e97-4533d21693e6@github.com> Message-ID: <2bluDMNS-Ehn5s3wrK3Ah1otV9v98AQOPtG2O_QhjFM=.e4f3eae4-5988-4fea-8e19-779e28be7e67@github.com> On Tue, 1 Aug 2023 13:17:10 GMT, Kim Barrett wrote: > Most/all of the PTR_FORMAT => INTPTR_FORMAT changes should not be made. Especially those where the argument is the result of a call to p2i. The p2i thing plus the definition of PTR_FORMAT are a bit of a kludge to work around the variations in the implementations of "%p", which is what one might wish PTR_FORMAT was using. > > I've not looked at the rest yet. It would be easier to do so once the PTR_FORMAT => INTPTR_FORMAT changes were removed. Understood, will revert them as soon as I can ------------- PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1676647733 From haosun at openjdk.org Mon Aug 14 04:47:31 2023 From: haosun at openjdk.org (Hao Sun) Date: Mon, 14 Aug 2023 04:47:31 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v3] In-Reply-To: References: Message-ID: > ### Background > > 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. > > 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. > > 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. > > 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. > > 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. > > ### Goal > > This patch aims to make PAC-RET compatible with virtual threads. > > ### Requirements of virtual threads > > R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. > > R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. > > Note that more details can be found in the discussion [3]. > > ### Investigation > > We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. > > 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. > > 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. > > 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP should be preserved to make it easy to find this modifier in case of... Hao Sun has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Remove my temp test patch on jvmci_global.hpp and stubGenerator_aarch64.hpp - Use relative SP as the PAC modifier - Merge branch 'master' into jdk-8287325 - Merge branch 'master' into jdk-8287325 - Rename return_pc_at and patch_pc_at Rename return_pc_at to return_address_at. Rename patch_pc_at to patch_return_address_at. - 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret * Background 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. * Goal This patch aims to make PAC-RET compatible with virtual threads. * Requirements of virtual threads R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. Note that more details can be found in the discussion [3]. * Investigation We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. 3. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP should be preserved to make it easy to find this modifier in case of some exception scenarios (Recall the reason why we fail to use SP as the modifier). Finally, we choose to use value zero as the modifier. Trivially, it's compatible with virtual threads. However, compared to FP modifier, this solution would reduce the strength of PAC-RET protection to some extent. E.g., you get the same authentication code for each call to the function, whereas using FP gives you different codes as long as the stack depth is different. * Implementation of Zero modifier Here list the key updates of this patch. 1. vm_version_aarch64.cpp Remove the constraint on "enable-preview" and "PreserveFramePointer". 2. macroAssembler_aarch64.cpp For utility protect_return_address(), 1) use PACIAZ/PACIZA instructions directly. 2) argument "temp_reg" is removed since all functions use the same modifier. 3) all the use sites are updated accordingly. This involves the updates in many files. Similar updates are done to utility authenticate_return_address(). Besides, aarch64.ad and AArch64TestAssembler.java are updated accordingly. 3. pauth_linux_aarch64.inline.hpp For utilities pauth_sign_return_address() and pauth_authenticate_return_address(), remove the second argument and pass value zero to r16 register. Similarly, all the use sites are updated as well. This involves the updates in many files. 4. continuationHelper_aarch64.inline.hpp Introduce return_pc_at() and patch_pc_at() to avoid directly reading the saved PC or writing new signed PC on the stack in shared code. 5. Minor updates 1) sharedRuntime_aarch64.cpp: Add the missing authenticate_return_address() use for function gen_continuation_enter(). In functions generate_deopt_blob() and generate_uncommon_trap_blob(), remove the authentication on the caller (3) frame since the return address is not used. 2) stubGenerator_aarch64.cpp: Add the missing authenticate_return_address() use for function generate_cont_thaw(). 3) runtime.cpp: enable the authentication. * Test 1. Cross compilations on arm32/s390/ppc/riscv passed. 2. zero build and x86 build passed. 3. tier1~3 passed on Linux/AArch64 w/ and w/o PAC-RET. Co-Developed-by: Nick Gasson [1] https://bugs.openjdk.org/browse/JDK-8277204 [2] https://openjdk.org/jeps/425 [3] https://github.com/openjdk/jdk/pull/9067 [4] https://bugs.openjdk.org/browse/JDK-8288023 [5] https://bugs.openjdk.org/browse/JDK-8301819 [6] https://openjdk.org/jeps/444 [7] https://www.usenix.org/conference/usenixsecurity21/presentation/liljestrand [8] https://github.com/openjdk/jdk/pull/10441 ------------- Changes: https://git.openjdk.org/jdk/pull/13322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13322&range=02 Stats: 309 lines in 30 files changed: 181 ins; 18 del; 110 mod Patch: https://git.openjdk.org/jdk/pull/13322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13322/head:pull/13322 PR: https://git.openjdk.org/jdk/pull/13322 From haosun at openjdk.org Mon Aug 14 04:47:32 2023 From: haosun at openjdk.org (Hao Sun) Date: Mon, 14 Aug 2023 04:47:32 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 20:32:49 GMT, Dean Long wrote: >>> Using SP seems like the right way to go. Can't we compute the correct SP value to use in Runtime1::generate_handle_exception()? >> >> Thanks for your question, Dean. >> Thinking more about it, I guess we can get the expected SP value. >> >> In my local test, I always use `rfp + 16` to authenticate the return address, and test cases under `test/jdk/java/lang/Thread/` and `test/hotspot/jtreg/compiler/c2/` can pass except the `virtual thread` cases. I'm running tier1-3 now. >> >> My concern is that **using absolute SP** is incompatible with **virtual thread**, since PAC re-sign is still needed due to the stack copying process (See Requirement-2 in the commit message). Alternatively, we may want to use **relative SP** as the modifier. >> >> However, I didn't know how to get such an **initial SP** value. Do you have any idea? >> Thanks. > > @shqking, to get a relative SP, I think you would want to subtract SP from thread->last_continuation()->entry_sp(). Thanks @dean-long for the suggestion of using `relative SP` as the modifier. Currently I implemented one prototype(See https://github.com/shqking/jdk/commit/bcc15fd09f7dc) but there are still several TODOs to address. I will continue to fix the TODOs and make this solution ready for official review. But I'd like to share the code in advance if you're interested. Any comment/feedback is welcome. Thanks. ### relative SP Different from [1], this is another implementation of PAC-RET branch protection on Linux/AArch64, i.e. using relative SP as the modifier. Note that `relative SP = signing SP - initial SP`, where signing SP is the lowest address of the frame record where LR is saved, and initial SP is `thread->last_continuation()->entry_sp()`. For non-virtual thread, initial SP is zero, and relative SP becomes absolute SP in this case. // For virtual thread: | | |==========| | | // Continuation.run | | |==========|\ | | | ContinuationEntry Address | | | high initial SP ---> |==========|/ | | | | | ... | |/ | | low |==========|\ | LR | | | FP | | frame record signing SP ---> |----------|/ | | | | ### Implementation Here lists the key difference from zero modifier [1] in implementation. 1. initial SP: We need access the thread register (i.e. `rthread`) to load the initial SP. However, `rthread` is not assigned yet at the time of stack frame creation for `make_upcall_stub()` and `generate_call_stub()`. 2. initial SP: For shared code, we utilize `Continuation::get_continuation_entry_for_sp()` to find the continuation which the signing SP belongs to. See the update in `continuationHelper_aarch64.inline.hpp`, `frame_aarch64.cpp` and `frame_aarch64.inline.hpp`. 3. signing SP: It's easy to compute the signing SP in most cases, but special handling is needed for `patch_callers_callsite()` as `push_CPU_state()` moves the SP a lot. 4. relative SP: One temporary register is needed to save the result. We choose to use `rscratch1`. Note that for the safety consideration, we save/restore it on the stack before/after PAC. See the code in `protect_return_address(Register thread)` and `authenticate_return_address(Register thread)`. ### Test Ran tier1~3 on Linux/AArch64 w/ and w/o PAC-RET and got only one new failure, i.e. `jdk/internal/vm/Continuation/Fuzz.java`. ### TODOs 1. Fix the jtreg failure: `jdk/internal/vm/Continuation/Fuzz.java` 2. Following [1], we didn't authenticate the return address in the following functons. We should try to enable the authentication. ContinuationHelper::return_address_at() ContinuationHelper::Frame::real_pc() StackChunkFrameStream::get_pc() 3. Some tests in `stubRoutines.cpp` are disabled, because these tests are conducted during the VM initialization phase and thread register is not assigned yet. We may want to move these tests to some other places. 4. We thought it's the usual convention that any MacroAssembler call can clobber `rscratch1` or `rscratch2` registers. We cannot do that in `protect_return_address()` and `authenticate_return_address()`. Here shows an exception case [2]. We may need revisit all the usages of `rscratch1` and `rscratch2` to check if this convention can be guaranteed. [1] https://github.com/openjdk/jdk/pull/13322 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L2936-L2949 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1566347900 From aph at openjdk.org Mon Aug 14 04:47:32 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 14 Aug 2023 04:47:32 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret In-Reply-To: References: Message-ID: On Mon, 29 May 2023 01:13:33 GMT, Hao Sun wrote: > We thought it's the usual convention that any MacroAssembler call can clobber rscratch1 or rscratch2 registers. We > cannot do that in protect_return_address() and authenticate_return_address(). Here shows an exception case [2]. We > may need revisit all the usages of rscratch1 and rscratch2 to check if this convention can be guaranteed. Generally speaking, that is the rule. If LR is not live in the snippet you mentioned, we could use LR instead of rscratch1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1566865984 From haosun at openjdk.org Mon Aug 14 04:47:33 2023 From: haosun at openjdk.org (Hao Sun) Date: Mon, 14 Aug 2023 04:47:33 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret In-Reply-To: References: Message-ID: On Mon, 29 May 2023 09:48:02 GMT, Andrew Haley wrote: > > We thought it's the usual convention that any MacroAssembler call can clobber rscratch1 or rscratch2 registers. We > > cannot do that in protect_return_address() and authenticate_return_address(). Here shows an exception case [2]. We > > may need revisit all the usages of rscratch1 and rscratch2 to check if this convention can be guaranteed. > > Generally speaking, that is the rule. If LR is not live in the snippet you mentioned, we could use LR instead of rscratch1. Thanks for your comment. But the fact is that LR is **live** in the PAC code generation/authentication parts, since LR is one of the three inputs to PAC(Note that the other two are the modifier and the key). As a result, I'm afraid we could not use LR as scratch register there either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1566876770 From dlong at openjdk.org Mon Aug 14 04:47:34 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 04:47:34 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v2] In-Reply-To: References: Message-ID: On Fri, 7 Apr 2023 03:25:44 GMT, Hao Sun wrote: >> ### Background >> >> 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. >> >> 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. >> >> 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. >> >> 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. >> >> 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. >> >> ### Goal >> >> This patch aims to make PAC-RET compatible with virtual threads. >> >> ### Requirements of virtual threads >> >> R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. >> >> R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. >> >> Note that more details can be found in the discussion [3]. >> >> ### Investigation >> >> We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. >> >> 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. >> >> 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. >> >> 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP sh... > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Rename return_pc_at and patch_pc_at > > Rename return_pc_at to return_address_at. > Rename patch_pc_at to patch_return_address_at. What I thinking was to use the absolute SP during call/return, but "relativize" it on continuation freeze and then rewrite to the new absolute address on thaw. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1571172982 From haosun at openjdk.org Mon Aug 14 04:47:34 2023 From: haosun at openjdk.org (Hao Sun) Date: Mon, 14 Aug 2023 04:47:34 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v2] In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 01:13:08 GMT, Dean Long wrote: > What I thinking was to use the absolute SP during call/return, but "relativize" it on continuation freeze and then rewrite to the new absolute address on thaw. Thanks for your review. But the exception is that the **fast path** in stack copying doesn't walk the frames. In this case, I'm afraid we have no chance to "relativize" the SP. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1575899183 From dlong at openjdk.org Mon Aug 14 04:47:35 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 04:47:35 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jun 2023 01:15:40 GMT, Hao Sun wrote: > > What I thinking was to use the absolute SP during call/return, but "relativize" it on continuation freeze and then rewrite to the new absolute address on thaw. > > Thanks for your review. But the exception is that the **fast path** in stack copying doesn't walk the frames. In this case, I'm afraid we have no chance to "relativize" the SP. OK, that makes sense. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1577239174 From aph at openjdk.org Mon Aug 14 04:47:35 2023 From: aph at openjdk.org (Andrew Haley) Date: Mon, 14 Aug 2023 04:47:35 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v2] In-Reply-To: References: Message-ID: <8MhWB-8yPUc-rYonrG6Fxb_Ps6Vrat_kVrcPhx7uh0w=.645e16a4-169a-441e-b9eb-b9f550541e81@github.com> On Fri, 7 Apr 2023 03:25:44 GMT, Hao Sun wrote: >> ### Background >> >> 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. >> >> 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. >> >> 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. >> >> 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. >> >> 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. >> >> ### Goal >> >> This patch aims to make PAC-RET compatible with virtual threads. >> >> ### Requirements of virtual threads >> >> R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. >> >> R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. >> >> Note that more details can be found in the discussion [3]. >> >> ### Investigation >> >> We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. >> >> 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. >> >> 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. >> >> 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP sh... > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Rename return_pc_at and patch_pc_at > > Rename return_pc_at to return_address_at. > Rename patch_pc_at to patch_return_address_at. > > Finally, we choose to use value zero as the modifier. Trivially, it's compatible with virtual threads. However, compared to FP modifier, this solution would reduce the strength of PAC-RET protection to some extent. E.g., you get the same authentication code for each call to the function, whereas using FP gives you different codes as long as the stack depth is different. So, how important is this weakening? Could we keep the FP, but save a relative FP into the stack in compiled code? That wouldn't be hard, and might be a better fix. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1674064242 From haosun at openjdk.org Mon Aug 14 04:47:35 2023 From: haosun at openjdk.org (Hao Sun) Date: Mon, 14 Aug 2023 04:47:35 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v2] In-Reply-To: References: Message-ID: On Fri, 7 Apr 2023 03:25:44 GMT, Hao Sun wrote: >> ### Background >> >> 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. >> >> 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. >> >> 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. >> >> 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. >> >> 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. >> >> ### Goal >> >> This patch aims to make PAC-RET compatible with virtual threads. >> >> ### Requirements of virtual threads >> >> R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. >> >> R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. >> >> Note that more details can be found in the discussion [3]. >> >> ### Investigation >> >> We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. >> >> 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. >> >> 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. >> >> 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP sh... > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Rename return_pc_at and patch_pc_at > > Rename return_pc_at to return_address_at. > Rename patch_pc_at to patch_return_address_at. This is ongoing work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1674028398 From haosun at openjdk.org Mon Aug 14 04:47:58 2023 From: haosun at openjdk.org (Hao Sun) Date: Mon, 14 Aug 2023 04:47:58 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v2] In-Reply-To: <8MhWB-8yPUc-rYonrG6Fxb_Ps6Vrat_kVrcPhx7uh0w=.645e16a4-169a-441e-b9eb-b9f550541e81@github.com> References: <8MhWB-8yPUc-rYonrG6Fxb_Ps6Vrat_kVrcPhx7uh0w=.645e16a4-169a-441e-b9eb-b9f550541e81@github.com> Message-ID: On Thu, 10 Aug 2023 23:53:34 GMT, Andrew Haley wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename return_pc_at and patch_pc_at >> >> Rename return_pc_at to return_address_at. >> Rename patch_pc_at to patch_return_address_at. > >> >> Finally, we choose to use value zero as the modifier. Trivially, it's compatible with virtual threads. However, compared to FP modifier, this solution would reduce the strength of PAC-RET protection to some extent. E.g., you get the same authentication code for each call to the function, whereas using FP gives you different codes as long as the stack depth is different. > > So, how important is this weakening? Could we keep the FP, but save a relative FP into the stack in compiled code? That wouldn't be hard, and might be a better fix. What do you think? Thanks for your comments. @theRealAph > So, how important is this weakening? To be honest, I'm not sure how to describe the importance degree. And as I see it, we should apply SP modifier if we can. > Could we keep the FP, but save a relative FP into the stack in compiled code? That wouldn't be hard, and might be a better fix. What do you think? I think it should work if we simply store the relative SP in the stack. And we should also store it for the "interpreted frame" as well, hence we may need update that metadata as well. Anyway, I just uploaded the new implementation, i.e. using **relative SP** as the PAC modifier, where we don't need store the relative SP on the stack. @theRealAph and @dean-long Could you help take another look at this patch? Thanks In the new commits, the four TODOs in our prototype [1] are addressed. TODO-1: Fuzz.java Frames may be freezed by the slow path and thawed by the fast path. Hence we need resign the return address for topmost frame, which is previously updated on heap frame by freeze_slow(). See the update in function Thaw::thaw_fast(). TODO-2: Enable more PAC authentications in shared code In the shared code, we try to do as many PAC signing and authentication as possible. But it's meaningless for the frames on the heap. TODO-3: stub tests at file stubRoutines.cpp This issue was fixed in [JDK-8310355](https://bugs.openjdk.java.net/browse/JDK-8310355) already. TODO-4: clobber rscratch1 or rscratch2 issue In our demo patch [2], we tried to find all the exception cases of rscratch2 usages, that is, we cannot clobber rscratch2 in enter() or leave(). In my local test, tier1~3 passed on Linux/AArch64. Even so, I'm not sure if we indeed find **all** the cases. Hence, in this new revision, we still follow the previous prototype, i.e. saving and resotring the scratch register on the stack for the sake of safety. Test: 1. Cross compilations on arm32/s390/ppc/riscv passed. 2. zero build and x86 build passed. 3. tier1~3 passed on Linux/AArch64 w/ and w/o PAC-RET. [1] https://github.com/openjdk/jdk/pull/13322#issuecomment-1566347900 [2] https://github.com/shqking/jdk/commit/c3ca8640 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1676658096 From mbaesken at openjdk.org Mon Aug 14 08:10:59 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 14 Aug 2023 08:10:59 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase Message-ID: Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. Some examples : Events::log_dll_message for hs-err files reporting JFR event NativeLibraryLoad There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information Offer an interface (e.g. jvm.cpp) to support this. ------------- Commit messages: - JDK-8313764 Changes: https://git.openjdk.org/jdk/pull/15264/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313764 Stats: 150 lines in 7 files changed: 150 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264 PR: https://git.openjdk.org/jdk/pull/15264 From alanb at openjdk.org Mon Aug 14 09:06:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 14 Aug 2023 09:06:33 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Having dlopen usages in non-core native libraries such as such as libsctp, libawt_xawt, ... have their dlopen usages compiled to use dlopen_ext in libjvm introduces questionable coupling that I think requires broader discussion. For the JFR NativeLibraryLoad event then I suppose there is a discussion on whether events for statically or dynamically loaded libs is interesting or not as there isn't a corresponding System.loadLibrary or SymbolLookup.libraryLookup. JDK-8314152 seems to very AIX specific with shared lib caching that I would hope complicate interfaces for other ports. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1676938047 From eosterlund at openjdk.org Mon Aug 14 09:11:30 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 14 Aug 2023 09:11:30 GMT Subject: RFR: 8314019: Add gc logging to jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 11:12:59 GMT, Stefan Karlsson wrote: > Add GC logging to this test so that we can figure out why this is intermittently throwing OOME. Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15207#pullrequestreview-1576380773 From stefank at openjdk.org Mon Aug 14 09:11:32 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 14 Aug 2023 09:11:32 GMT Subject: RFR: 8314019: Add gc logging to jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 11:12:59 GMT, Stefan Karlsson wrote: > Add GC logging to this test so that we can figure out why this is intermittently throwing OOME. Thanks for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15207#issuecomment-1676925915 From stefank at openjdk.org Mon Aug 14 09:11:32 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 14 Aug 2023 09:11:32 GMT Subject: Integrated: 8314019: Add gc logging to jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 11:12:59 GMT, Stefan Karlsson wrote: > Add GC logging to this test so that we can figure out why this is intermittently throwing OOME. This pull request has now been integrated. Changeset: 049b55f2 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/049b55f24e33559816c2b4b1abfda54f44fe87f5 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8314019: Add gc logging to jdk/jfr/event/gc/detailed/TestZAllocationStallEvent.java Reviewed-by: aboldtch, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/15207 From mbaesken at openjdk.org Mon Aug 14 10:21:00 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 14 Aug 2023 10:21:00 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Hi Alan, > JDK-8314152 seems to very AIX specific with shared lib caching that I would hope complicate interfaces for other ports. yes this is of course AIX specific. However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1677045118 From chagedorn at openjdk.org Mon Aug 14 11:25:59 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 14 Aug 2023 11:25:59 GMT Subject: RFR: 8313756: [BACKOUT] 8308682: Enhance AES performance Message-ID: <3p_rhD9NsHis0lGYoc5BOKJbaDaoqyDDCEhbCCgiZY8=.78197343-2a1b-44f1-8d94-d879c8d180cc@github.com> JDK-8308682 was wrongly attributed (contributor and missing reviewers). In order to fix this, we back the change out and reapply it with the correct attributions ([JDK-8313760](https://bugs.openjdk.org/browse/JDK-8313760)). The backout applied cleanly. Thanks, Christian ------------- Commit messages: - [BACKOUT] 8308682: Enhance AES performance Changes: https://git.openjdk.org/jdk/pull/15266/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15266&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313756 Stats: 107 lines in 7 files changed: 1 ins; 70 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/15266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15266/head:pull/15266 PR: https://git.openjdk.org/jdk/pull/15266 From thartmann at openjdk.org Mon Aug 14 11:26:30 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 14 Aug 2023 11:26:30 GMT Subject: RFR: 8313756: [BACKOUT] 8308682: Enhance AES performance In-Reply-To: <3p_rhD9NsHis0lGYoc5BOKJbaDaoqyDDCEhbCCgiZY8=.78197343-2a1b-44f1-8d94-d879c8d180cc@github.com> References: <3p_rhD9NsHis0lGYoc5BOKJbaDaoqyDDCEhbCCgiZY8=.78197343-2a1b-44f1-8d94-d879c8d180cc@github.com> Message-ID: On Mon, 14 Aug 2023 11:08:28 GMT, Christian Hagedorn wrote: > JDK-8308682 was wrongly attributed (contributor and missing reviewers). In order to fix this, we back the change out and reapply it with the correct attributions ([JDK-8313760](https://bugs.openjdk.org/browse/JDK-8313760)). > > The backout applied cleanly. > > Thanks, > Christian Looks good and trivial. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15266#pullrequestreview-1576643190 From chagedorn at openjdk.org Mon Aug 14 11:37:29 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 14 Aug 2023 11:37:29 GMT Subject: RFR: 8313756: [BACKOUT] 8308682: Enhance AES performance In-Reply-To: <3p_rhD9NsHis0lGYoc5BOKJbaDaoqyDDCEhbCCgiZY8=.78197343-2a1b-44f1-8d94-d879c8d180cc@github.com> References: <3p_rhD9NsHis0lGYoc5BOKJbaDaoqyDDCEhbCCgiZY8=.78197343-2a1b-44f1-8d94-d879c8d180cc@github.com> Message-ID: On Mon, 14 Aug 2023 11:08:28 GMT, Christian Hagedorn wrote: > JDK-8308682 was wrongly attributed (contributor and missing reviewers). In order to fix this, we back the change out and reapply it with the correct attributions ([JDK-8313760](https://bugs.openjdk.org/browse/JDK-8313760)). > > The backout applied cleanly. > > Thanks, > Christian Thanks Tobias for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15266#issuecomment-1677138770 From ogillespie at openjdk.org Mon Aug 14 11:43:03 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Mon, 14 Aug 2023 11:43:03 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v7] In-Reply-To: References: Message-ID: <3SO6LMVyClI5tqDbwdsIgeTd7Rc3vw9Rq4_zWgp_CJo=.07924acd-c7bb-40d2-8941-7044e1143e8c@github.com> > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: Fix failing test The test assertion relied on the buggy behaviour. Fix the desired ref count. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15137/files - new: https://git.openjdk.org/jdk/pull/15137/files/dd5ee5fe..35f05399 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15137&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15137/head:pull/15137 PR: https://git.openjdk.org/jdk/pull/15137 From ogillespie at openjdk.org Mon Aug 14 11:43:58 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Mon, 14 Aug 2023 11:43:58 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v6] In-Reply-To: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> References: <3EtJqnQ6D7M_A2Mguqn_wXWpBkTqU3-FbZi4MPlvkqQ=.baec60db-b1ec-48d3-b2b7-19e1e553b93c@github.com> Message-ID: On Thu, 10 Aug 2023 13:41:06 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Tweak comment Thanks for spotting, updated the test and it now passes ------------- PR Comment: https://git.openjdk.org/jdk/pull/15137#issuecomment-1677137463 From coleenp at openjdk.org Mon Aug 14 12:07:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 12:07:58 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v7] In-Reply-To: <3SO6LMVyClI5tqDbwdsIgeTd7Rc3vw9Rq4_zWgp_CJo=.07924acd-c7bb-40d2-8941-7044e1143e8c@github.com> References: <3SO6LMVyClI5tqDbwdsIgeTd7Rc3vw9Rq4_zWgp_CJo=.07924acd-c7bb-40d2-8941-7044e1143e8c@github.com> Message-ID: On Mon, 14 Aug 2023 11:43:03 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing test > > The test assertion relied on the buggy behaviour. > Fix the desired ref count. Thank you for fixing the test, and good idea to run them on this change. All the other testing was clean for this change. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1576693035 From shade at openjdk.org Mon Aug 14 12:09:28 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 14 Aug 2023 12:09:28 GMT Subject: RFR: 8313678 - SymbolTable can leak Symbols during cleanup [v7] In-Reply-To: <3SO6LMVyClI5tqDbwdsIgeTd7Rc3vw9Rq4_zWgp_CJo=.07924acd-c7bb-40d2-8941-7044e1143e8c@github.com> References: <3SO6LMVyClI5tqDbwdsIgeTd7Rc3vw9Rq4_zWgp_CJo=.07924acd-c7bb-40d2-8941-7044e1143e8c@github.com> Message-ID: <8N7FjhdfOYQCSzfEJ8UTmmcgkKMpXS9Y86QRXfUzeJ8=.19263710-ceae-4f58-ab1f-dd0c4b8d83e1@github.com> On Mon, 14 Aug 2023 11:43:03 GMT, Oli Gillespie wrote: >> Fix leak in SymbolTable during cleanup. >> >> 1. symbol1 inserted in bucket, refcount 1 >> 2. Decrement refcount for this symbol, refcount is now 0 >> 3. symbol2 inserted in same bucket >> 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket >> 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 >> 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount >> 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak >> >> The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. >> >> The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). >> >> Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. >> >> The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. >> >> I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. >> >> Thanks @shipilev for help debugging and fixing this :) > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing test > > The test assertion relied on the buggy behaviour. > Fix the desired ref count. Agreed, I think we are good to go. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15137#pullrequestreview-1576694564 From azafari at openjdk.org Mon Aug 14 12:11:34 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 14 Aug 2023 12:11:34 GMT Subject: RFR: 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits [v7] In-Reply-To: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> References: <_RHKYhxKOIB4ya5imXv1EQloz2yWThC8uIGcUV04vME=.5741b1a5-4afb-4ec4-8991-f14b0a8f6e6b@github.com> Message-ID: On Thu, 10 Aug 2023 14:45:30 GMT, Afshin Zafari wrote: >> The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. >> >> ### Tests >> tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug >> tier1 all passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a missed option. Thank you Coleen, Dean, David, Thomas and Ioi for your comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15164#issuecomment-1677184673 From azafari at openjdk.org Mon Aug 14 12:11:59 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 14 Aug 2023 12:11:59 GMT Subject: Integrated: 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 17:41:50 GMT, Afshin Zafari wrote: > The JVM options that are in range of `int` type are converted in `globals.hpp` and other files where affected. > > ### Tests > tiers 1-4 passed for linux-x64, linux-x64-debug, windows-x64, windows-x64-debug > tier1 all passed. This pull request has now been integrated. Changeset: 823f5b93 Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/823f5b930c917f36bb32aa0d0bda3ef0187db875 Stats: 22 lines in 7 files changed: 0 ins; 0 del; 22 mod 8308850: Change JVM options with small ranges that get -Wconversion warnings to 32 bits Reviewed-by: dholmes, coleenp, dlong ------------- PR: https://git.openjdk.org/jdk/pull/15164 From coleenp at openjdk.org Mon Aug 14 12:25:29 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 12:25:29 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v6] In-Reply-To: References: Message-ID: <0HD09MY8xg-2GTUImjBE3WaHP77HhXDX4T3nwQDbneE=.fdcad4db-8ea8-4e89-b6e2-d1de35b641e3@github.com> On Thu, 10 Aug 2023 19:07:55 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: >> >> - Thomas Stuefe and Dean's suggestions, turn Wconversion back off. >> - revert copyright change > > src/hotspot/os/bsd/os_bsd.cpp line 2215: > >> 2213: diff = filetime1.tv_nsec - filetime2.tv_nsec; >> 2214: } >> 2215: return checked_cast(diff); > > Suggestion: > > return diff; done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293371534 From chagedorn at openjdk.org Mon Aug 14 12:25:29 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 14 Aug 2023 12:25:29 GMT Subject: Integrated: 8313756: [BACKOUT] 8308682: Enhance AES performance In-Reply-To: <3p_rhD9NsHis0lGYoc5BOKJbaDaoqyDDCEhbCCgiZY8=.78197343-2a1b-44f1-8d94-d879c8d180cc@github.com> References: <3p_rhD9NsHis0lGYoc5BOKJbaDaoqyDDCEhbCCgiZY8=.78197343-2a1b-44f1-8d94-d879c8d180cc@github.com> Message-ID: On Mon, 14 Aug 2023 11:08:28 GMT, Christian Hagedorn wrote: > JDK-8308682 was wrongly attributed (contributor and missing reviewers). In order to fix this, we back the change out and reapply it with the correct attributions ([JDK-8313760](https://bugs.openjdk.org/browse/JDK-8313760)). > > The backout applied cleanly. > > Thanks, > Christian This pull request has now been integrated. Changeset: 207bd00c Author: Christian Hagedorn URL: https://git.openjdk.org/jdk/commit/207bd00c5101fce06b5ac12e76893d989b0093e2 Stats: 107 lines in 7 files changed: 1 ins; 70 del; 36 mod 8313756: [BACKOUT] 8308682: Enhance AES performance Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/jdk/pull/15266 From coleenp at openjdk.org Mon Aug 14 12:26:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 12:26:31 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: On Mon, 14 Aug 2023 02:16:06 GMT, David Holmes wrote: >> It doesn't. I got a Wconversion warning converting to int here. I wouldn't have changed it otherwise. >> >> src/hotspot/os/linux/os_linux.cpp:404:21: warning: conversion from 'long int' to 'int' may change value [-Wconversion] >> 404 | int rslt = syscall(SYS_gettid); >> | ~~~~~~~^~~~~~~~~~~~ > > I have to prove I'm not an idiot here :). This is from the Linux manpage: > > NAME > syscall - indirect system call > > SYNOPSIS > #define _GNU_SOURCE /* See feature_test_macros(7) */ > #include > #include /* For SYS_xxx definitions */ > > int syscall(int number, ...); > > But yes the definition in unistd.h is `long int'. > > In platform specific code such as this, when a function returns a long then perhaps we should type the result variable as a long as well, rather than forcing to a 64-bit type? We discussed purging 'long' from the code but since this is platform specific code, then we can use long here to match the type of syscall. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293382554 From coleenp at openjdk.org Mon Aug 14 12:26:33 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 12:26:33 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v5] In-Reply-To: References: <-FbUxcZUISaSr_6Xk6ZDShTi5hNAjiXgdKhEKLT2LPQ=.c5614314-f150-429f-b033-a36262c59d54@github.com> Message-ID: On Sat, 12 Aug 2023 12:55:30 GMT, Coleen Phillimore wrote: >> I am in favour of `long` too, since that is what syscall returns. int64_t does not seem to have any obvious relation to the call. And there is no reason to need 64-bit on 32-bit Linux. > > We try to avoid using long in the hotspot source code, at least in the shared code since long is a different size on windows. The preference is to use int64_t. I suppose we can use long in platform code. I'll change it to long. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293384148 From evergizova at openjdk.org Mon Aug 14 13:39:59 2023 From: evergizova at openjdk.org (Ekaterina Vergizova) Date: Mon, 14 Aug 2023 13:39:59 GMT Subject: RFR: 8314220: Configurable InlineCacheBuffer size Message-ID: InlineCacheBuffer size is currently hardcoded to 10K. This can lead to multiple ICBufferFull safepoints for InlineCacheBuffer cleanup and possible performance degradation. Added experimental command line option InlineCacheBufferSize with the same default value, allowing it to be configured for performance experiments with ICBufferFull safepoints frequency. ------------- Commit messages: - 8314220: Configurable InlineCacheBuffer size Changes: https://git.openjdk.org/jdk/pull/15271/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15271&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314220 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15271/head:pull/15271 PR: https://git.openjdk.org/jdk/pull/15271 From coleenp at openjdk.org Mon Aug 14 15:04:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 15:04:58 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v7] In-Reply-To: References: Message-ID: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use 'long' and fix -Wsign-compare warnings from previous edit. Make max_len size_t in the three places. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/c4c4584d..6d3f4765 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=05-06 Stats: 18 lines in 6 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From mbaesken at openjdk.org Mon Aug 14 15:11:28 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 14 Aug 2023 15:11:28 GMT Subject: RFR: JDK-8314211: Add NativeLibraryUnload event Message-ID: [JDK-8313251](https://bugs.openjdk.org/browse/JDK-8313251) introduced a a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. There should be a similar event for unload operations of shared libs. ------------- Commit messages: - JDK-8314211 Changes: https://git.openjdk.org/jdk/pull/15272/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15272&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314211 Stats: 66 lines in 7 files changed: 64 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15272.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15272/head:pull/15272 PR: https://git.openjdk.org/jdk/pull/15272 From mdoerr at openjdk.org Mon Aug 14 15:53:28 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 14 Aug 2023 15:53:28 GMT Subject: RFR: 8308479: [s390x] Implement alternative fast-locking scheme [v8] In-Reply-To: References: Message-ID: On Fri, 23 Jun 2023 05:44:04 GMT, Amit Kumar wrote: >> This PR implements new fast-locking scheme for s390x. Additionally few parameters have been renamed to be in sync with PPC. >> >> Testing done (for release, fastdebug and slowdebug build): >> All `test/jdk/java/util/concurrent` test with parameters: >> * LockingMode=2 >> * LockingMode=2 with -Xint >> * LockingMode=2 with -XX:TieredStopAtLevel=1 >> * LockingMode=2 with -XX:-TieredCompilation >> >> Result is consistently similar to Aarch(MacOS) and PPC, All of 124 tests are passing except `MapLoops.java` because in the 2nd part for this testcase, jvm starts with `HeavyMonitors` which conflict with `LockingMode=2` >> >> BenchMark Result for Renaissance-jmh: >> >> | Benchmark | Without fastLock (ms/op) | With fastLock (ms/op) | Improvement | >> |------------------------------------------|-------------------------|----------------------|-------------| >> | o.r.actors.JmhAkkaUct.runOperation | 1565.080 | 1365.877 | 12.70% | >> | o.r.actors.JmhReactors.runOperation | 9316.972 | 10592.982 | -13.70% | >> | o.r.jdk.concurrent.JmhFjKmeans.runOperation | 1257.183 | 1235.530 | 1.73% | >> | o.r.jdk.concurrent.JmhFutureGenetic.runOperation | 1925.158 | 2073.066 | -7.69% | >> | o.r.jdk.streams.JmhParMnemonics.runOperation | 2746.664 | 2836.085 | -3.24% | >> | o.r.jdk.streams.JmhScrabble.runOperation | 76.774 | 74.239 | 3.31% | >> | o.r.rx.JmhRxScrabble.runOperation | 162.270 | 167.061 | -2.96% | >> | o.r.scala.sat.JmhScalaDoku.runOperation | 3333.711 | 3271.078 | 1.88% | >> | o.r.scala.stdlib.JmhScalaKmeans.runOperation | 182.746 | 182.153 | 0.33% | >> | o.r.scala.stm.JmhPhilosophers.runOperation | 15003.329 | 13396.921 | 10.57% | >> | o.r.scala.stm.JmhScalaStmBench7.runOperation | 1669.090 | 1579.900 | 5.34% | >> | o.r.twitter.finagle.JmhFinagleChirper.runOperation | 9601.963 | 10034.404 | -4.52% | >> | o.r.twitter.finagle.JmhFinagleHttp.runOperation | 4403.725 | 4746.707 | -7.79% | >> >> >> DaCapo Benchmark Result: >> >> | Benchmark | Without fast lock (msec) | With fast lock (msec) | Improvement | >> |--... > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestions from Martin I think my concerns had been addressed. The performance topic can be investigated later if there's not enough time right now. I think it's good enough for an experimental feature. What's your opinion, @RealLucy? ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14414#pullrequestreview-1577104336 From ogillespie at openjdk.org Mon Aug 14 16:26:32 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Mon, 14 Aug 2023 16:26:32 GMT Subject: Integrated: 8313678 - SymbolTable can leak Symbols during cleanup In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 11:21:27 GMT, Oli Gillespie wrote: > Fix leak in SymbolTable during cleanup. > > 1. symbol1 inserted in bucket, refcount 1 > 2. Decrement refcount for this symbol, refcount is now 0 > 3. symbol2 inserted in same bucket > 4. during insertion, concurrentHashTable notices there is a dead entry in this bucket > 4a. This triggers delete_in_bucket, which triggers SymbolTableLookup.equals for symbol2 > 4b. SymbolTableLookup.equals for symbol2 spuriously increments symbol2's refcount > 5. symbol2 is newly inserted with a refcount of 2, thus can never be cleaned up -> leak > > The cleanup routine of concurrentHashTable uses the lookup function for its secondary effect of checking whether any particular value is dead or not. It does not actually care about the main purpose of the lookup function, i.e. checking if a particular value is the desired value. > > The lookup function for SymbolTable, however, has the side effect of incrementing the Symbol refcount when the lookup succeeds. This is presumably with the assumption that a successful lookup will result in a newly held reference. concurrentHashTable's delete_in_bucket can break this assumption by completing a successful lookup without retaining the result (nor ever decrementing the refcount). > > Thus, with a particular sequence of events (as shown in the new test case), a newly inserted Symbol can have a refcount of 2 instead of 1. Even if all legitimate references to this Symbol are removed, it will remain live, thus leaking. > > The fix allows the caller of .equals to specify if they intend to use the value after the lookup, or not, allowing SymbolTable to only increment the refcount when appropriate. > > I'd be happy to hear if anyone has any alternative suggestions for the fix, it seems a bit awkward/dangerous in general that SymbolTableLookup's equals increments the refcount. Also, any suggestions for implementing the test case without relying on the String.hashCode implementation would be great. > > Thanks @shipilev for help debugging and fixing this :) This pull request has now been integrated. Changeset: 4b2703ad Author: Oli Gillespie Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/4b2703ad39f8160264eb30c797824cc93a6b56e2 Stats: 82 lines in 11 files changed: 53 ins; 14 del; 15 mod 8313678: SymbolTable can leak Symbols during cleanup Reviewed-by: coleenp, dholmes, shade ------------- PR: https://git.openjdk.org/jdk/pull/15137 From dlong at openjdk.org Mon Aug 14 19:49:26 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 19:49:26 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <3iwWmu4wOB-sRwfThnExs3UsQox3H67rKNaLDk6UJBg=.3421ba15-8ac3-4152-8f5b-d6379c6502c8@github.com> Message-ID: On Mon, 14 Aug 2023 02:10:31 GMT, David Holmes wrote: >> The AIX code is a copy of the linux code. I got a sign conversion warning on the linux code. >> >> src/hotspot/os/linux/attachListener_linux.cpp:275:14: warning: comparison of integer expressions of different signedness: 'ssize_t' {aka 'long int'} and 'size_t' {aka 'long unsigned int'} [-Wsign-compare] >> 275 | assert(n <= left, "buffer was too small, impossible!"); >> | ~~^~~~~~~ > > This is an example of how the basic integer type system is broken. You define size variables as `size_t` but then get `ssize_t` back from functions like `read`, and then you get warnings if you combine them in particular ways. In this particular case I don't even understand the conversion warning as semantically a maximum `ssize_t` must be < the maximum `size_t` so where is the loss? It also seems to me that the strictly correct way to address this would be to ensure the `ssize_t` variable is not -1 and then cast it to `size_t`, rather than downcasting the `size_t` variable to `ssize_t`. Isn't the compiler complaining because the comparison will be done as unsigned, and a negative value turns into a huge unsigned value? To do a loss-less compare, both sides would need to be widened to a common signed type that can represent either side, like __int128_t. There's probably an equivalent way to do it with 64-bit values, but I think it would involve more than one compare. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293901494 From dlong at openjdk.org Mon Aug 14 19:57:06 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 19:57:06 GMT Subject: RFR: 8314220: Configurable InlineCacheBuffer size In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 13:12:16 GMT, Ekaterina Vergizova wrote: > InlineCacheBuffer size is currently hardcoded to 10K. > This can lead to multiple ICBufferFull safepoints for InlineCacheBuffer cleanup and possible performance degradation. > > Added experimental command line option InlineCacheBufferSize with the same default value, allowing it to be configured for performance experiments with ICBufferFull safepoints frequency. I like the idea of getting rid of this arbitrary limit, but it might be better to either: 1) scale the default size value based on the code cache size (ergonomics)? 2) grow the buffer as needed, no size flag needed I would prefer 2). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15271#issuecomment-1677970789 From coleenp at openjdk.org Mon Aug 14 19:57:08 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 19:57:08 GMT Subject: RFR: 8314220: Configurable InlineCacheBuffer size In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 13:12:16 GMT, Ekaterina Vergizova wrote: > InlineCacheBuffer size is currently hardcoded to 10K. > This can lead to multiple ICBufferFull safepoints for InlineCacheBuffer cleanup and possible performance degradation. > > Added experimental command line option InlineCacheBufferSize with the same default value, allowing it to be configured for performance experiments with ICBufferFull safepoints frequency. src/hotspot/share/runtime/globals.hpp line 299: > 297: \ > 298: product(uintx, InlineCacheBufferSize, 10*K, EXPERIMENTAL, \ > 299: "InlineCacheBuffer size") \ Can you make this type an int and add a range to it? Line 143 above will get -Wconversion warnings if we ever turned them on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15271#discussion_r1293908483 From dlong at openjdk.org Mon Aug 14 20:11:16 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 20:11:16 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v7] In-Reply-To: References: Message-ID: <9LZWRSFVpdxArrhMMFqb2MaI3eMeEBHiO0Q7pCOUWkg=.69940830-259d-4905-abbe-d79c48b00d0c@github.com> On Mon, 14 Aug 2023 15:04:58 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use 'long' and fix -Wsign-compare warnings from previous edit. Make max_len size_t in the three places. src/hotspot/os/linux/os_linux.cpp line 745: > 743: Monitor* sync = osthread->startThread_lock(); > 744: > 745: osthread->set_thread_id(checked_cast(os::current_thread_id())); I don't see the change @dholmes-ora. Suggestion: osthread->set_thread_id(checked_cast(os::current_thread_id())); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293918754 From dlong at openjdk.org Mon Aug 14 20:11:17 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 20:11:17 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: On Fri, 11 Aug 2023 12:37:29 GMT, Coleen Phillimore wrote: >> src/hotspot/os/linux/os_linux.cpp line 1272: >> >>> 1270: fp = os::fopen("/proc/self/stat", "r"); >>> 1271: if (fp) { >>> 1272: statlen = checked_cast(fread(stat, 1, 2047, fp)); >> >> checked_cast seems unnecessary given we're reading max 2047 elements. > > Made statlen size_t to match fread return. I still see "int statlen". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293920039 From dlong at openjdk.org Mon Aug 14 20:19:17 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 20:19:17 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v7] In-Reply-To: <9LZWRSFVpdxArrhMMFqb2MaI3eMeEBHiO0Q7pCOUWkg=.69940830-259d-4905-abbe-d79c48b00d0c@github.com> References: <9LZWRSFVpdxArrhMMFqb2MaI3eMeEBHiO0Q7pCOUWkg=.69940830-259d-4905-abbe-d79c48b00d0c@github.com> Message-ID: <4xuok8nFjIrwmYlk_-04H6zyjz-iGQzxhCNQEzYUXkk=.0a7ea28b-889e-4d5f-a3f7-a6aca55b9449@github.com> On Mon, 14 Aug 2023 20:06:50 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use 'long' and fix -Wsign-compare warnings from previous edit. Make max_len size_t in the three places. > > src/hotspot/os/linux/os_linux.cpp line 745: > >> 743: Monitor* sync = osthread->startThread_lock(); >> 744: >> 745: osthread->set_thread_id(checked_cast(os::current_thread_id())); > > I don't see the change @dholmes-ora. > Suggestion: > > osthread->set_thread_id(checked_cast(os::current_thread_id())); Nevermind, I was looking at outdated changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293926996 From coleenp at openjdk.org Mon Aug 14 20:19:19 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 20:19:19 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v7] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 15:04:58 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use 'long' and fix -Wsign-compare warnings from previous edit. Make max_len size_t in the three places. src/hotspot/os/linux/os_linux.cpp line 745: > 743: Monitor* sync = osthread->startThread_lock(); > 744: > 745: osthread->set_thread_id(checked_cast(os::current_thread_id())); Here it is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293928881 From coleenp at openjdk.org Mon Aug 14 20:19:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 20:19:20 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: On Mon, 14 Aug 2023 20:08:30 GMT, Dean Long wrote: >> Made statlen size_t to match fread return. > > I still see "int statlen". size_t statlen; fp = os::fopen("/proc/self/stat", "r"); if (fp) { statlen = fread(stat, 1, 2047, fp); stat[statlen] = '\0'; fclose(fp); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293928139 From dlong at openjdk.org Mon Aug 14 20:38:18 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 20:38:18 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v7] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 15:04:58 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use 'long' and fix -Wsign-compare warnings from previous edit. Make max_len size_t in the three places. Marked as reviewed by dlong (Reviewer). src/hotspot/os/linux/os_linux.cpp line 1608: > 1606: // No more space in ebuf for additional diagnostics message > 1607: return nullptr; > 1608: } Suggestion: size_t ebuf_len = strlen(ebuf); if (ebuflen <= ebuf_len) { // No more space in ebuf for additional diagnostics message return nullptr; } size_t diag_msg_max_length = ebuflen - ebuf_len; src/hotspot/os/linux/os_linux.cpp line 1610: > 1608: } > 1609: > 1610: char* diag_msg_buf=ebuf+strlen(ebuf); Suggestion: char* diag_msg_buf=ebuf+ebuf_len; ------------- PR Review: https://git.openjdk.org/jdk/pull/15229#pullrequestreview-1577611177 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293942588 PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293943491 From prr at openjdk.org Mon Aug 14 20:42:07 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Aug 2023 20:42:07 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. I don't see why we need this .. The desktop module has a LOT of calls to dlopen() .. I wasn't sure why you were only interested in two of them. I suspect because there's #ifdef AIX blocks in both of these files that do AIX-specific things for the dlopen .. but I'm still not sure I understand .. why is what you are doing only wanted for the AIX cases ? And I'd prefer that if anything is done that whatever you need to do be entirely within that #ifdef AIX block and so not affect anything else. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678026889 From coleenp at openjdk.org Mon Aug 14 20:52:37 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 20:52:37 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v8] In-Reply-To: References: Message-ID: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/os/linux/os_linux.cpp Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> - Update src/hotspot/os/linux/os_linux.cpp Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/6d3f4765..1b804298 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=06-07 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From coleenp at openjdk.org Mon Aug 14 20:56:17 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 20:56:17 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> Message-ID: On Mon, 14 Aug 2023 02:03:22 GMT, David Holmes wrote: >> The reason I changed it was to assign into size_t below without sign conversion. > > Sure, but can't it be size_t itself in the first place? Ok, doesn't reintroduce warnings to change back to size_t. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293959632 From prr at openjdk.org Mon Aug 14 21:00:14 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Aug 2023 21:00:14 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove negation in os_windows.cpp I have no time to look at the client changes for quite some time so do not push it. No matter how many other people approve it. And in the meantime you can (1) explain how many client tests you ran - and it had better be all of them :-) (2) add a comment in the PR to explain each client change you made - at the site of the change. Comments like "Fields in awt_TextComponent.cpp" are not an explanation (3) On the broader front, I note that you just start off with "We should set the -permissive- flag for the Microsoft Visual C compiler" without explaining WHY and what it does. In fact from what I've read about -it seems like we would not want it .. it downgrades errors to warnings .. and surely that's a bad thing ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1678049894 From coleenp at openjdk.org Mon Aug 14 21:10:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 21:10:20 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v7] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 20:32:20 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use 'long' and fix -Wsign-compare warnings from previous edit. Make max_len size_t in the three places. > > src/hotspot/os/linux/os_linux.cpp line 1608: > >> 1606: // No more space in ebuf for additional diagnostics message >> 1607: return nullptr; >> 1608: } > > Suggestion: > > size_t ebuf_len = strlen(ebuf); > if (ebuflen <= ebuf_len) { > // No more space in ebuf for additional diagnostics message > return nullptr; > } > size_t diag_msg_max_length = ebuflen - ebuf_len; /scratch/cphillim/hg/22os-conversion/src/hotspot/os/linux/os_linux.cpp:1605:15: warning: comparison of integer expressions of different signedness: 'int' and 'size_t' {aka 'long unsigned int'} [-Wsign-compare] 1605 | if (ebuflen <= ebuf_len) { | ~~~~~~~~^~~~~~~~~~~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293971628 From dlong at openjdk.org Mon Aug 14 21:23:10 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 21:23:10 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove negation in os_windows.cpp I had the same confusion, reading "-permissive-" the same as /permissive, but the trailing "-" means disable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1678081977 From coleenp at openjdk.org Mon Aug 14 21:27:53 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 21:27:53 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v9] In-Reply-To: References: Message-ID: <4VWAxNQwUl-lmA1CFUR60-EaZDNNm-M8XJYx0LTMoXU=.76d998a5-b171-4674-ad83-cc15d403936f@github.com> > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix Wsign-comparison warning. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/1b804298..84905d74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From dlong at openjdk.org Mon Aug 14 21:27:56 2023 From: dlong at openjdk.org (Dean Long) Date: Mon, 14 Aug 2023 21:27:56 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v7] In-Reply-To: References: Message-ID: <8x0FgDDL052Vyh-3Hu5rAE4JY0IiZftxDP0q-IVdBf0=.26893405-2620-406f-bd5c-eeb1e8f54118@github.com> On Mon, 14 Aug 2023 21:07:46 GMT, Coleen Phillimore wrote: >> src/hotspot/os/linux/os_linux.cpp line 1608: >> >>> 1606: // No more space in ebuf for additional diagnostics message >>> 1607: return nullptr; >>> 1608: } >> >> Suggestion: >> >> size_t ebuf_len = strlen(ebuf); >> if (ebuflen <= ebuf_len) { >> // No more space in ebuf for additional diagnostics message >> return nullptr; >> } >> size_t diag_msg_max_length = ebuflen - ebuf_len; > > /scratch/cphillim/hg/22os-conversion/src/hotspot/os/linux/os_linux.cpp:1605:15: warning: comparison of integer expressions of different signedness: 'int' and 'size_t' {aka 'long unsigned int'} [-Wsign-compare] > 1605 | if (ebuflen <= ebuf_len) { > | ~~~~~~~~^~~~~~~~~~~ Sorry, I thought ebuflen was size_t. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1293982435 From prr at openjdk.org Mon Aug 14 21:29:18 2023 From: prr at openjdk.org (Phil Race) Date: Mon, 14 Aug 2023 21:29:18 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: <2PJWcAd4gIs8qK6NWqgLgYhEOmPS6iBvkQnhCCfp3pw=.2b11ffcb-17c8-45ad-b794-fbfd12f47fdb@github.com> On Mon, 14 Aug 2023 21:20:42 GMT, Dean Long wrote: > I had the same confusion, reading "-permissive-" the same as /permissive, but the trailing "-" means disable. Ah, my brain just saw that trailing - as somebody's idea of hyphenation. That's questionable syntax by the compiler IMO. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1678091565 From lmesnik at openjdk.org Mon Aug 14 22:25:32 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 14 Aug 2023 22:25:32 GMT Subject: RFR: 8314242: Update applications/scimark/Scimark.java to accept VM flags Message-ID: Test applications/scimark/Scimark.java is a small stress test which currently ignores VM flags and is vm.flagless. This fix update it to accept all flags. Tested by running tier1 and this test with additional VM flags. ------------- Commit messages: - 8314242: Update applications/scimark/Scimark.java to accept VM flags Changes: https://git.openjdk.org/jdk/pull/15280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314242 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15280/head:pull/15280 PR: https://git.openjdk.org/jdk/pull/15280 From coleenp at openjdk.org Mon Aug 14 22:27:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 14 Aug 2023 22:27:50 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v10] In-Reply-To: References: Message-ID: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Avoid second strlen(ebuf) with variable. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15229/files - new: https://git.openjdk.org/jdk/pull/15229/files/84905d74..b31e3a82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15229&range=08-09 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15229/head:pull/15229 PR: https://git.openjdk.org/jdk/pull/15229 From dholmes at openjdk.org Tue Aug 15 01:08:21 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Aug 2023 01:08:21 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v2] In-Reply-To: References: <9D9Zi8Y9CM8qZy5cLXDqOeCjeKVLsvINR1_5P0ydqIM=.09989d75-f9b2-4070-916c-f7d863fd0a85@github.com> <3iwWmu4wOB-sRwfThnExs3UsQox3H67rKNaLDk6UJBg=.3421ba15-8ac3-4152-8f5b-d6379c6502c8@github.com> Message-ID: On Mon, 14 Aug 2023 19:45:53 GMT, Dean Long wrote: >> This is an example of how the basic integer type system is broken. You define size variables as `size_t` but then get `ssize_t` back from functions like `read`, and then you get warnings if you combine them in particular ways. In this particular case I don't even understand the conversion warning as semantically a maximum `ssize_t` must be < the maximum `size_t` so where is the loss? It also seems to me that the strictly correct way to address this would be to ensure the `ssize_t` variable is not -1 and then cast it to `size_t`, rather than downcasting the `size_t` variable to `ssize_t`. > > Isn't the compiler complaining because the comparison will be done as unsigned, and a negative value turns into a huge unsigned value? To do a loss-less compare, both sides would need to be widened to a common signed type that can represent either side, like __int128_t. There's probably an equivalent way to do it with 64-bit values, but I think it would involve more than one compare. Yes that is the problem. My point is that the type system leads you into that problem even though you are trying to use the "correct" types. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15229#discussion_r1294096269 From dholmes at openjdk.org Tue Aug 15 01:25:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Aug 2023 01:25:19 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v10] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 22:27:50 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Avoid second strlen(ebuf) with variable. For the sake of moving forward, nothing further from me. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15229#pullrequestreview-1577855776 From jwaters at openjdk.org Tue Aug 15 02:34:10 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 15 Aug 2023 02:34:10 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Mon, 14 Aug 2023 20:57:24 GMT, Phil Race wrote: > I have no time to look at the client changes for quite some time so do not push it. No matter how many other people approve it. And in the meantime you can (1) explain how many client tests you ran - and it had better be all of them :-) (2) add a comment in the PR to explain each client change you made - at the site of the change. Comments like "Fields in awt_TextComponent.cpp" are not an explanation (3) On the broader front, I note that you just start off with "We should set the -permissive- flag for the Microsoft Visual C compiler" without explaining WHY and what it does. In fact from what I've read about -it seems like we would not want it .. it downgrades errors to warnings .. and surely that's a bad thing ? No worries, I was not planning on committing without approval from each group, this was why I set the required reviewers to 5, 2 for HotSpot, one for build, and so on. I'll add the comments later on, but right now I can explain the changes directly since it's slightly easier to do so: The changes to awt involve enclosing several areas which make heavy use of goto in scopes to avoid them jumping over the initialization of locals, reordering the order of includes to avoid Microsoft specific headers from using our redefined malloc, moving the definition of C++ static fields outside of extern "C" blocks, and removing the class qualifiers from field declarations in several classes. The last one is fairly obvious - It isn't legal C++ grammar to do so. For the fields that were moved, they have C++ linkage initially by virtue of being static members of a class, but their definitions are inside extern "C" blocks, which causes their linkage to conflict between C++ and C. For the reordering of includes, see my conversation with Thomas - With permissive- enabled C++ templates are properly conforming, and the header comip.h (which is included by comdef.h) uses a templated malloc somewhere, which due to our #define malloc in alloc.h fails since the identifier is obviously not d efined. This is actually a major problem that is potentially causing an invisible bug in awt.dll somewhere, aside from it not compiling with permissive-, the redefining of malloc and all other allocators like this is something @tstuefe has expressed some concern over, but I don't really know how to deal with the bigger underlying problem outside of reordering the includes to not let comdef.h use our #define'd malloc. For the enclosing of gotos in scopes Thomas has suggested using RAII instead of labels in awt, which is something that could be done outside of this change, but I'm still figuring out if doing so for the sites that this is a problem for in this change would be neater Noted, I'll also improve the explaination on what permissive- does and why we want it in just a moment ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1678344486 From jwaters at openjdk.org Tue Aug 15 03:10:38 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 15 Aug 2023 03:10:38 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v4] In-Reply-To: References: Message-ID: > Fix several formatting errors on Windows Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'openjdk:master' into format - zPhysicalMemoryBacking_windows.cpp - Bug - 8313302 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15063/files - new: https://git.openjdk.org/jdk/pull/15063/files/db9102a2..ddf2f723 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=02-03 Stats: 24613 lines in 1039 files changed: 11414 ins; 6492 del; 6707 mod Patch: https://git.openjdk.org/jdk/pull/15063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15063/head:pull/15063 PR: https://git.openjdk.org/jdk/pull/15063 From dholmes at openjdk.org Tue Aug 15 04:36:06 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Aug 2023 04:36:06 GMT Subject: RFR: 8314242: Update applications/scimark/Scimark.java to accept VM flags In-Reply-To: References: Message-ID: <0SrIRbcHUqVJsAPE0HEzOZJZ01Xb_Xnv9Idqnt-iYY0=.bc49c9c5-330b-4275-b6a3-45fc7a30d3df@github.com> On Mon, 14 Aug 2023 22:19:24 GMT, Leonid Mesnik wrote: > Test applications/scimark/Scimark.java is a small stress test which currently ignores VM flags and is vm.flagless. > This fix update it to accept all flags. > > Tested by running tier1 and this test with additional VM flags. test/hotspot/jtreg/applications/scimark/Scimark.java line 49: > 47: } > 48: > 49: System.setProperty("test.noclasspath", "true"); What does this do? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15280#discussion_r1294172195 From lmesnik at openjdk.org Tue Aug 15 05:15:07 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Aug 2023 05:15:07 GMT Subject: RFR: 8314242: Update applications/scimark/Scimark.java to accept VM flags In-Reply-To: <0SrIRbcHUqVJsAPE0HEzOZJZ01Xb_Xnv9Idqnt-iYY0=.bc49c9c5-330b-4275-b6a3-45fc7a30d3df@github.com> References: <0SrIRbcHUqVJsAPE0HEzOZJZ01Xb_Xnv9Idqnt-iYY0=.bc49c9c5-330b-4275-b6a3-45fc7a30d3df@github.com> Message-ID: On Tue, 15 Aug 2023 04:33:44 GMT, David Holmes wrote: >> Test applications/scimark/Scimark.java is a small stress test which currently ignores VM flags and is vm.flagless. >> This fix update it to accept all flags. >> >> Tested by running tier1 and this test with additional VM flags. > > test/hotspot/jtreg/applications/scimark/Scimark.java line 49: > >> 47: } >> 48: >> 49: System.setProperty("test.noclasspath", "true"); > > What does this do? The "test.noclasspath" is set to don't use the default classpath to run process and only add VM options. This test starts the 3rd-party application and doesn't need test classes and a test library in the path. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15280#discussion_r1294186156 From stuefe at openjdk.org Tue Aug 15 06:05:05 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 15 Aug 2023 06:05:05 GMT Subject: RFR: JDK-8314211: Add NativeLibraryUnload event In-Reply-To: References: Message-ID: <6pLP4oleApqB5rbTO6tIE5Yo_sdgJD1zkwP38HRgCkI=.dc85d582-f28d-441b-b899-8324b4f8346f@github.com> On Mon, 14 Aug 2023 14:51:50 GMT, Matthias Baesken wrote: > [JDK-8313251](https://bugs.openjdk.org/browse/JDK-8313251) introduced a a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. > There should be a similar event for unload operations of shared libs. LGTM. While looking at this, I saw that many dlopens in hotspot and jdk coding are not tracked, is that deliberate? Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15272#pullrequestreview-1578016761 From mbaesken at openjdk.org Tue Aug 15 07:23:17 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 15 Aug 2023 07:23:17 GMT Subject: RFR: JDK-8314211: Add NativeLibraryUnload event In-Reply-To: <6pLP4oleApqB5rbTO6tIE5Yo_sdgJD1zkwP38HRgCkI=.dc85d582-f28d-441b-b899-8324b4f8346f@github.com> References: <6pLP4oleApqB5rbTO6tIE5Yo_sdgJD1zkwP38HRgCkI=.dc85d582-f28d-441b-b899-8324b4f8346f@github.com> Message-ID: On Tue, 15 Aug 2023 06:01:57 GMT, Thomas Stuefe wrote: > LGTM. > > While looking at this, I saw that many dlopens in hotspot and jdk coding are not tracked, is that deliberate? > Hi Thomas, thanks for the review ! Regarding untracked dlopen in HS codebase, I added a few with https://bugs.openjdk.org/browse/JDK-8313616 8313616: support loading library members on AIX in os::dll_load I also had a question/discussion with David recently about untracked dlopen calls in HS and the outcome was that it was just seen not that important to track those . Regarding untracked dlopen in JDK C codebase I have this one open for review https://bugs.openjdk.org/browse/JDK-8313764 8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase ------------- PR Comment: https://git.openjdk.org/jdk/pull/15272#issuecomment-1678521598 From mbaesken at openjdk.org Tue Aug 15 07:43:23 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 15 Aug 2023 07:43:23 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Hi Phil, yes there are of course more call sites of dlopen in the JDK C codebase. I could cover them too, if this is wished. > . but I'm still not sure I understand .. why is what you are doing only wanted for the AIX cases ? The lib cache update ` LoadedLibraries::reload();` is AIX specific; the UL and JFR events are cross platform. ( Btw. in our proprietary JVM we have this approach for many years ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678538226 From dholmes at openjdk.org Tue Aug 15 08:05:09 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 15 Aug 2023 08:05:09 GMT Subject: RFR: 8314242: Update applications/scimark/Scimark.java to accept VM flags In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 22:19:24 GMT, Leonid Mesnik wrote: > Test applications/scimark/Scimark.java is a small stress test which currently ignores VM flags and is vm.flagless. > This fix update it to accept all flags. > > Tested by running tier1 and this test with additional VM flags. Seems okay. Time will tell if this test runs okay with all potential flags. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15280#pullrequestreview-1578126413 From coleenp at openjdk.org Tue Aug 15 11:08:25 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Aug 2023 11:08:25 GMT Subject: RFR: 8314114: Fix -Wconversion warnings in os code, primarily linux [v10] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 22:27:50 GMT, Coleen Phillimore wrote: >> This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. >> Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Avoid second strlen(ebuf) with variable. Thanks Dean, David and Thomas. I think your comments improved the change significantly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15229#issuecomment-1678757944 From coleenp at openjdk.org Tue Aug 15 11:08:26 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Aug 2023 11:08:26 GMT Subject: Integrated: 8314114: Fix -Wconversion warnings in os code, primarily linux In-Reply-To: References: Message-ID: <0A57XCrN1TbCGvI1KKIdF4tnEPysY2dAiCDMgbdnwbg=.55ee90ee-0696-4f1a-9edf-0ccce450ed39@github.com> On Thu, 10 Aug 2023 15:22:07 GMT, Coleen Phillimore wrote: > This change fixes various -Wconversion warnings from files in the os directories and related, widening types or adding checked_cast<> where narrowing. > Tested with tier1 on linux/macosx/windows and tier1-4 on linux-x64-debug, windows-x64-debug. This pull request has now been integrated. Changeset: 9ded8682 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/9ded86821b01d6d790850e9b49eedfc597c0c9a2 Stats: 131 lines in 18 files changed: 3 ins; 1 del; 127 mod 8314114: Fix -Wconversion warnings in os code, primarily linux Reviewed-by: dholmes, dlong ------------- PR: https://git.openjdk.org/jdk/pull/15229 From aph at openjdk.org Tue Aug 15 11:18:17 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Aug 2023 11:18:17 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v3] In-Reply-To: References: Message-ID: <65av8Ef3RPpFqINe_AoPfsagdbmp0Kbc0TBPCVClYxY=.d87d3c24-d3fb-4469-89a8-281a2109140e@github.com> On Mon, 14 Aug 2023 04:47:31 GMT, Hao Sun wrote: >> ### Background >> >> 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. >> >> 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. >> >> 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. >> >> 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. >> >> 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. >> >> ### Goal >> >> This patch aims to make PAC-RET compatible with virtual threads. >> >> ### Requirements of virtual threads >> >> R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. >> >> R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. >> >> Note that more details can be found in the discussion [3]. >> >> ### Investigation >> >> We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. >> >> 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. >> >> 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. >> >> 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP sh... > > Hao Sun has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Remove my temp test patch on jvmci_global.hpp and stubGenerator_aarch64.hpp > - Use relative SP as the PAC modifier > - Merge branch 'master' into jdk-8287325 > - Merge branch 'master' into jdk-8287325 > - Rename return_pc_at and patch_pc_at > > Rename return_pc_at to return_address_at. > Rename patch_pc_at to patch_return_address_at. > - 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret > > * Background > > 1. PAC-RET branch protection was initially implemented on Linux/AArch64 > in JDK-8277204 [1]. > > 2. However, it was broken with the introduction of virtual threads [2], > mainly because the continuation freeze/thaw mechanism would trigger > stack copying to/from memory, whereas the saved and signed LR on the > stack doesn't get re-signed accordingly. > > 3. PR-9067 [3] tried to implement the re-sign part, but it was not > accepted because option "PreserveFramePointer" is always turned on by > PAC-RET but this would slow down virtual threads by ~5-20x. > > 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview > language features are enabled. Note that virtual thread is one preview > feature then. > > 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. > > * Goal > > This patch aims to make PAC-RET compatible with virtual threads. > > * Requirements of virtual threads > > R-1: Option "PreserveFramePointer" should be turned off. That is, > PAC-RET implementation should not rely on frame pointer FP. Otherwise, > the fast path in stack copying will never be taken. > > R-2: Use some invariant values to stack copying as the modifier, so as > to avoid the PAC re-sign for continuation thaw, as the fast path in > stack copying doesn't walk the frame. > > Note that more details can be found in the discussion [3]. > > * Investigation > > We considered to use (relative) stack pointer SP, thread ID, PACStack > [7] and value zero as the candidate modifier. > > 1. SP: In some scenarios, we need to authenticate the return address in > places where the current SP doesn't match the SP on function entry. E.g. > see the usage in Runtime1::generate_handle_exception(). Hence, neither > absolute nor relative SP works. > > 2. thread ID (tid): It's invariant to virtual thread, but it's > nontrivial to access it from the JIT side.... src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6002: > 6000: pacia(lr, rscratch1); > 6001: ldp(rscratch1, zr, Address(post(sp, 2 * wordSize))); > 6002: } Suggestion: ldr(lr, Address(thread, JavaThread::cont_entry_offset())); sub(lr, sp, lr); pacia(lr, lr); } Maybe? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13322#discussion_r1294463429 From fbredberg at openjdk.org Tue Aug 15 12:01:41 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 15 Aug 2023 12:01:41 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v3] In-Reply-To: References: Message-ID: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> > Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. > Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. > > By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Removed the on_heap parameter from FrameValues::print_on ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14545/files - new: https://git.openjdk.org/jdk/pull/14545/files/e54b7090..1664979d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14545&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14545&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14545.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14545/head:pull/14545 PR: https://git.openjdk.org/jdk/pull/14545 From coleenp at openjdk.org Tue Aug 15 12:08:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Aug 2023 12:08:28 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code Message-ID: Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. Tested with tier1-4. ------------- Commit messages: - Use parse_integer instead of strtol with a cast. - Unset Wconversion - Fix elf files. - Revert utf8.cpp - Fix -Wconversion warnings in misc runtime code. - Fix command line flag and metaspace. Another 4 files. Changes: https://git.openjdk.org/jdk/pull/15233/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314265 Stats: 93 lines in 34 files changed: 4 ins; 2 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/15233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15233/head:pull/15233 PR: https://git.openjdk.org/jdk/pull/15233 From coleenp at openjdk.org Tue Aug 15 13:53:09 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Aug 2023 13:53:09 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 20:31:20 GMT, Coleen Phillimore wrote: > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. @tstuefe There are some metaspace changes here, can you look at this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15233#issuecomment-1678964968 From rkennke at openjdk.org Tue Aug 15 14:17:28 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 15 Aug 2023 14:17:28 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v33] In-Reply-To: <87ecc9JR1ie1bGLibg22j-nFA4KZjlpLWqZSZgFjuRA=.a6b7e527-c6be-47cd-b8c6-61cf51994cbf@github.com> References: <87ecc9JR1ie1bGLibg22j-nFA4KZjlpLWqZSZgFjuRA=.a6b7e527-c6be-47cd-b8c6-61cf51994cbf@github.com> Message-ID: On Tue, 9 May 2023 20:28:01 GMT, Coleen Phillimore wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix calls to removed instanceOopDesc::header_size() > > I was looking at this again, and my review is NOT a full review. I only reviewed the metadata changes. I think it'd be a good time to move this forward and get it into jdk22 asap, as preparation for the upcoming Lilliput. As far as I can tell, this PR is in good shape now. @coleenp and others, what do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1679005209 From mdoerr at openjdk.org Tue Aug 15 14:26:07 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 15 Aug 2023 14:26:07 GMT Subject: RFR: JDK-8314211: Add NativeLibraryUnload event In-Reply-To: References: Message-ID: <4iQS7AvOtj1XvhrrXB0qSsT-ESdEQ6MrFwIuonZEgkk=.57945eb0-51d9-4637-b00f-b67d3dec2c51@github.com> On Mon, 14 Aug 2023 14:51:50 GMT, Matthias Baesken wrote: > [JDK-8313251](https://bugs.openjdk.org/browse/JDK-8313251) introduced a a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. > There should be a similar event for unload operations of shared libs. src/hotspot/os/windows/os_windows.cpp line 1283: > 1281: } else { > 1282: os::snprintf(buf, sizeof(buf), "Attempt to unload dll failed (error code %d)", (int) errcode); > 1283: event.set_errorMessage(buf); Please move replicated line after if-then-else block. Otherwise, good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15272#discussion_r1294665835 From ayang at openjdk.org Tue Aug 15 14:47:29 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 15 Aug 2023 14:47:29 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: Message-ID: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> On Wed, 12 Jul 2023 14:14:46 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > RISCV fixes by @RealYFang src/hotspot/share/oops/arrayOop.hpp line 49: > 47: // Interpreter/Compiler offsets > 48: > 49: public: Could this method be moved next to `length_offset_in_bytes` as they are closely related? (Then, this `public` becomes unneeded.) src/hotspot/share/oops/arrayOop.hpp line 94: > 92: // Returns the offset of the first element. > 93: static int base_offset_in_bytes(BasicType type) { > 94: size_t hs = header_size_in_bytes(); Previously, the memory representation of an array is `[header] + [payload]`. The "header" part includes the necessary alignment gap if any. (IOW, the end of the header and the beginning of the payload is adjacent.) The public API has `header_size(...)` and `base_offset_in_bytes(...)`, which corresponds to the header and payload, respectively. With the new change, the header is *not* word-alignment any more. Could the API (and its impl) be adjusted to maintain the original model `array = [header] + [payload]`. Sth like, `header_size_in_bytes(...)` includes the alignment gap and replaces `header_size` in the public API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1286890020 PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1294691072 From mbaesken at openjdk.org Tue Aug 15 15:33:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 15 Aug 2023 15:33:32 GMT Subject: RFR: JDK-8314211: Add NativeLibraryUnload event [v2] In-Reply-To: References: Message-ID: > [JDK-8313251](https://bugs.openjdk.org/browse/JDK-8313251) introduced a a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. > There should be a similar event for unload operations of shared libs. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Simplify os_windows code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15272/files - new: https://git.openjdk.org/jdk/pull/15272/files/ce607b38..b7557a5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15272&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15272&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15272.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15272/head:pull/15272 PR: https://git.openjdk.org/jdk/pull/15272 From mbaesken at openjdk.org Tue Aug 15 15:33:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 15 Aug 2023 15:33:32 GMT Subject: RFR: JDK-8314211: Add NativeLibraryUnload event [v2] In-Reply-To: <4iQS7AvOtj1XvhrrXB0qSsT-ESdEQ6MrFwIuonZEgkk=.57945eb0-51d9-4637-b00f-b67d3dec2c51@github.com> References: <4iQS7AvOtj1XvhrrXB0qSsT-ESdEQ6MrFwIuonZEgkk=.57945eb0-51d9-4637-b00f-b67d3dec2c51@github.com> Message-ID: On Tue, 15 Aug 2023 14:23:17 GMT, Martin Doerr wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify os_windows code > > src/hotspot/os/windows/os_windows.cpp line 1283: > >> 1281: } else { >> 1282: os::snprintf(buf, sizeof(buf), "Attempt to unload dll failed (error code %d)", (int) errcode); >> 1283: event.set_errorMessage(buf); > > Please move replicated line after if-then-else block. Otherwise, good. Hi Martin, I adjusted the coding you mentioned . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15272#discussion_r1294779751 From rkennke at openjdk.org Tue Aug 15 15:41:29 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 15 Aug 2023 15:41:29 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: On Tue, 15 Aug 2023 14:43:54 GMT, Albert Mingkun Yang wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> RISCV fixes by @RealYFang > > src/hotspot/share/oops/arrayOop.hpp line 94: > >> 92: // Returns the offset of the first element. >> 93: static int base_offset_in_bytes(BasicType type) { >> 94: size_t hs = header_size_in_bytes(); > > Previously, the memory representation of an array is `[header] + [payload]`. The "header" part includes the necessary alignment gap if any. (IOW, the end of the header and the beginning of the payload is adjacent.) The public API has `header_size(...)` and `base_offset_in_bytes(...)`, which corresponds to the header and payload, respectively. > > With the new change, the header is *not* word-alignment any more. Could the API (and its impl) be adjusted to maintain the original model `array = [header] + [payload]`. Sth like, `header_size_in_bytes(...)` includes the alignment gap and replaces `header_size` in the public API. I am not sure what you are asking here. We *do* have header_size_in_bytes(), but its meaning is just the header, without gap (if any). The gap is included in base_offset_in_bytes(), which is the offset at which the payload starts, which seems consistent to other similar methods. We could make header_size_in_bytes() so that it includes the gap, but then 1. it would be the same as base_offset_in_bytes() and 2. we still need 'just the header' in places, so we would have to have another method for that. Also, I am not sure where we would need header_size_in_bytes() with gap, because that's usually the places where base_offset_in_bytes() seems semantically better suited. (Also, note that we still have header_size(BasicType) which returns an word-up-aligned header size which is used by a number of places that require this like minimum and maximum size computations; it's kinda ugly, but having to have to align-up the byte-size in all those places has been ugly as well, I have attempted that in an earlier version of this PR) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1294791277 From ayang at openjdk.org Tue Aug 15 16:21:30 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 15 Aug 2023 16:21:30 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: On Tue, 15 Aug 2023 15:38:09 GMT, Roman Kennke wrote: >> src/hotspot/share/oops/arrayOop.hpp line 94: >> >>> 92: // Returns the offset of the first element. >>> 93: static int base_offset_in_bytes(BasicType type) { >>> 94: size_t hs = header_size_in_bytes(); >> >> Previously, the memory representation of an array is `[header] + [payload]`. The "header" part includes the necessary alignment gap if any. (IOW, the end of the header and the beginning of the payload is adjacent.) The public API has `header_size(...)` and `base_offset_in_bytes(...)`, which corresponds to the header and payload, respectively. >> >> With the new change, the header is *not* word-alignment any more. Could the API (and its impl) be adjusted to maintain the original model `array = [header] + [payload]`. Sth like, `header_size_in_bytes(...)` includes the alignment gap and replaces `header_size` in the public API. > > I am not sure what you are asking here. We *do* have header_size_in_bytes(), but its meaning is just the header, without gap (if any). The gap is included in base_offset_in_bytes(), which is the offset at which the payload starts, which seems consistent to other similar methods. We could make header_size_in_bytes() so that it includes the gap, but then 1. it would be the same as base_offset_in_bytes() and 2. we still need 'just the header' in places, so we would have to have another method for that. Also, I am not sure where we would need header_size_in_bytes() with gap, because that's usually the places where base_offset_in_bytes() seems semantically better suited. > > (Also, note that we still have header_size(BasicType) which returns an word-up-aligned header size which is used by a number of places that require this like minimum and maximum size computations; it's kinda ugly, but having to have to align-up the byte-size in all those places has been ugly as well, I have attempted that in an earlier version of this PR) On master, `header_size` and `base_offset_in_bytes` are two public API; they refer to the header and payload of an array and have the invariant, header-size-in-bytes == base-offset-in-bytes, because `base_offset_in_bytes(...)` is impled as `header_size(...) * HeapWordSize`. With the new change, `header_size` and `base_offset_in_bytes` are still two public API, but the invariant is broken, `header_size(...) * HeapWordSize != base_offset_in_bytes(...)`. I am asking if we can expose `header_size_in_bytes` as the public API so that invariant is kept. > 1. it would be the same as base_offset_in_bytes() True; the impl on master is just a word-to-byte translation. (They being the same is an advantage, reinforcing the invariant, IMO.) > 2. we still need 'just the header' in places Is that a public API? I think the concept of "header" contains everything from array-start to payload-start, from the perspective of users (of this class). > it's kinda ugly, but having to have to align-up the byte-size in all those places has been ugly as well I am more concerned about the fact that the public API `header_size` covers more than the header. Having the header-size aligned up to word-size (or anything) should be sth the caller decides. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1294837287 From rkennke at openjdk.org Tue Aug 15 17:11:29 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 15 Aug 2023 17:11:29 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: On Tue, 15 Aug 2023 16:18:49 GMT, Albert Mingkun Yang wrote: > On master, `header_size` and `base_offset_in_bytes` are two public API; they refer to the header and payload of an array and have the invariant, header-size-in-bytes == base-offset-in-bytes, because `base_offset_in_bytes(...)` is impled as `header_size(...) * HeapWordSize`. > > With the new change, `header_size` and `base_offset_in_bytes` are still two public API, but the invariant is broken, `header_size(...) * HeapWordSize != base_offset_in_bytes(...)`. I am asking if we can expose `header_size_in_bytes` as the public API so that invariant is kept. So you want: static int base_offset_in_bytes() { return header_size_in_bytes(); } ?? Seems like an unnecessary duplication to me. > > 1. it would be the same as base_offset_in_bytes() > > True; the impl on master is just a word-to-byte translation. (They being the same is an advantage, reinforcing the invariant, IMO.) Yes, but that distinction is gone. We shall use only the byte-size version, except for the case where we really want the up-aligned word-sized version (this needs to be used with caution, see below). > > 2. we still need 'just the header' in places > > Is that a public API? I think the concept of "header" contains everything from array-start to payload-start, from the perspective of users (of this class). No. All users are code-generators (except for base_offset_in_bytes() and header_size() which transform the value in their own ways). And we are using the header-size *without* the gap in order to determine if we need an extra store to initialize the gap. E.g.: if (!is_aligned(arrayOopDesc::header_size_in_bytes(), BytesPerWord)) { assert(is_aligned(arrayOopDesc::header_size_in_bytes(), BytesPerInt), "must be 4-byte aligned"); strw(zr, Address(obj, arrayOopDesc::header_size_in_bytes())); } > > it's kinda ugly, but having to have to align-up the byte-size in all those places has been ugly as well > > I am more concerned about the fact that the public API `header_size` covers more than the header. Having the header-size aligned up to word-size (or anything) should be sth the caller decides. Ok I agree. I've done that, and ended up with a dozen (or so) cases which all did the exact same thing. That's why I added back header_size() (I originally removed it) as a helper method for the callers which decided to do that. I'm open to suggestions for improving the situation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1294887659 From rkennke at openjdk.org Tue Aug 15 18:00:15 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 15 Aug 2023 18:00:15 GMT Subject: RFR: 8310031: Parallel: Implement better work distribution for large object arrays in old gen [v3] In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 16:20:13 GMT, Richard Reingruber wrote: >> This pr introduces parallel scanning of large object arrays in the old generation containing roots for young collections of Parallel GC. This allows for better distribution of the actual work (following the array references) as opposed to "stealing" from other task queues which can lead to inverse scaling demonstrated by small tests (attached to JDK-8310031) and also observed in gerrit production systems. >> >> The algorithm to share scanning large arrays is supposed to be a straight >> forward extension of the scheme implemented in >> `PSCardTable::scavenge_contents_parallel`. >> >> - A worker scans the part of a large array located in its stripe >> >> - Except for the end of the large array reaching into a stripe which is scanned by the thread owning the previous stripe. This is just what the current implementation does: it skips objects crossing into the stripe. >> >> - For this it is necessary that large arrays cover at least 3 stripes (see `PSCardTable::large_obj_arr_min_words`) >> >> The implementation also makes use of the precise card marks for arrays. Only dirty regions are actually scanned. >> >> #### Performance testing >> >> ##### BigArrayInOldGenRR.java >> >> [BigArrayInOldGenRR.java](https://bugs.openjdk.org/secure/attachment/104422/BigArrayInOldGenRR.java) is a micro benchmark that assigns new objects to a large array in a loop. Creating new array elements triggers young collections. In each collection the large array is scanned because of its references to the new elements in the young generation. The benchmark score is the geometric mean of the duration of the last 5 young collections (lower is better). >> >> [BigArrayInOldGenRR.pdf](https://cr.openjdk.org/~rrich/webrevs/8310031/BigArrayInOldGenRR.pdf)([BigArrayInOldGenRR.ods](https://cr.openjdk.org/~rrich/webrevs/8310031/BigArrayInOldGenRR.ods)) presents the benchmark results with 1 to 64 gc threads. >> >> Observations >> >> * JDK22 scales inversely. Adding gc threads prolongues young collections. With 32 threads young collections take ~15x longer than single threaded. >> >> * Fixed JDK22 scales well. Adding gc theads reduces the duration of young collections. With 32 threads young collections are 5x shorter than single threaded. >> >> * With just 1 gc thread there is a regression. Young collections are 1.5x longer with the fix. I assume the reason is that the iteration over the array elements is interrupted at the end of a stripe which makes it less efficient. The prize for parallelization is paid ... > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Limit effect of previous commit to large array handling Nice change! Cursory review found a misplaced (I think) method impl. src/hotspot/share/oops/objArrayKlass.inline.hpp line 121: > 119: } > 120: > 121: template It looks to me like this implementation is misplaced, I believe it should reside in objArrayOop.inline.hpp. ------------- Changes requested by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14846#pullrequestreview-1579093956 PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1294927119 From mdoerr at openjdk.org Tue Aug 15 19:16:09 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 15 Aug 2023 19:16:09 GMT Subject: RFR: JDK-8314211: Add NativeLibraryUnload event [v2] In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 15:33:32 GMT, Matthias Baesken wrote: >> [JDK-8313251](https://bugs.openjdk.org/browse/JDK-8313251) introduced a a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. >> There should be a similar event for unload operations of shared libs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify os_windows code LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15272#pullrequestreview-1579248060 From rkennke at openjdk.org Tue Aug 15 21:03:13 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 15 Aug 2023 21:03:13 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v17] In-Reply-To: References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: On Fri, 23 Jun 2023 02:31:11 GMT, Julian Waters wrote: >> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)). >> >> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used. >> >> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right >> >> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446)) > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'openjdk:master' into alignas > - Merge branch 'master' into alignas > - Merge branch 'openjdk:master' into alignas > - alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - ... and 7 more: https://git.openjdk.org/jdk/compare/5a82fa3b...bb9ae391 This looks reasonable to me. Would be good to phase out the actual macro uses as well, in the future. Also, would be great to be able to use offsetof() instead of offset_of() whereever this is possible. ------------- Marked as reviewed by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/11431#pullrequestreview-1579424138 From lmesnik at openjdk.org Wed Aug 16 00:19:15 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 16 Aug 2023 00:19:15 GMT Subject: Integrated: 8314242: Update applications/scimark/Scimark.java to accept VM flags In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 22:19:24 GMT, Leonid Mesnik wrote: > Test applications/scimark/Scimark.java is a small stress test which currently ignores VM flags and is vm.flagless. > This fix update it to accept all flags. > > Tested by running tier1 and this test with additional VM flags. This pull request has now been integrated. Changeset: 6bf4a335 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/6bf4a33593bfe0df9b5ba81de5321a04f4dbe0ea Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod 8314242: Update applications/scimark/Scimark.java to accept VM flags Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/15280 From rkennke at openjdk.org Wed Aug 16 01:03:11 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 16 Aug 2023 01:03:11 GMT Subject: RFR: 8310160: Make GC APIs for handling archive heap objects agnostic of GC policy [v2] In-Reply-To: References: Message-ID: On Wed, 26 Jul 2023 04:28:25 GMT, Ioi Lam wrote: >> @iklam I agree this is a much better approach and makes the whole process truly collector agnostic. Great work, specially the optimization to re-order the objects. >> >> Given that this has minimal impact on performance, are we good to go ahead with this approach now? >> >> One issue I noticed while doing some testing with Shenandoah collector is probably worth pointing out here: >> When using `-XX:+NahlRawAlloc` with very small heap size like -Xmx4m or -Xmx8m the java process freezes. . This happens because the allocations for archive objects causes pacing to kick in and the main thread waits on `ShenandoahPacer::_wait_monitor` [0] to be notified by ShenandoahPeriodicPacerNotify [1]. But the WatcherThread which is responsible for executing the `ShenandoahPeriodicPacerNotify` task does run the periodic tasks until VM init is done [2][3]. So the main thread is stuck now. >> >> I guess if we do the wait in `ShenandoahPacer::pace_for_alloc` only after VM init is completed, it would resolve this issue. >> >> I haven't noticed this with `-XX:-NahlRawAlloc`, not sure why that should make any difference. >> >> Here are the stack traces: >> >> main thread: >> >> #5 0x00007f5a1fafbafc in PlatformMonitor::wait (this=this at entry=0x7f5a180f6c78, millis=, millis at entry=10) at src/hotspot/os/posix/mutex_posix.hpp:124 >> #6 0x00007f5a1faa3f9c in Monitor::wait (this=0x7f5a180f6c70, timeout=timeout at entry=10) at src/hotspot/share/runtime/mutex.cpp:254 >> #7 0x00007f5a1fc2d3bd in ShenandoahPacer::wait (time_ms=10, this=0x7f5a180f6a20) at src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp:286 >> #8 ShenandoahPacer::pace_for_alloc (this=0x7f5a180f6a20, words=) at src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp:263 >> #9 0x00007f5a1fbfc7e1 in ShenandoahHeap::allocate_memory (this=0x7f5a180ca590, req=...) at src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:855 >> #10 0x00007f5a1fbfcb5c in ShenandoahHeap::mem_allocate (this=, size=, gc_overhead_limit_was_exceeded=) at src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:931 >> #11 0x00007f5a1f2402c2 in NewQuickLoader::mem_allocate_raw (size=6) at src/hotspot/share/cds/archiveHeapLoader.cpp:493 >> #12 NewQuickLoaderImpl::allocate (this=, __the_thread__=, size=: 6, stream=0x7f5a1d228850) at src/hotspot/share/cds/archiveHeapLoader.cpp:712 >> #13 NewQuickLoaderImpl::load_archive_heap_inner > Hi @ashu-mehra thanks for testing the patch. I think we all agree that the minor performance impact is acceptable because the code is simpler and more portable. I'll try to clean up my patch and start a PR. > > BTW, I have implemented a simpler relocation algorithm with similar performance. It uses less memory and hopefully will be easier to understand as well. The algorithm is described in comments inside archiveHeapLoader.cpp > > https://github.com/openjdk/jdk/compare/master...iklam:jdk:8310823-materialize-cds-heap-with-regular-alloc.alternative-relocation?expand=1 > > As a prerequisite, I'll start a PR for [JDK-8251330: Reorder CDS archived heap to speed up relocation](https://bugs.openjdk.org/browse/JDK-8251330) > > Regarding raw allocation, it doesn't seem to be too much faster, so maybe we should disable it, at least for the initial integration. > > > $ (for i in {1..6}; do perf stat -r 100 java -XX:+NewArchiveHeapLoading -XX:-NahlRawAlloc --version > /dev/null; done) 2>&1 | grep elapsed > 0.0162332 +- 0.0000914 seconds time elapsed ( +- 0.56% ) > 0.0161316 +- 0.0000228 seconds time elapsed ( +- 0.14% ) > 0.0161171 +- 0.0000250 seconds time elapsed ( +- 0.16% ) > 0.0161311 +- 0.0000231 seconds time elapsed ( +- 0.14% ) > 0.0161433 +- 0.0000244 seconds time elapsed ( +- 0.15% ) > 0.0161121 +- 0.0000271 seconds time elapsed ( +- 0.17% ) > $ (for i in {1..6}; do perf stat -r 100 java -XX:+NewArchiveHeapLoading -XX:+NahlRawAlloc --version > /dev/null; done) 2>&1 | grep elapsed > 0.0160640 +- 0.0000973 seconds time elapsed ( +- 0.61% ) > 0.0159320 +- 0.0000221 seconds time elapsed ( +- 0.14% ) > 0.0159910 +- 0.0000272 seconds time elapsed ( +- 0.17% ) > 0.0159406 +- 0.0000230 seconds time elapsed ( +- 0.14% ) > 0.0159930 +- 0.0000252 seconds time elapsed ( +- 0.16% ) > 0.0159670 +- 0.0000296 seconds time elapsed ( +- 0.19% ) > $ (for i in {1..6}; do perf stat -r 100 java -XX:-NewArchiveHeapLoading -XX:+NahlRawAlloc --version > /dev/null; done) 2>&1 | grep elapsed > 0.0149069 +- 0.0000932 seconds time elapsed ( +- 0.63% ) > 0.0148363 +- 0.0000259 seconds time elapsed ( +- 0.17% ) > 0.0148077 +- 0.0000218 seconds time elapsed ( +- 0.15% ) > 0.0148377 +- 0.0000212 seconds time elapsed ( +- 0.14% ) > 0.0148411 +- 0.0000245 seconds time elapsed ( +- 0.17% ) > 0.0148504 +- 0.0000258 seconds time elapsed ( +- 0.17% ) > @iklam I agree this is a much better approach and makes the whole process truly collector agnostic. Great work, specially the optimization to re-order the objects. > > Given that this has minimal impact on performance, are we good to go ahead with this approach now? > > One issue I noticed while doing some testing with Shenandoah collector is probably worth pointing out here: When using `-XX:+NahlRawAlloc` with very small heap size like -Xmx4m or -Xmx8m the java process freezes. . This happens because the allocations for archive objects causes pacing to kick in and the main thread waits on `ShenandoahPacer::_wait_monitor` [0] to be notified by ShenandoahPeriodicPacerNotify [1]. But the WatcherThread which is responsible for executing the `ShenandoahPeriodicPacerNotify` task does run the periodic tasks until VM init is done [2][3]. So the main thread is stuck now. > > I guess if we do the wait in `ShenandoahPacer::pace_for_alloc` only after VM init is completed, it would resolve this issue. Yes, Shenandoah pacing should not run before VM init is complete. This seems like a separate issue. Great work in this PR, though! Roman ------------- PR Comment: https://git.openjdk.org/jdk/pull/14520#issuecomment-1679817438 From haosun at openjdk.org Wed Aug 16 01:53:35 2023 From: haosun at openjdk.org (Hao Sun) Date: Wed, 16 Aug 2023 01:53:35 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v3] In-Reply-To: <65av8Ef3RPpFqINe_AoPfsagdbmp0Kbc0TBPCVClYxY=.d87d3c24-d3fb-4469-89a8-281a2109140e@github.com> References: <65av8Ef3RPpFqINe_AoPfsagdbmp0Kbc0TBPCVClYxY=.d87d3c24-d3fb-4469-89a8-281a2109140e@github.com> Message-ID: On Tue, 15 Aug 2023 11:14:54 GMT, Andrew Haley wrote: >> Hao Sun has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Remove my temp test patch on jvmci_global.hpp and stubGenerator_aarch64.hpp >> - Use relative SP as the PAC modifier >> - Merge branch 'master' into jdk-8287325 >> - Merge branch 'master' into jdk-8287325 >> - Rename return_pc_at and patch_pc_at >> >> Rename return_pc_at to return_address_at. >> Rename patch_pc_at to patch_return_address_at. >> - 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret >> >> * Background >> >> 1. PAC-RET branch protection was initially implemented on Linux/AArch64 >> in JDK-8277204 [1]. >> >> 2. However, it was broken with the introduction of virtual threads [2], >> mainly because the continuation freeze/thaw mechanism would trigger >> stack copying to/from memory, whereas the saved and signed LR on the >> stack doesn't get re-signed accordingly. >> >> 3. PR-9067 [3] tried to implement the re-sign part, but it was not >> accepted because option "PreserveFramePointer" is always turned on by >> PAC-RET but this would slow down virtual threads by ~5-20x. >> >> 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview >> language features are enabled. Note that virtual thread is one preview >> feature then. >> >> 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. >> >> * Goal >> >> This patch aims to make PAC-RET compatible with virtual threads. >> >> * Requirements of virtual threads >> >> R-1: Option "PreserveFramePointer" should be turned off. That is, >> PAC-RET implementation should not rely on frame pointer FP. Otherwise, >> the fast path in stack copying will never be taken. >> >> R-2: Use some invariant values to stack copying as the modifier, so as >> to avoid the PAC re-sign for continuation thaw, as the fast path in >> stack copying doesn't walk the frame. >> >> Note that more details can be found in the discussion [3]. >> >> * Investigation >> >> We considered to use (relative) stack pointer SP, thread ID, PACStack >> [7] and value zero as the candidate modifier. >> >> 1. SP: In some scenarios, we need to authenticate the return address in >> places where the current SP doesn't match the SP on function entry. E.g. >> see the usage in Runtime1::generate_handle_exception(). Hence, neither >> absolute nor relative SP works. >>... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6002: > >> 6000: pacia(lr, rscratch1); >> 6001: ldp(rscratch1, zr, Address(post(sp, 2 * wordSize))); >> 6002: } > > Suggestion: > > ldr(lr, Address(thread, JavaThread::cont_entry_offset())); > sub(lr, sp, lr); > pacia(lr, lr); > } > > Maybe? I'm afraid not. In this way, the original value of `lr` would be overwritten before `pacia` instruction, and we turn to protect `relative SP` with `relative SP` as the modifier, rather than protecting `lr` with `relative SP` as the modifier. We may get some basics of `ARM pauth` from this slides, https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf For simplicity, we can view the process of "PAC signing" and "PAC authentication" as the **generation** and **verification** of the **PAC code** (something like one hash code). For PAC generation, three inputs are taken in - the pointer to protection, i.e. LR in our context - one key, which is maintained by the underlying kernel - context, i.e. the modifier. we can use any value in theory, like constants, zero, some runtime values(SP, FP, thread id etc) In our context, after `pacia` instruction, the LR under protection would turn to be "PAC code + LR", where the generated PAC code is put at the higher N bits and the lower 48 bit is still the original LR. Hence, the PACed LR cannot be accessed directly, until the corresponding authentication is conducted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13322#discussion_r1295301014 From jwaters at openjdk.org Wed Aug 16 02:21:51 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 16 Aug 2023 02:21:51 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v5] In-Reply-To: References: Message-ID: > Fix several formatting errors on Windows Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Remove whitespace - Revert changes of INTPTR_FORMAT, minor improvements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15063/files - new: https://git.openjdk.org/jdk/pull/15063/files/ddf2f723..9402a57c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=03-04 Stats: 29 lines in 5 files changed: 0 ins; 0 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/15063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15063/head:pull/15063 PR: https://git.openjdk.org/jdk/pull/15063 From mbaesken at openjdk.org Wed Aug 16 07:42:16 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 16 Aug 2023 07:42:16 GMT Subject: RFR: JDK-8314211: Add NativeLibraryUnload event [v2] In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 15:33:32 GMT, Matthias Baesken wrote: >> [JDK-8313251](https://bugs.openjdk.org/browse/JDK-8313251) introduced a a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. >> There should be a similar event for unload operations of shared libs. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify os_windows code Hi Martin, thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15272#issuecomment-1680114908 From mbaesken at openjdk.org Wed Aug 16 07:42:17 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 16 Aug 2023 07:42:17 GMT Subject: Integrated: JDK-8314211: Add NativeLibraryUnload event In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 14:51:50 GMT, Matthias Baesken wrote: > [JDK-8313251](https://bugs.openjdk.org/browse/JDK-8313251) introduced a a NativeLibraryLoad event that provides us more detail about shared lib/dll loads. > There should be a similar event for unload operations of shared libs. This pull request has now been integrated. Changeset: ef6db5c2 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/ef6db5c2991b92e2a600fa01d1d3f5026055ad17 Stats: 64 lines in 7 files changed: 62 ins; 0 del; 2 mod 8314211: Add NativeLibraryUnload event Reviewed-by: stuefe, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/15272 From stefank at openjdk.org Wed Aug 16 08:03:16 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 16 Aug 2023 08:03:16 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v5] In-Reply-To: References: Message-ID: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com> On Wed, 16 Aug 2023 02:21:51 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has updated the pull request incrementally with two additional commits since the last revision: > > - Remove whitespace > - Revert changes of INTPTR_FORMAT, minor improvements Changes requested by stefank (Reviewer). src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 267: > 265: > 266: if (!res) { > 267: fatal_error("Failed to split placeholder", static_cast(addr), size); Suggestion: fatal_error("Failed to split placeholder", untype(addr), size); src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp line 202: > 200: if (!res) { > 201: fatal("Failed to unmap view " PTR_FORMAT " " SIZE_FORMAT "M (%ld)", > 202: static_cast(addr), size / M, GetLastError()); Suggestion: untype(addr), size / M, GetLastError()); src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp line 242: > 240: void ZPhysicalMemoryBacking::map(zaddress_unsafe addr, size_t size, zoffset offset) const { > 241: assert(is_aligned(untype(offset), ZGranuleSize), "Misaligned: " PTR_FORMAT, untype(offset)); > 242: assert(is_aligned(untype(addr), ZGranuleSize), "Misaligned: " PTR_FORMAT, static_cast(addr)); Suggestion: assert(is_aligned(untype(addr), ZGranuleSize), "Misaligned: " PTR_FORMAT, untype(addr)); ------------- PR Review: https://git.openjdk.org/jdk/pull/15063#pullrequestreview-1580009829 PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1295515784 PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1295516066 PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1295516411 From epeter at openjdk.org Wed Aug 16 08:09:27 2023 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 16 Aug 2023 08:09:27 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v33] In-Reply-To: References: <87ecc9JR1ie1bGLibg22j-nFA4KZjlpLWqZSZgFjuRA=.a6b7e527-c6be-47cd-b8c6-61cf51994cbf@github.com> Message-ID: On Tue, 15 Aug 2023 14:14:01 GMT, Roman Kennke wrote: >> I was looking at this again, and my review is NOT a full review. I only reviewed the metadata changes. > > I think it'd be a good time to move this forward and get it into jdk22 asap, as preparation for the upcoming Lilliput. As far as I can tell, this PR is in good shape now. @coleenp and others, what do you think? @rkennke I have not yet had a chance to look at the code in detail here. But I have a more general concern. In SuperWord, we auto-vectorize loops over arrays. In some conditions, we want to have the vector loads/stores aligned. On some machines this is done mostly for performance (e.g. cache line alignment). On other machines, this is a strict requirement (otherwise we either get a SIGBUS or wrong results). The flag `-XX:+AlignVector` can be set to force this strict alignment, and some platforms have it always enabled, see `Matcher::misaligned_vectors_ok() = false`. The current alignment logic in SuperWord is subtly broken, and I am working on a fix [JDK-8310190](https://bugs.openjdk.org/browse/JDK-8310190). But what I know is that we do the alignment checks statically, assuming that the array base is aligned. I think the assumption is that it is aligned with `ObjectAlignmentInBytes = 8` bytes. See for example in `SuperWord::align_initial_loop_index`: https://github.com/openjdk/jdk/blob/d46f0fb31888db75f5b2b78a162fec16dfc5d0d9/src/hotspot/share/opto/superword.cpp#L3736-L3738 Some platforms need 4 byte or 8 byte alignment: https://github.com/openjdk/jdk/blob/d46f0fb31888db75f5b2b78a162fec16dfc5d0d9/src/hotspot/cpu/ppc/matcher_ppc.hpp#L40-L44 As far as I understand, some (if not all arm32) require 8 byte alignment (@fg1417 is this correct?). https://github.com/openjdk/jdk/blob/d46f0fb31888db75f5b2b78a162fec16dfc5d0d9/src/hotspot/cpu/arm/matcher_arm.hpp#L40-L43 The alignment checks are performed statically, by analyzing the pointer of the memory load/store into this form: https://github.com/openjdk/jdk/blob/d46f0fb31888db75f5b2b78a162fec16dfc5d0d9/src/hotspot/share/opto/superword.cpp#L785 As far as I understand, the `base` is always assumed to be aligned. We only check that adding the other components to the base would keep the address aligned. Hence this change here makes me a bit nervous. The problem is that we currently do not have very good tests. I'm working on improving tests and verification with [JDK-8310190](https://bugs.openjdk.org/browse/JDK-8310190). Are you aware of the possible impact on SuperWord alignment? Maybe it is really only going to be an issue on arm32. What do you think @fg1417 ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1680149988 From fbredberg at openjdk.org Wed Aug 16 08:20:14 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 16 Aug 2023 08:20:14 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 17:01:11 GMT, Andrew Haley wrote: > > I think you need to correct `frame::describe` to make it print the relativized SP in an easy-to-understand form. > > Ping. I looked into frame::describe and I realized that it already contained code to deal with relativized values (by @AlanBateman and adopted to PowerPC by @reinrich). It works like this: If a member of the fixed frame is on the heap and has a value between -99 to 99 it's value will be printed as a signed integer instead of a hexadecimal value. I think the basic thought is something like this: Members of the fixed frame are pointers and therefore don't hold values [-99..99], but if they do, they are probably relativized values so they should be printed as integers. And they should be interpreted as pointing to a stack index relative to the frame pointer. Up until I started to change fixed frame pointers so that they are permanently relativized (JDK-8289296), the relativized pointers only occurred on the heap (after a freeze). Henze the on_heap condition. ??????if (on_heap ?????? && *fv.location != 0 && *fv.location > -100 && *fv.location < 100 I decided to go with the prior art of Alan and Richard, but since the relativized values can now appear both on the stack and on the heap I removed the on_heap condition. I've tested the output on several platforms, and the output seems ok to me. Does this answer your "Ping" @theRealAph? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1680164503 From rrich at openjdk.org Wed Aug 16 08:31:10 2023 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 16 Aug 2023 08:31:10 GMT Subject: RFR: 8310031: Parallel: Implement better work distribution for large object arrays in old gen [v3] In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 17:51:25 GMT, Roman Kennke wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Limit effect of previous commit to large array handling > > src/hotspot/share/oops/objArrayKlass.inline.hpp line 121: > >> 119: } >> 120: >> 121: template > > It looks to me like this implementation is misplaced, I believe it should reside in objArrayOop.inline.hpp. Indeed, nice catch! I'll fix it asap when back. And thanks for looking at the change! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1295557447 From rrich at openjdk.org Wed Aug 16 08:39:16 2023 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 16 Aug 2023 08:39:16 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v3] In-Reply-To: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> References: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> Message-ID: On Tue, 15 Aug 2023 12:01:41 GMT, Fredrik Bredberg wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Removed the on_heap parameter from FrameValues::print_on Wouldn't it be good to print derelativized pointers for frames on stack? Maybe print both? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1680194243 From aph at openjdk.org Wed Aug 16 09:23:12 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Aug 2023 09:23:12 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 08:15:11 GMT, Fredrik Bredberg wrote: > I looked into frame::describe and I realized that it already contained code to deal with relativized values (by @AlanBateman and adopted to PowerPC by @reinrich). It works like this: If a member of the fixed frame is on the heap and has a value between -99 to 99 it's value will be printed as a signed integer instead of a hexadecimal value. Sure, but we need to see what they point to. In other words, every relativized point should be _decoded_ into its pointer form. Otherwise relativization, a good thing, becomes obfuscation, a bad thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1680258169 From ayang at openjdk.org Wed Aug 16 09:43:28 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 16 Aug 2023 09:43:28 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: On Tue, 15 Aug 2023 17:08:17 GMT, Roman Kennke wrote: > And we are using the header-size without the gap in order to determine if we need an extra store to initialize the gap. E.g.: I suspect the store to the gap is related to the following comment/diff: // We align-up the header size to word-size, because we clear the // possible alignment gap in initialize_header(). int hdr_size = align_up(base_offset_in_bytes, BytesPerWord); initialize_body(obj, arr_size, hdr_size, len_zero); Wonder if sth like `initialize_body(obj, arr_size, base_offset_in_bytes, len_zero);` can make the header/body classification more explicit. Ofc, `zero_memory` needs to be extended somehow to support non-word-align start-addr. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1295643550 From coleenp at openjdk.org Wed Aug 16 11:49:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 11:49:20 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code In-Reply-To: References: Message-ID: On Thu, 10 Aug 2023 20:31:20 GMT, Coleen Phillimore wrote: > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. src/hotspot/share/utilities/elfFile.cpp line 1426: > 1424: return false; > 1425: } > 1426: _state->_discriminator = static_cast(discriminator); @chhagedorn These fields are declared as 32 bits but are read out of the dwarf info as 64 bits. Should they be 64 bits? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1295772547 From coleenp at openjdk.org Wed Aug 16 12:04:41 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 12:04:41 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v2] In-Reply-To: References: Message-ID: > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Make elf fields 64 bits removing some static casts. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15233/files - new: https://git.openjdk.org/jdk/pull/15233/files/e6458796..4b8799ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=00-01 Stats: 17 lines in 2 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/15233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15233/head:pull/15233 PR: https://git.openjdk.org/jdk/pull/15233 From chagedorn at openjdk.org Wed Aug 16 12:25:12 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 16 Aug 2023 12:25:12 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v2] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 11:45:54 GMT, Coleen Phillimore wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make elf fields 64 bits removing some static casts. > > src/hotspot/share/utilities/elfFile.cpp line 1426: > >> 1424: return false; >> 1425: } >> 1426: _state->_discriminator = static_cast(discriminator); > > @chhagedorn These fields are declared as 32 bits but are read out of the dwarf info as 64 bits. Should they be 64 bits? I just made them 64 bits. According to the DWARF 4 spec, the discriminator is an unsigned integer (i.e. 32 bits). Also, the other fields like `isa or `column` are unsigned integer. I think we would be good to keep them as unsigned integer to follow the spec. `read_uleb128()` reads up to 8 bytes and just returns the result in a `uint64_t`. But sometimes, it should only read 1, 2, or 4 bytes. In that case, we additionally specify `check_size` to ensure that we can safely cast it. I guess we could change these calls to `read_uleb128()` to return a more precise type instead of relying on `check_size` passed in by a caller + casting the result in the caller. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1295814369 From coleenp at openjdk.org Wed Aug 16 12:33:21 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 12:33:21 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v2] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 12:22:15 GMT, Christian Hagedorn wrote: >> src/hotspot/share/utilities/elfFile.cpp line 1426: >> >>> 1424: return false; >>> 1425: } >>> 1426: _state->_discriminator = static_cast(discriminator); >> >> @chhagedorn These fields are declared as 32 bits but are read out of the dwarf info as 64 bits. Should they be 64 bits? I just made them 64 bits. > > According to the DWARF 4 spec, the discriminator is an unsigned integer (i.e. 32 bits). Also, the other fields like `isa or `column` are unsigned integer. I think we would be good to keep them as unsigned integer to follow the spec. > > `read_uleb128()` reads up to 8 bytes and just returns the result in a `uint64_t`. But sometimes, it should only read 1, 2, or 4 bytes. In that case, we additionally specify `check_size` to ensure that we can safely cast it. I guess we could change these calls to `read_uleb128()` to return a more precise type instead of relying on `check_size` passed in by a caller + casting the result in the caller. When we read the 64 bit values in the code, the values are 64 bits though. So static_cast<> to narrow the result is more correct ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1295823096 From coleenp at openjdk.org Wed Aug 16 12:36:09 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 12:36:09 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v2] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 12:30:18 GMT, Coleen Phillimore wrote: >> According to the DWARF 4 spec, the discriminator is an unsigned integer (i.e. 32 bits). Also, the other fields like `isa or `column` are unsigned integer. I think we would be good to keep them as unsigned integer to follow the spec. >> >> `read_uleb128()` reads up to 8 bytes and just returns the result in a `uint64_t`. But sometimes, it should only read 1, 2, or 4 bytes. In that case, we additionally specify `check_size` to ensure that we can safely cast it. I guess we could change these calls to `read_uleb128()` to return a more precise type instead of relying on `check_size` passed in by a caller + casting the result in the caller. > > When we read the 64 bit values in the code, the values are 64 bits though. So static_cast<> to narrow the result is more correct ? This code: uint64_t isa; if (!_reader.read_uleb128(&isa, 4)) { // isa register is 4 bytes wide. return false; } _state->_isa = isa; // only save 4 bytes returns 64 bit of information into isa from this read_uleb128 call, even though it passes 4. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1295827701 From chagedorn at openjdk.org Wed Aug 16 13:05:17 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 16 Aug 2023 13:05:17 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v2] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 12:33:47 GMT, Coleen Phillimore wrote: >> When we read the 64 bit values in the code, the values are 64 bits though. So static_cast<> to narrow the result is more correct ? > > This code: > > uint64_t isa; > if (!_reader.read_uleb128(&isa, 4)) { > // isa register is 4 bytes wide. > return false; > } > _state->_isa = isa; // only save 4 bytes > > returns 64 bit of information into isa from this read_uleb128 call, even though it passes 4. I've quickly skimmed through the usages of `read_uleb128`. We only seem to be reading either directly into a proper `uint64_t` or we are reading 4 bytes (i.e. `check_size = 4`). In the latter case, we could either: - add a `static_cast` for the read value when storing it into a 32 bit field, as for example for `isa` above (i.e. `_state->_isa = static_cast(isa)`). - provide a 32 bit `read_uleb128()` version that hides the casting. I guess it's fine to just go with a `static_cast` when storing to a field for the few cases we have. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1295863147 From coleenp at openjdk.org Wed Aug 16 13:48:35 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 13:48:35 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v3] In-Reply-To: References: Message-ID: > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Revert to use static_cast. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15233/files - new: https://git.openjdk.org/jdk/pull/15233/files/4b8799ed..4ac4bf47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=01-02 Stats: 17 lines in 2 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/15233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15233/head:pull/15233 PR: https://git.openjdk.org/jdk/pull/15233 From coleenp at openjdk.org Wed Aug 16 13:48:36 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 13:48:36 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v3] In-Reply-To: References: Message-ID: <59x-5y2rJqnSYlnLX_tgEIxkWi-1jFYe8V7g6Qj85VI=.79443604-6856-4d14-b0bc-c7c3312116d3@github.com> On Wed, 16 Aug 2023 13:01:53 GMT, Christian Hagedorn wrote: >> This code: >> >> uint64_t isa; >> if (!_reader.read_uleb128(&isa, 4)) { >> // isa register is 4 bytes wide. >> return false; >> } >> _state->_isa = isa; // only save 4 bytes >> >> returns 64 bit of information into isa from this read_uleb128 call, even though it passes 4. > > I've quickly skimmed through the usages of `read_uleb128`. We only seem to be reading either directly into a proper `uint64_t` or we are reading 4 bytes (i.e. `check_size = 4`). In the latter case, we could either: > - add a `static_cast` for the read value when storing it into a 32 bit field, as for example for `isa` above (i.e. `_state->_isa = static_cast(isa)`). > - provide a 32 bit `read_uleb128()` version that hides the casting. > > I guess it's fine to just go with a `static_cast` when storing to a field for the few cases we have. Thanks Christian. I'll revert to use the static cast. One of the cases has a comment why. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1295937366 From jsjolen at openjdk.org Wed Aug 16 13:49:33 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 16 Aug 2023 13:49:33 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v3] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 13:48:35 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Revert to use static_cast. The NMT changes looks good! ------------- PR Review: https://git.openjdk.org/jdk/pull/15233#pullrequestreview-1580675909 From iwalulya at openjdk.org Wed Aug 16 15:56:39 2023 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 16 Aug 2023 15:56:39 GMT Subject: RFR: 8314406: Provide a shared doubly LinkedList implementation Message-ID: Hi all, Please review this refactoring change to move the ZGC ZList to utilities. Mainly code motion with addition of the necessary tests. Another notable change is allowing the List elements to exist in multiple lists at the same time. Testing: - Linux x86_64 fastdebug `gtest:all`. - Mach5 GTestWrapper Thanks! ------------- Commit messages: - Add tests Changes: https://git.openjdk.org/jdk/pull/15312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314406 Stats: 697 lines in 3 files changed: 697 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15312/head:pull/15312 PR: https://git.openjdk.org/jdk/pull/15312 From rkennke at openjdk.org Wed Aug 16 16:18:28 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 16 Aug 2023 16:18:28 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: On Wed, 16 Aug 2023 09:40:39 GMT, Albert Mingkun Yang wrote: > > And we are using the header-size without the gap in order to determine if we need an extra store to initialize the gap. E.g.: > > I suspect the store to the gap is related to the following comment/diff: > > ``` > // We align-up the header size to word-size, because we clear the > // possible alignment gap in initialize_header(). > int hdr_size = align_up(base_offset_in_bytes, BytesPerWord); > initialize_body(obj, arr_size, hdr_size, len_zero); > ``` > > Wonder if sth like `initialize_body(obj, arr_size, base_offset_in_bytes, len_zero);` can make the header/body classification more explicit. Ofc, `zero_memory` needs to be extended somehow to support non-word-align start-addr. I did that in an earlier version of this PR and it looked quite messy (you can see it if you go back in the commit history. The trouble is that the loops that zero the body are optimized to work on 8-byte-word units, so we would have to check if the body is aligned or not, and if not, add an extra store. I thought it was easier to just add that store in the header zeroing routine. This is also consistent with how we store the klass-gap in instance objects there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1296147786 From rkennke at openjdk.org Wed Aug 16 16:23:31 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 16 Aug 2023 16:23:31 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v33] In-Reply-To: References: <87ecc9JR1ie1bGLibg22j-nFA4KZjlpLWqZSZgFjuRA=.a6b7e527-c6be-47cd-b8c6-61cf51994cbf@github.com> Message-ID: On Tue, 15 Aug 2023 14:14:01 GMT, Roman Kennke wrote: >> I was looking at this again, and my review is NOT a full review. I only reviewed the metadata changes. > > I think it'd be a good time to move this forward and get it into jdk22 asap, as preparation for the upcoming Lilliput. As far as I can tell, this PR is in good shape now. @coleenp and others, what do you think? > @rkennke I have not yet had a chance to look at the code in detail here. But have you considered the impact on SuperWord yet? > > First about terminology. In SuperWord, we talk about the `base`, which is the beginning of the array object, but not where the first entry starts (at some "base" = `base + offset`). You (or at least the title of the RFE) seem to call the "base" where the first entry starts. > > I see that with `-XX:-UseCompressedClassPointers`, before we used to have: > > ``` > UNSAFE.ARRAY_BYTE_BASE_OFFSET: 24 > UNSAFE.ARRAY_SHORT_BASE_OFFSET: 24 > UNSAFE.ARRAY_INT_BASE_OFFSET: 24 > UNSAFE.ARRAY_LONG_BASE_OFFSET: 24 > ``` > > and now have: > > ``` > UNSAFE.ARRAY_BYTE_BASE_OFFSET: 20 > UNSAFE.ARRAY_SHORT_BASE_OFFSET: 20 > UNSAFE.ARRAY_INT_BASE_OFFSET: 20 > UNSAFE.ARRAY_LONG_BASE_OFFSET: 24 > ``` > > I looked at a simple byte array loop. And I do see that without this patch, the memref has an `offset = 24`, and with you patch a `offset = 20`. So to me that means that SuperWord gets the correct information, and can do the alignment checks with this correct information. > > At first the title had me worried, because in SuperWord we do assume that the `base` is aligned, and the title here suggests that you are about to break that. But as mentioned above `base` != "base". > > Still, there may be some subtle alignment differences now. The offsets are moved by 4 bytes for some types. That could have some impact on what vectorizes when `-XX:+AlignVector` or on platforms where `Matcher::misaligned_vectors_ok() = false`. But that is probably not bad enough to block this change here. What do you think @fg1417 @vnkozlov ? Thanks Emanuel, for checking how this PR affects superword opts. I have checked that superficially earlier, but not in such depth. Do you have any tests or benchmarks which you can recommend which exercise these sort of optimizations and which may give some insight on the performance impact (if any)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1680909105 From jvernee at openjdk.org Wed Aug 16 18:18:46 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 16 Aug 2023 18:18:46 GMT Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v5] In-Reply-To: References: Message-ID: > This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'master' into JEP22 - remove spurious imports - enable fallback linker on linux x86 in GHA - make Arena::allocate abstract - 8313894: Rename isTrivial linker option to critical Reviewed-by: pminborg, mcimadamore - 8313680: Disallow combining caputreCallState with isTrivial Reviewed-by: mcimadamore - Merge branch 'master' into JEP22 - use immutable map for fallback linker canonical layouts - 8313265: Move the FFM API out of preview Reviewed-by: mcimadamore - 8313005: Ensure native access check can fold away Reviewed-by: mcimadamore - ... and 11 more: https://git.openjdk.org/jdk/compare/6b396da2...5352dc0f ------------- Changes: https://git.openjdk.org/jdk/pull/15103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=04 Stats: 2834 lines in 232 files changed: 1245 ins; 901 del; 688 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103 From ayang at openjdk.org Wed Aug 16 18:28:28 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 16 Aug 2023 18:28:28 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: On Wed, 16 Aug 2023 16:15:16 GMT, Roman Kennke wrote: > I did that in an earlier version of this PR and it looked quite messy ... I just checked the first commit and the `MacroAssembler` part matches what I have in mind. I believe that diff being messy is due to "Calculations of min and max array and tlab sizes". > so we would have to check if the body is aligned or not, and if not, add an extra store The store, as I understand it, belongs to the body (payload) semantically. Mixing stores btw `initialize_header` and `initialize_body` is super confusing, IMO. > This is also consistent with how we store the klass-gap in instance objects there. klass-gap is part of the header, so it makes sense to be in `initialize_header`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1296283275 From stuefe at openjdk.org Wed Aug 16 18:55:11 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 16 Aug 2023 18:55:11 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v3] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 13:48:35 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Revert to use static_cast. Hi Coleen, looked at metaspace- and NMT- changes and gave the rest a cursory glance. Did not find anything to complain. Thanks for your work! Cheers, Thomas src/hotspot/share/logging/logOutput.cpp line 77: > 75: ntags++; > 76: } > 77: qsort(tags, ntags, sizeof(*tags), (_sort_Fn)tag_cmp); While wondering about, then searching for, _sort_Fn, I found it in globalDefinitions.hpp and a wrong comment in instanceKlass.cpp 1781: // _sort_Fn is defined in growableArray.hpp. would you mind fixing that comment or removing it? ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15233#pullrequestreview-1581233101 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296307276 From coleenp at openjdk.org Wed Aug 16 19:16:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 19:16:28 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v4] In-Reply-To: References: Message-ID: > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove wrong comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15233/files - new: https://git.openjdk.org/jdk/pull/15233/files/4ac4bf47..87f79bfc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15233/head:pull/15233 PR: https://git.openjdk.org/jdk/pull/15233 From coleenp at openjdk.org Wed Aug 16 19:16:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 19:16:31 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v3] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 18:51:03 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert to use static_cast. > > src/hotspot/share/logging/logOutput.cpp line 77: > >> 75: ntags++; >> 76: } >> 77: qsort(tags, ntags, sizeof(*tags), (_sort_Fn)tag_cmp); > > While wondering about, then searching for, _sort_Fn, I found it in globalDefinitions.hpp and a wrong comment in instanceKlass.cpp > > 1781: // _sort_Fn is defined in growableArray.hpp. > > would you mind fixing that comment or removing it? I removed it, since it seems not helpful. Thanks for reviewing! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296324419 From serb at openjdk.org Wed Aug 16 19:25:12 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 16 Aug 2023 19:25:12 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Thu, 10 Aug 2023 04:04:58 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove negation in os_windows.cpp Why initial patch was reverter using this comment: "unfortunately, did not prove to be as useful as expected"? What was the problem? What about the "pedantic" option which was added last time? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1681152431 From rkennke at openjdk.org Wed Aug 16 20:54:45 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 16 Aug 2023 20:54:45 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: On Wed, 16 Aug 2023 18:25:36 GMT, Albert Mingkun Yang wrote: > > I did that in an earlier version of this PR and it looked quite messy ... > > I just checked the first commit and the `MacroAssembler` part matches what I have in mind. I believe that diff being messy is due to "Calculations of min and max array and tlab sizes". Yes, that is another part of it. I can re-instate the parts where we initialize the leading 4 bytes in the body, if agree that this is the way to go. > > so we would have to check if the body is aligned or not, and if not, add an extra store > > The store, as I understand it, belongs to the body (payload) semantically. Mixing stores btw `initialize_header` and `initialize_body` is super confusing, IMO. Yes, I understand that. > > This is also consistent with how we store the klass-gap in instance objects there. > > klass-gap is part of the header, so it makes sense to be in `initialize_header`. No, klass-gap really is not part of the header. For non-array objects, this gap is where the first bunch of fields go, it really is payload. So, arguably, we should move the clearing of the gap into initialize_body(), too - but not as part of this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1296411005 From dlong at openjdk.org Wed Aug 16 21:24:37 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 16 Aug 2023 21:24:37 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v4] In-Reply-To: References: Message-ID: <5GqvDjdISC4fwmokR_sBBkxZyjIPHE3R5AHIJDT37rw=.03c19e38-2e13-4ad6-934f-7931ebdf931e@github.com> On Wed, 16 Aug 2023 19:16:28 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove wrong comment. src/hotspot/share/utilities/elfFile.hpp line 486: > 484: DwarfFile* _dwarf_file; > 485: MarkedDwarfFileReader _reader; > 486: uint64_t _section_start_address; This is platform-specific. Suggestion: uintptr_t _section_start_address; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296443060 From dlong at openjdk.org Wed Aug 16 21:37:36 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 16 Aug 2023 21:37:36 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v4] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 19:16:28 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove wrong comment. src/hotspot/share/utilities/elfFile.hpp line 790: > 788: // The address and op_index registers, taken together, form an operation pointer that can reference any > 789: // individual operation with the instruction stream. This field was introduced with DWARF 4. > 790: uint64_t _op_index; This can be uint8_t, because it can never be larger than _maximum_operations_per_instruction, which is also a byte. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296452122 From dlong at openjdk.org Wed Aug 16 21:41:34 2023 From: dlong at openjdk.org (Dean Long) Date: Wed, 16 Aug 2023 21:41:34 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v4] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 19:16:28 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove wrong comment. src/hotspot/share/utilities/elfFile.cpp line 1723: > 1721: void DwarfFile::LineNumberProgram::LineNumberProgramState::set_index_register(const uint64_t operation_advance, > 1722: const LineNumberProgramHeader& header) { > 1723: _op_index = (_op_index + operation_advance) % header._maximum_operations_per_instruction; This should be narrowed by a byte. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296456394 From coleenp at openjdk.org Wed Aug 16 23:08:07 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 23:08:07 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v5] In-Reply-To: References: Message-ID: > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/utilities/elfFile.hpp Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15233/files - new: https://git.openjdk.org/jdk/pull/15233/files/87f79bfc..913d94ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15233/head:pull/15233 PR: https://git.openjdk.org/jdk/pull/15233 From coleenp at openjdk.org Wed Aug 16 23:08:08 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 23:08:08 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v4] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 21:38:52 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove wrong comment. > > src/hotspot/share/utilities/elfFile.cpp line 1723: > >> 1721: void DwarfFile::LineNumberProgram::LineNumberProgramState::set_index_register(const uint64_t operation_advance, >> 1722: const LineNumberProgramHeader& header) { >> 1723: _op_index = (_op_index + operation_advance) % header._maximum_operations_per_instruction; > > This should be narrowed by a byte. So put the cast here? > src/hotspot/share/utilities/elfFile.hpp line 790: > >> 788: // The address and op_index registers, taken together, form an operation pointer that can reference any >> 789: // individual operation with the instruction stream. This field was introduced with DWARF 4. >> 790: uint64_t _op_index; > > This can be uint8_t, because it can never be larger than _maximum_operations_per_instruction, which is also a byte. This was windened as a result of a conversion warning, so I'd have to add a cast somewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296518068 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296517769 From coleenp at openjdk.org Wed Aug 16 23:14:27 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 23:14:27 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v4] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 23:02:45 GMT, Coleen Phillimore wrote: >> src/hotspot/share/utilities/elfFile.cpp line 1723: >> >>> 1721: void DwarfFile::LineNumberProgram::LineNumberProgramState::set_index_register(const uint64_t operation_advance, >>> 1722: const LineNumberProgramHeader& header) { >>> 1723: _op_index = (_op_index + operation_advance) % header._maximum_operations_per_instruction; >> >> This should be narrowed by a byte. > > So put the cast here? uint64_t operation_advance; if (!_reader.read_uleb128(&operation_advance, 4)) { // Must be at most 4 bytes because the index register is only 4 bytes wide. return false; } _state->add_to_address_register(operation_advance, _header); This is why I changed it. Should operation_advance be static_cast here ? This read function reads 64 bits of info. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296522650 From coleenp at openjdk.org Wed Aug 16 23:46:36 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 23:46:36 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v4] In-Reply-To: References: Message-ID: <3nwwU6qz0xL-YdB9m5O0Nzljhs-TYHuRncSfsM_FURk=.d3c7db91-5c7f-4734-9900-e8b7b582562d@github.com> On Wed, 16 Aug 2023 23:10:30 GMT, Coleen Phillimore wrote: >> So put the cast here? > > uint64_t operation_advance; > if (!_reader.read_uleb128(&operation_advance, 4)) { > // Must be at most 4 bytes because the index register is only 4 bytes wide. > return false; > } > _state->add_to_address_register(operation_advance, _header); > > This is why I changed it. Should operation_advance be static_cast here ? This read function reads 64 bits of info. src/hotspot/share/utilities/elfFile.cpp:1723:47: warning: conversion from 'int' to 'uint8_t' {aka 'u nsigned char'} may change value [-Wconversion] 1723 | _op_index = (_op_index + operation_advance) % header._maximum_operations_per_instruction; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296538303 From coleenp at openjdk.org Wed Aug 16 23:56:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Aug 2023 23:56:58 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Change size of op_index back. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15233/files - new: https://git.openjdk.org/jdk/pull/15233/files/913d94ea..570823b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=04-05 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15233/head:pull/15233 PR: https://git.openjdk.org/jdk/pull/15233 From coleenp at openjdk.org Thu Aug 17 00:10:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 00:10:28 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v4] In-Reply-To: <3nwwU6qz0xL-YdB9m5O0Nzljhs-TYHuRncSfsM_FURk=.d3c7db91-5c7f-4734-9900-e8b7b582562d@github.com> References: <3nwwU6qz0xL-YdB9m5O0Nzljhs-TYHuRncSfsM_FURk=.d3c7db91-5c7f-4734-9900-e8b7b582562d@github.com> Message-ID: On Wed, 16 Aug 2023 23:43:36 GMT, Coleen Phillimore wrote: >> uint64_t operation_advance; >> if (!_reader.read_uleb128(&operation_advance, 4)) { >> // Must be at most 4 bytes because the index register is only 4 bytes wide. >> return false; >> } >> _state->add_to_address_register(operation_advance, _header); >> >> This is why I changed it. Should operation_advance be static_cast here ? This read function reads 64 bits of info. > > src/hotspot/share/utilities/elfFile.cpp:1723:47: warning: conversion from 'int' to 'uint8_t' {aka 'u > nsigned char'} may change value [-Wconversion] > 1723 | _op_index = (_op_index + operation_advance) % header._maximum_operations_per_instruction; > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Changing op_index back fixes the warnings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296538634 From dlong at openjdk.org Thu Aug 17 00:40:38 2023 From: dlong at openjdk.org (Dean Long) Date: Thu, 17 Aug 2023 00:40:38 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: <8QK_R7yjBsv-FmX_OcDznsuE7UIZBl2hMqVJ7DjLmlQ=.dfff1586-ad90-42d1-8395-317183dcc58e@github.com> On Wed, 16 Aug 2023 23:56:58 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Change size of op_index back. src/hotspot/share/utilities/elfFile.cpp line 1454: > 1452: return false; > 1453: } > 1454: uint8_t operation_advance = checked_cast(adv); My reading of the spec is that operation_advance can be large. I suggest reverting operation_advance changes and just do a checked_cast when assigning op_index. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296561040 From coleenp at openjdk.org Thu Aug 17 01:01:02 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 01:01:02 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v7] In-Reply-To: References: Message-ID: <64mXF-Qq1tRFR1axECU7SYso_2LkvwRgIv9hYysCik8=.c0129347-0e66-4831-8d82-2d6414d14ae0@github.com> > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: put sizes back to uint32_t. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15233/files - new: https://git.openjdk.org/jdk/pull/15233/files/570823b0..280c018e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=05-06 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15233/head:pull/15233 PR: https://git.openjdk.org/jdk/pull/15233 From coleenp at openjdk.org Thu Aug 17 01:05:37 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 01:05:37 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: <8QK_R7yjBsv-FmX_OcDznsuE7UIZBl2hMqVJ7DjLmlQ=.dfff1586-ad90-42d1-8395-317183dcc58e@github.com> References: <8QK_R7yjBsv-FmX_OcDznsuE7UIZBl2hMqVJ7DjLmlQ=.dfff1586-ad90-42d1-8395-317183dcc58e@github.com> Message-ID: On Thu, 17 Aug 2023 00:37:55 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Change size of op_index back. > > src/hotspot/share/utilities/elfFile.cpp line 1454: > >> 1452: return false; >> 1453: } >> 1454: uint8_t operation_advance = checked_cast(adv); > > My reading of the spec is that operation_advance can be large. I suggest reverting operation_advance changes and just do a checked_cast when assigning op_index. I reverted it to uint32_t and we should file a bug if it needs to be larger, since the code is using 32 bit or smaller for this value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296570904 From dholmes at openjdk.org Thu Aug 17 02:09:42 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Aug 2023 02:09:42 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v7] In-Reply-To: <64mXF-Qq1tRFR1axECU7SYso_2LkvwRgIv9hYysCik8=.c0129347-0e66-4831-8d82-2d6414d14ae0@github.com> References: <64mXF-Qq1tRFR1axECU7SYso_2LkvwRgIv9hYysCik8=.c0129347-0e66-4831-8d82-2d6414d14ae0@github.com> Message-ID: On Thu, 17 Aug 2023 01:01:02 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > put sizes back to uint32_t. Mostly okay. One change I'd like reverted. A few queries - in particular with the Elf file stuff it is hard to see how you decided the new sizes for some variables. Thanks. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15233#pullrequestreview-1581595070 From dholmes at openjdk.org Thu Aug 17 02:09:47 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Aug 2023 02:09:47 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 23:56:58 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Change size of op_index back. src/hotspot/share/logging/logOutput.cpp line 69: > 67: > 68: static int tag_cmp(const LogTagType *a, const LogTagType *b) { > 69: return primitive_compare(a, b); This looks very odd given we are dealing with pointers not primitives. src/hotspot/share/memory/metaspace.cpp line 711: > 709: // it can get as low as 1:2. It is not a big deal though since ccs is only > 710: // reserved and will be committed on demand only. > 711: size_t max_ccs_size = (size_t)((double) MaxMetaspaceSize * 0.8); Really no need for FP arithmetic here - we could just do: size_t max_ccs_size = 8 * (MaxMetaspaceSize / 10); src/hotspot/share/services/threadService.hpp line 107: > 105: static jlong get_peak_thread_count() { return _peak_threads_count->get_value(); } > 106: static int get_live_thread_count() { return _atomic_threads_count; } > 107: static int get_daemon_thread_count() { return _atomic_daemon_threads_count; } Given all the other jlong usage in these functions, and that these are used for the return value of `jlong get_long_attribute(jmmLongAttribute att)` in management.cpp, I think these should stay as jlong returning functions. src/hotspot/share/services/threadStackTracker.cpp line 46: > 44: > 45: int ThreadStackTracker::compare_thread_stack_base(const SimpleThreadStackSite& s1, const SimpleThreadStackSite& s2) { > 46: return primitive_compare(s1.base(), s2.base()); Again these are not primitive values, but addresses, so this looks odd to me. src/hotspot/share/utilities/elfFile.cpp line 792: > 790: // We must align to twice the address size. > 791: uint8_t alignment = DwarfFile::ADDRESS_SIZE * 2; > 792: uint64_t padding = alignment - (_reader.get_position() - _section_start_address) % alignment; 64-bit seems a waste here. I would just cast the result to uint8_t. The % operator ensures it is within range. src/hotspot/share/utilities/elfFile.hpp line 486: > 484: DwarfFile* _dwarf_file; > 485: MarkedDwarfFileReader _reader; > 486: uintptr_t _section_start_address; This seems suspicious - is this a 32-bit value or 64-bit? src/hotspot/share/utilities/elfFile.hpp line 851: > 849: void reset_fields(); > 850: // Defined in section 6.2.5.1 of the DWARF spec 4. add_to_address_register() must always be executed before set_index_register. > 851: void add_to_address_register(uint8_t operation_advance, const LineNumberProgramHeader& header); Not clear how you decided/determined that `operation_advance` should always be 8-bit? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296554448 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296555979 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296558300 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296559830 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296569150 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296594924 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296595284 From dholmes at openjdk.org Thu Aug 17 02:09:48 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Aug 2023 02:09:48 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 01:57:46 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Change size of op_index back. > > src/hotspot/share/utilities/elfFile.hpp line 486: > >> 484: DwarfFile* _dwarf_file; >> 485: MarkedDwarfFileReader _reader; >> 486: uintptr_t _section_start_address; > > This seems suspicious - is this a 32-bit value or 64-bit? I see Dean indicated this is platform specific, but I don't know how. It sounds like this is a bug if it should be 64-bit. > src/hotspot/share/utilities/elfFile.hpp line 851: > >> 849: void reset_fields(); >> 850: // Defined in section 6.2.5.1 of the DWARF spec 4. add_to_address_register() must always be executed before set_index_register. >> 851: void add_to_address_register(uint8_t operation_advance, const LineNumberProgramHeader& header); > > Not clear how you decided/determined that `operation_advance` should always be 8-bit? Never mind I see you reverted this while I was reviewing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296598547 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296599004 From fgao at openjdk.org Thu Aug 17 02:52:54 2023 From: fgao at openjdk.org (Fei Gao) Date: Thu, 17 Aug 2023 02:52:54 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v33] In-Reply-To: References: <87ecc9JR1ie1bGLibg22j-nFA4KZjlpLWqZSZgFjuRA=.a6b7e527-c6be-47cd-b8c6-61cf51994cbf@github.com> Message-ID: On Wed, 16 Aug 2023 16:19:57 GMT, Roman Kennke wrote: > Still, there may be some subtle alignment differences now. The offsets are moved by 4 bytes for some types. That could have some impact on what vectorizes when `-XX:+AlignVector` or on platforms where `Matcher::misaligned_vectors_ok() = false`. But that is probably not bad enough to block this change here. What do you think @fg1417 @vnkozlov ? Yes. And, even on platforms supporting unaligned vector operations, like `AlignVector = false` or `Matcher::misaligned_vectors_ok() = true`, the offset change of the first entry may have impact on the pre-loop limit, because superword always requires that the load/store reference locating position zero in the vector should be aligned with vector length, see the algorithm in [align_initial_loop_index](https://github.com/openjdk/jdk/blob/0c3bc71d24fa13a0b1e55541c01554cd5e124027/src/hotspot/share/opto/superword.cpp#L3638). Well, the impact may vary in machines with different vector lengths. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1681530684 From jwaters at openjdk.org Thu Aug 17 04:34:34 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 04:34:34 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v3] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> <48HKGEKliSz22PR7_0NiTxDiV6Putmyxgeuhv8vstkA=.fd97e315-3cc6-477a-a99e-7e8a80344955@github.com> Message-ID: On Wed, 16 Aug 2023 19:22:01 GMT, Sergey Bylokhov wrote: > Why initial patch was reverter using this comment: "unfortunately, did not prove to be as useful as expected"? What was the problem? What about the "pedantic" option which was added last time? Hi, the problem was that gcc and clang are by default extremely strict with regards to conforming to C++, and the -pedantic flag simply made them so strict that it was impossible to compile the JDK with them. In an ideal world we'd be able to compile with -pedantic enabled, but that seems to be a lot of work required before that can be achieved, so it was reverted. In contrast, Visual C compiler is much too lax with what it allows you to get away with by default, so the permissive- flag is needed to make it match clang and gcc's default strictness. Additionally, permissive- is going to become the default on Visual C in the future, so we should add this as a flag to allow the JDK to be prepared when that time arrives ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1681596804 From jwaters at openjdk.org Thu Aug 17 04:37:31 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 04:37:31 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v17] In-Reply-To: References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: On Fri, 23 Jun 2023 02:31:11 GMT, Julian Waters wrote: >> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)). >> >> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used. >> >> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right >> >> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446)) > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'openjdk:master' into alignas > - Merge branch 'master' into alignas > - Merge branch 'openjdk:master' into alignas > - alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - ... and 7 more: https://git.openjdk.org/jdk/compare/5a82fa3b...bb9ae391 Thanks Roman, though I think there is discussion around offsetof and offset_of and the consensus was that it can't be replaced without causing issues, at least for now ------------- PR Comment: https://git.openjdk.org/jdk/pull/11431#issuecomment-1681598375 From jwaters at openjdk.org Thu Aug 17 04:45:56 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 04:45:56 GMT Subject: RFR: 8314488: Compile the JDK as C++17 Message-ID: Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) ------------- Commit messages: - vm_version_linux_riscv.cpp - allocation.cpp - 8310260 Changes: https://git.openjdk.org/jdk/pull/14988/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14988&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314488 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/14988.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14988/head:pull/14988 PR: https://git.openjdk.org/jdk/pull/14988 From jwaters at openjdk.org Thu Aug 17 04:48:26 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 04:48:26 GMT Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) The minimum compiler requirements have not been implemented yet, as I wanted to leave their discretion to any reviewers before setting a fixed value in the build system ------------- PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1681605796 From jwaters at openjdk.org Thu Aug 17 05:55:30 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 05:55:30 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v5] In-Reply-To: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com> References: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com> Message-ID: On Wed, 16 Aug 2023 07:54:12 GMT, Stefan Karlsson wrote: >> Julian Waters has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove whitespace >> - Revert changes of INTPTR_FORMAT, minor improvements > > src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 267: > >> 265: >> 266: if (!res) { >> 267: fatal_error("Failed to split placeholder", static_cast(addr), size); > > Suggestion: > > fatal_error("Failed to split placeholder", untype(addr), size); won't these trigger assertions inside fatal error reporting code as Thomas mentioned earlier? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1296707683 From stuefe at openjdk.org Thu Aug 17 06:03:25 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 17 Aug 2023 06:03:25 GMT Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) I disagree with this change. This should be discussed more broadly before trying to get a PR in. The associated JEP has been closed by Mark. Just a "oh well, then I'm doing it without JEP" is not the right way. Before agreeing to this, I would like to know what actual changes have been planned, and see them weighted against the cost. The cost, as I have stated before, are reviewer churn, implementation risk, and increased cost of downporting patches to older JDK versions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1681660826 From jwaters at openjdk.org Thu Aug 17 06:32:53 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 06:32:53 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v6] In-Reply-To: References: Message-ID: > Fix several formatting errors on Windows Julian Waters has updated the pull request incrementally with one additional commit since the last revision: src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp Co-authored-by: Stefan Karlsson ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15063/files - new: https://git.openjdk.org/jdk/pull/15063/files/9402a57c..b8829f1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15063/head:pull/15063 PR: https://git.openjdk.org/jdk/pull/15063 From fyang at openjdk.org Thu Aug 17 07:45:38 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 17 Aug 2023 07:45:38 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v2] In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 16:27:50 GMT, Ilya Gavrilin wrote: >> Please review this changes into risc-v double rounding intrinsic. >> >> On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). >> >> Also, we should provide some rounding mode to fcvt.x.x instruction. >> >> Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: >> >>> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). >> >> For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. >> For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. >> >> For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). >> As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). >> >> We have observed significant improvement on hifive and thead boards. >> >> testing: tier1, tier2 and hotspot:tier3 on hifive >> >> Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): >> >> Without intrinsic: >> >> Benchmark (TESTSIZE) Mode Cnt Score Error Units >> FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms >> FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms >> FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms >> >> With intrinsic: >> >> Benchmark (TESTSIZE) Mode Cnt Score Error Units >> FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms >> FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms >> FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms > > Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: > > Change fsgnj_d(dst, src, src) to fmv_d(dst, src) Changes requested by fyang (Reviewer). src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4250: > 4248: > 4249: // Round double with mode > 4250: We should add some comment here. Maybe: // According to Java SE specification, for floating-point round operations, if // the input is NaN, +/-infinity, or +/-0, the same input is returned as the // rounded result; this differs from behavior of RISC-V fcvt instructions (which // round out-of-range values to the nearest max or min value), therefore special // handling is needed by NaN, +/-Infinity, +/-0. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4258: > 4256: > 4257: // setting roundig mode to double->long (rm_direct) and long->double (rm_back) conversions > 4258: RoundingMode rm_direct, rm_back; Can we use the same rounding mode for conversions in both direction? Say `rup` for `ceil`, and `rdn` for `floor`. I see this policy is used for both glibc [1] and V8. [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/riscv/rv64/rvd/s_ceil.c;h=6c355cd72691c45c97201fe8947683287982ade9;hb=41d8c3bc33bcae1ebb8077b0442caef4917f763a src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1236: > 1234: rmode_floor, > 1235: rmode_rint > 1236: }; Why not use the existing `RoundDoubleModeNode::rmode_ceil`, `RoundDoubleModeNode::rmode_floor` and `RoundDoubleModeNode::rmode_rint` instead? src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1238: > 1236: }; > 1237: > 1238: void round_double_mode(FloatRegister dst, FloatRegister src, enum Round_double_mode round_mode, Register converted_dbl, Register mask, Register converted_dbl_masked); I would prefer to rename the last three parameters as `tmp1`, `tmp2` and `tmp3`. You could create aliases for these parameters where you feel necessary. src/hotspot/cpu/riscv/riscv.ad line 7706: > 7704: match(Set dst (RoundDoubleMode src rmode)); > 7705: ins_cost(2 * XFER_COST + BRANCH_COST); > 7706: effect(TEMP_DEF dst, TEMP tmp1, TEMP tmp2, TEMP tmp3, KILL cr); Did we kill `cr` anywhere in the assembly code? src/hotspot/cpu/riscv/riscv.ad line 7708: > 7706: effect(TEMP_DEF dst, TEMP tmp1, TEMP tmp2, TEMP tmp3, KILL cr); > 7707: > 7708: format %{ "RoundDoubleMode $src,$rmode" %} Indentation: Please leave a space between the two operands. src/hotspot/cpu/riscv/riscv.ad line 7727: > 7725: } > 7726: %} > 7727: ins_pipe(fp_rnd_d); I think `pipe_class_default` will do here. No need for another new pipe class. ------------- PR Review: https://git.openjdk.org/jdk/pull/14991#pullrequestreview-1581868109 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296756944 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296766101 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296734767 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296743831 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296750058 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296751637 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296749660 From stefank at openjdk.org Thu Aug 17 07:45:34 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 17 Aug 2023 07:45:34 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 06:32:53 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp > > Co-authored-by: Stefan Karlsson Changes requested by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15063#pullrequestreview-1581976221 From stefank at openjdk.org Thu Aug 17 07:45:37 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 17 Aug 2023 07:45:37 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v5] In-Reply-To: References: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com> Message-ID: <3Ww5RQVFcmJwR7ntIxoMhrbTMO6LhqzTKD7GZe1QOX0=.390291e8-5e00-4308-b290-1d7783bca587@github.com> On Thu, 17 Aug 2023 05:53:10 GMT, Julian Waters wrote: >> src/hotspot/os/windows/gc/z/zMapper_windows.cpp line 267: >> >>> 265: >>> 266: if (!res) { >>> 267: fatal_error("Failed to split placeholder", static_cast(addr), size); >> >> Suggestion: >> >> fatal_error("Failed to split placeholder", untype(addr), size); > > won't these trigger assertions inside fatal error reporting code as Thomas mentioned earlier? No. See: inline uintptr_t untype(zaddress_unsafe addr) { return static_cast(addr); } I wonder if Thomas were thinking about the opposite operation, which converts an uintptr_t to a zaddress_unsafe: inline zaddress_unsafe to_zaddress_unsafe(uintptr_t value) { const zaddress_unsafe addr = zaddress_unsafe(value); assert_is_valid(addr); return addr; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1296800443 From stefank at openjdk.org Thu Aug 17 07:45:39 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 17 Aug 2023 07:45:39 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v5] In-Reply-To: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com> References: <097vlyh3HRtjh26BxaaqKSBUFKJMTx8C6oeDR_D_Loo=.2424d129-4456-4f8c-9944-70dbb7bba676@github.com> Message-ID: On Wed, 16 Aug 2023 07:54:28 GMT, Stefan Karlsson wrote: >> Julian Waters has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove whitespace >> - Revert changes of INTPTR_FORMAT, minor improvements > > src/hotspot/os/windows/gc/z/zPhysicalMemoryBacking_windows.cpp line 202: > >> 200: if (!res) { >> 201: fatal("Failed to unmap view " PTR_FORMAT " " SIZE_FORMAT "M (%ld)", >> 202: static_cast(addr), size / M, GetLastError()); > > Suggestion: > > untype(addr), size / M, GetLastError()); This suggestion is still valid. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15063#discussion_r1296809821 From chagedorn at openjdk.org Thu Aug 17 08:02:31 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 17 Aug 2023 08:02:31 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v7] In-Reply-To: <59x-5y2rJqnSYlnLX_tgEIxkWi-1jFYe8V7g6Qj85VI=.79443604-6856-4d14-b0bc-c7c3312116d3@github.com> References: <59x-5y2rJqnSYlnLX_tgEIxkWi-1jFYe8V7g6Qj85VI=.79443604-6856-4d14-b0bc-c7c3312116d3@github.com> Message-ID: <0XRd5b-6Lsu3KbmkxUrqRCsAAIt9iW0eOCI9uPlAjJc=.cc8269a0-73ed-4bfc-8709-788132f81b7d@github.com> On Wed, 16 Aug 2023 13:43:34 GMT, Coleen Phillimore wrote: >> I've quickly skimmed through the usages of `read_uleb128`. We only seem to be reading either directly into a proper `uint64_t` or we are reading 4 bytes (i.e. `check_size = 4`). In the latter case, we could either: >> - add a `static_cast` for the read value when storing it into a 32 bit field, as for example for `isa` above (i.e. `_state->_isa = static_cast(isa)`). >> - provide a 32 bit `read_uleb128()` version that hides the casting. >> >> I guess it's fine to just go with a `static_cast` when storing to a field for the few cases we have. > > Thanks Christian. I'll revert to use the static cast. One of the cases has a comment why. That looks good! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296820975 From chagedorn at openjdk.org Thu Aug 17 08:02:33 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 17 Aug 2023 08:02:33 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 02:06:22 GMT, David Holmes wrote: >> src/hotspot/share/utilities/elfFile.hpp line 486: >> >>> 484: DwarfFile* _dwarf_file; >>> 485: MarkedDwarfFileReader _reader; >>> 486: uintptr_t _section_start_address; >> >> This seems suspicious - is this a 32-bit value or 64-bit? > > I see Dean indicated this is platform specific, but I don't know how. It sounds like this is a bug if it should be 64-bit. I think `uint32_t` was wrong here since it could be a larger 64-bit value on 64-bit platforms. `ElfShdr` is a `typedef` for `Elf64_Shdr` here which specifies `sh_offset` as `uint64_t`: https://github.com/openjdk/jdk/blob/43311930107d1783b742adbe567e9bdbcb55775d/src/hotspot/share/utilities/elfFile.cpp#L747-L752 I guess `sh_offset` was just never larger than 32-bits in practice, so it went unnoticed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296812239 From chagedorn at openjdk.org Thu Aug 17 08:02:36 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 17 Aug 2023 08:02:36 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v7] In-Reply-To: <64mXF-Qq1tRFR1axECU7SYso_2LkvwRgIv9hYysCik8=.c0129347-0e66-4831-8d82-2d6414d14ae0@github.com> References: <64mXF-Qq1tRFR1axECU7SYso_2LkvwRgIv9hYysCik8=.c0129347-0e66-4831-8d82-2d6414d14ae0@github.com> Message-ID: On Thu, 17 Aug 2023 01:01:02 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > put sizes back to uint32_t. src/hotspot/share/utilities/elfFuncDescTable.cpp line 49: > 47: } > 48: > 49: address ElfFuncDescTable::lookup(Elf64_Addr index) { I think this could be `Elf_Addr` to be platform-specific. `Elf_Word` is either `Elf32_Word` or `Elf64_Word`, depending on the platform. But both are `typedefs` for `uint32_t` for some reason. That's why it must have complained here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296819904 From vkempik at openjdk.org Thu Aug 17 08:17:29 2023 From: vkempik at openjdk.org (Vladimir Kempik) Date: Thu, 17 Aug 2023 08:17:29 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v2] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 06:30:47 GMT, Fei Yang wrote: >> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: >> >> Change fsgnj_d(dst, src, src) to fmv_d(dst, src) > > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1236: > >> 1234: rmode_floor, >> 1235: rmode_rint >> 1236: }; > > Why not use the existing `RoundDoubleModeNode::rmode_ceil`, `RoundDoubleModeNode::rmode_floor` and `RoundDoubleModeNode::rmode_rint` instead? not sure it's good idea: RoundDoubleModeNode enum is purely C2 entity. Using some C2 enum in macroAssembler_riscv ( not c2_MacroAssembler_riscv) doesn't sound good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296845599 From fyang at openjdk.org Thu Aug 17 08:23:27 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 17 Aug 2023 08:23:27 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v2] In-Reply-To: References: Message-ID: <40ZBlZSH8kW1ku-h_JWAOq3h-OtJPbcqV9X6DZ_Ssmg=.2fff99ca-2f9e-45dd-9914-2731663f4c2d@github.com> On Thu, 17 Aug 2023 08:15:01 GMT, Vladimir Kempik wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1236: >> >>> 1234: rmode_floor, >>> 1235: rmode_rint >>> 1236: }; >> >> Why not use the existing `RoundDoubleModeNode::rmode_ceil`, `RoundDoubleModeNode::rmode_floor` and `RoundDoubleModeNode::rmode_rint` instead? > > not sure it's good idea: RoundDoubleModeNode enum is purely C2 entity. Using some C2 enum in macroAssembler_riscv ( not c2_MacroAssembler_riscv) doesn't sound good. Make sense. So we might further move the new assembler function `MacroAssembler::round_double_mode` into c2_MacroAssembler_riscv as it's only used for C2 for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1296852355 From jwaters at openjdk.org Thu Aug 17 08:32:01 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 08:32:01 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v7] In-Reply-To: References: Message-ID: <2DcPIgu4u8-toGNKtbJRolqEJbKrNQ5j2v2_k_ipl3g=.11b771c9-e8bc-43df-ab34-2f7f4fbe28d2@github.com> > Fix several formatting errors on Windows Julian Waters has updated the pull request with a new target base due to a merge or a rebase. ------------- Changes: https://git.openjdk.org/jdk/pull/15063/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15063&range=06 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15063/head:pull/15063 PR: https://git.openjdk.org/jdk/pull/15063 From jwaters at openjdk.org Thu Aug 17 08:32:02 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 08:32:02 GMT Subject: RFR: 8313302: Fix formatting errors on Windows [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 06:32:53 GMT, Julian Waters wrote: >> Fix several formatting errors on Windows > > Julian Waters has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. Closed due to merge conflicts ------------- PR Comment: https://git.openjdk.org/jdk/pull/15063#issuecomment-1681856161 From jwaters at openjdk.org Thu Aug 17 08:38:01 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 08:38:01 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: > We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Document changes in awt_DnDDS.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15096/files - new: https://git.openjdk.org/jdk/pull/15096/files/4e3329b8..2f8997e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096 PR: https://git.openjdk.org/jdk/pull/15096 From jwaters at openjdk.org Thu Aug 17 08:40:33 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 17 Aug 2023 08:40:33 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Document changes in awt_DnDDS.cpp Adding extra reviewer for jdk.accessibility ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1681871378 From fbredberg at openjdk.org Thu Aug 17 08:49:34 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 17 Aug 2023 08:49:34 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames In-Reply-To: References: Message-ID: <1qfsl2V8xwnj3aIwL2UJlVEePrqByF8oOKAP_IzyQ6Q=.7c71ab55-ac9b-4324-88ad-35c41fcebdaf@github.com> On Wed, 16 Aug 2023 09:20:07 GMT, Andrew Haley wrote: > Sure, but we need to see what they point to. In other words, every relativized point should be _decoded_ into its pointer form. Otherwise relativization, a good thing, becomes obfuscation, a bad thing. I see what you mean, but It can also be very confusing if you use a debugger to hex dump the memory were the fixed frame is located, and you see something else than is shown by frame::describe. My opinion is that it's important to show the relativzed pointers the same way, regardless if they are on the stack or on the heap. And also somehow show that they are relativized. Also since this PR is really just about relativizing last_sp, I think it would be nice if it could be integrated with the small change I did to frame::describe. After that I can create a new issue to handle the broader picture of how to show relativized pointers in frame::describe. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1681883545 From aph at openjdk.org Thu Aug 17 09:20:29 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 17 Aug 2023 09:20:29 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames In-Reply-To: <1qfsl2V8xwnj3aIwL2UJlVEePrqByF8oOKAP_IzyQ6Q=.7c71ab55-ac9b-4324-88ad-35c41fcebdaf@github.com> References: <1qfsl2V8xwnj3aIwL2UJlVEePrqByF8oOKAP_IzyQ6Q=.7c71ab55-ac9b-4324-88ad-35c41fcebdaf@github.com> Message-ID: On Thu, 17 Aug 2023 08:46:57 GMT, Fredrik Bredberg wrote: > Also since this PR is really just about relativizing last_sp, I think it would be nice if it could be integrated with the small change I did to frame::describe. After that I can create a new issue to handle the broader picture of how to show relativized pointers in frame::describe. That sounds good to me. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1681928206 From neugens at redhat.com Thu Aug 17 09:27:28 2023 From: neugens at redhat.com (Mario Torre) Date: Thu, 17 Aug 2023 11:27:28 +0200 Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: I agree with Thomas and Mark, I too don't see this change favourably. This change would affect current build environments and setups, introduce unforeseen bugs and as Thomas mentioned the backporting work itself. Even changes due to JEP 347 did potentially make backporting more difficult, however it standardised on a fixed and broadly available version of gcc, and in this case C++17 would mean being forced to update. The right place for this sort of changes is a JEP and it needs to be widely discussed with porters and the updates maintainers before even going into mainline. In your case the JEP was rejected, I would accept that because this is an invasive change that may not bring relevant benefits, but at the very least the right thing to do would be to write a better proposal and make a [very] compelling case in the JEP on why we may want to update now, with the prerequisite of a discussion on this proposal and its benefits on the main development list to make sure many more eyes did see this. Eventually there will be a time where we can and maybe should consider c++17 (or later), I don't think this is now however. Cheers, Mario On Thu, Aug 17, 2023 at 8:04?AM Thomas Stuefe wrote: > > On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > > > Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) > > I disagree with this change. This should be discussed more broadly before trying to get a PR in. The associated JEP has been closed by Mark. Just a "oh well, then I'm doing it without JEP" is not the right way. > > Before agreeing to this, I would like to know what actual changes have been planned, and see them weighted against the cost. The cost, as I have stated before, are reviewer churn, implementation risk, and increased cost of downporting patches to older JDK versions. > > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1681660826 > -- Mario Torre Manager, Software Engineering, Red Hat OpenJDK, Java Champion https://keybase.io/neugens 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 Mastodon: https://mastodon.social/@MarioTorre Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross From fbredberg at openjdk.org Thu Aug 17 11:51:31 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 17 Aug 2023 11:51:31 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v3] In-Reply-To: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> References: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> Message-ID: On Tue, 15 Aug 2023 12:01:41 GMT, Fredrik Bredberg wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Removed the on_heap parameter from FrameValues::print_on Created [Improve how relativized pointers are printed by frame::describe](https://bugs.openjdk.org/browse/JDK-8314508) to handle the broader picture of how to show relativized pointers in frame::describe. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1682146366 From coleenp at openjdk.org Thu Aug 17 12:37:03 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 12:37:03 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v7] In-Reply-To: <64mXF-Qq1tRFR1axECU7SYso_2LkvwRgIv9hYysCik8=.c0129347-0e66-4831-8d82-2d6414d14ae0@github.com> References: <64mXF-Qq1tRFR1axECU7SYso_2LkvwRgIv9hYysCik8=.c0129347-0e66-4831-8d82-2d6414d14ae0@github.com> Message-ID: <9GB5lt86xg-UXyoE--JhoSl27LkvDJKhhXrw4NtotQA=.f74c3baa-c69b-4c5f-af83-de28f95988e1@github.com> On Thu, 17 Aug 2023 01:01:02 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > put sizes back to uint32_t. I reverted much of elfFile.cpp, except a few casts already. ------------- PR Review: https://git.openjdk.org/jdk/pull/15233#pullrequestreview-1582475421 From coleenp at openjdk.org Thu Aug 17 12:37:03 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 12:37:03 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v8] In-Reply-To: References: Message-ID: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: David's and Christian's review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15233/files - new: https://git.openjdk.org/jdk/pull/15233/files/280c018e..11eef98f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15233&range=06-07 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15233/head:pull/15233 PR: https://git.openjdk.org/jdk/pull/15233 From coleenp at openjdk.org Thu Aug 17 12:37:04 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 12:37:04 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 00:20:44 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Change size of op_index back. > > src/hotspot/share/logging/logOutput.cpp line 69: > >> 67: >> 68: static int tag_cmp(const LogTagType *a, const LogTagType *b) { >> 69: return primitive_compare(a, b); > > This looks very odd given we are dealing with pointers not primitives. Was it odd before or odd now? What we want to do is compare pointers for a sort function. This primitive_compare has been used in other places as an improvement. > src/hotspot/share/memory/metaspace.cpp line 711: > >> 709: // it can get as low as 1:2. It is not a big deal though since ccs is only >> 710: // reserved and will be committed on demand only. >> 711: size_t max_ccs_size = (size_t)((double) MaxMetaspaceSize * 0.8); > > Really no need for FP arithmetic here - we could just do: > > size_t max_ccs_size = 8 * (MaxMetaspaceSize / 10); That's a good observation. > src/hotspot/share/services/threadService.hpp line 107: > >> 105: static jlong get_peak_thread_count() { return _peak_threads_count->get_value(); } >> 106: static int get_live_thread_count() { return _atomic_threads_count; } >> 107: static int get_daemon_thread_count() { return _atomic_daemon_threads_count; } > > Given all the other jlong usage in these functions, and that these are used for the return value of `jlong get_long_attribute(jmmLongAttribute att)` in management.cpp, I think these should stay as jlong returning functions. If they stay jlong returns (note that these fields are in fact int), then we need to add casting to all the callers. Casting is worse than returning the correct types. If someone wants to make these fields jlong someday then they can propagate the change to the callers. This change corrects the types. > src/hotspot/share/services/threadStackTracker.cpp line 46: > >> 44: >> 45: int ThreadStackTracker::compare_thread_stack_base(const SimpleThreadStackSite& s1, const SimpleThreadStackSite& s2) { >> 46: return primitive_compare(s1.base(), s2.base()); > > Again these are not primitive values, but addresses, so this looks odd to me. Maybe you don't like the name primitive. We can file an RFE to change the name to something you'd prefer? > src/hotspot/share/utilities/elfFile.cpp line 792: > >> 790: // We must align to twice the address size. >> 791: uint8_t alignment = DwarfFile::ADDRESS_SIZE * 2; >> 792: uint64_t padding = alignment - (_reader.get_position() - _section_start_address) % alignment; > > 64-bit seems a waste here. I would just cast the result to uint8_t. The % operator ensures it is within range. Wasting what? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297129576 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297147389 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297133657 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297134164 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297134606 From coleenp at openjdk.org Thu Aug 17 12:37:04 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 12:37:04 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 12:15:24 GMT, Coleen Phillimore wrote: >> src/hotspot/share/utilities/elfFile.cpp line 792: >> >>> 790: // We must align to twice the address size. >>> 791: uint8_t alignment = DwarfFile::ADDRESS_SIZE * 2; >>> 792: uint64_t padding = alignment - (_reader.get_position() - _section_start_address) % alignment; >> >> 64-bit seems a waste here. I would just cast the result to uint8_t. The % operator ensures it is within range. > > Wasting what? This calls move_position with the value next: bool DwarfFile::MarkedDwarfFileReader::move_position(const long offset) { if (offset == 0) { return true; } return set_position(_current_pos + offset); } Then set position bool FileReader::set_position(long offset) { Both will promote whatever "wasted type" to a long. I probably should make this a long though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297144614 From coleenp at openjdk.org Thu Aug 17 12:37:04 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 12:37:04 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 12:24:48 GMT, Coleen Phillimore wrote: >> Wasting what? > > This calls move_position with the value next: > > > bool DwarfFile::MarkedDwarfFileReader::move_position(const long offset) { > if (offset == 0) { > return true; > } > return set_position(_current_pos + offset); > } > > > Then set position > > bool FileReader::set_position(long offset) { > > Both will promote whatever "wasted type" to a long. I probably should make this a long though. We're not using 'long' in platform dependent code but this elf support does use it. That should be changed/fixed together if we decide to change/fix it. Since this code isn't used on windows, maybe we don't mind the 'long' type here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297153696 From coleenp at openjdk.org Thu Aug 17 12:37:04 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 12:37:04 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v8] In-Reply-To: <0XRd5b-6Lsu3KbmkxUrqRCsAAIt9iW0eOCI9uPlAjJc=.cc8269a0-73ed-4bfc-8709-788132f81b7d@github.com> References: <59x-5y2rJqnSYlnLX_tgEIxkWi-1jFYe8V7g6Qj85VI=.79443604-6856-4d14-b0bc-c7c3312116d3@github.com> <0XRd5b-6Lsu3KbmkxUrqRCsAAIt9iW0eOCI9uPlAjJc=.cc8269a0-73ed-4bfc-8709-788132f81b7d@github.com> Message-ID: On Thu, 17 Aug 2023 07:53:07 GMT, Christian Hagedorn wrote: >> Thanks Christian. I'll revert to use the static cast. One of the cases has a comment why. > > That looks good! Thanks Christian! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297135202 From coleenp at openjdk.org Thu Aug 17 12:37:05 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 12:37:05 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 07:44:54 GMT, Christian Hagedorn wrote: >> I see Dean indicated this is platform specific, but I don't know how. It sounds like this is a bug if it should be 64-bit. > > I think `uint32_t` was wrong here since it could be a larger 64-bit value on 64-bit platforms. `ElfShdr` is a `typedef` for `Elf64_Shdr` here which specifies `sh_offset` as `uint64_t`: > https://github.com/openjdk/jdk/blob/43311930107d1783b742adbe567e9bdbcb55775d/src/hotspot/share/utilities/elfFile.cpp#L747-L752 > > I guess `sh_offset` was just never larger than 32-bits in practice, so it went unnoticed. It was unnoticed until -Wconversion that is. It seems reasonable that something called "address" should be declared as an address size. Especially if address sized things are being assigned into it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297135720 From coleenp at openjdk.org Thu Aug 17 12:37:05 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 12:37:05 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v7] In-Reply-To: References: <64mXF-Qq1tRFR1axECU7SYso_2LkvwRgIv9hYysCik8=.c0129347-0e66-4831-8d82-2d6414d14ae0@github.com> Message-ID: On Thu, 17 Aug 2023 07:52:07 GMT, Christian Hagedorn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> put sizes back to uint32_t. > > src/hotspot/share/utilities/elfFuncDescTable.cpp line 49: > >> 47: } >> 48: >> 49: address ElfFuncDescTable::lookup(Elf64_Addr index) { > > I think this could be `Elf_Addr` to be platform-specific. `Elf_Word` is either `Elf32_Word` or `Elf64_Word`, depending on the platform. But both are `typedefs` for `uint32_t` for some reason. That's why it must have complained here. Ok, thanks, I'll change that. I picked the type that the compiler told me, but this would be better on 32 bit platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297137694 From rcastanedalo at openjdk.org Thu Aug 17 12:44:55 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 17 Aug 2023 12:44:55 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) Message-ID: This changeset ensures that the array copy stub underlying the intrinsic implementation of `Object.clone` only copies its (double-word aligned) payload, excluding the remaining object alignment padding words, when a non-default `ObjectAlignmentInBytes` value is used. This prevents the specialized ZGC stubs for `Object[]` array copy from processing undefined object alignment padding words as valid object pointers. For further details about the specific failure, see [initial analysis](https://bugs.openjdk.org/browse/JDK-8312749?focusedCommentId=14600658&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14600658) by Erik ?sterlund and Stefan Karlsson and comments in the regression test included in this changeset. As a side-benefit, the changeset simplifies the array size computation logic in `GraphKit::new_array()` by decoupling computation of header size and alignment padding size. #### Testing ##### Functionality - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) - tier4-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; ZGC-specific tests only) - tier6-9 (linux-x64; ZGC-specific tests only) - tier1-3, and a few custom examples, applying [JDK-8139457](https://github.com/openjdk/jdk/pull/11044) (under review) on top of this changeset ##### Performance Tested performance on the following set of OpenJDK micro-benchmarks, on linux-x64 (for both G1 and ZGC, using different ObjectAlignmentInBytes values): - `openjdk.bench.java.lang.ArrayClone.byteClone` - `openjdk.bench.java.lang.ArrayClone.intClone` - `openjdk.bench.java.lang.ArrayFiddle.simple_clone` - `openjdk.bench.java.lang.Clone.cloneLarge` - `openjdk.bench.java.lang.Clone.cloneThreeDifferent` No significant regression was observed. ------------- Commit messages: - Remove extra whitespace - Revert use of UseNewCode - Revert "TEMPORARY: add additional macro-assembly comments" - Revert "TEMPORARY: set UseNewCode to true by default" - Revert "TEMPORARY: print only 'oop_disjoint_arraycopy_uninit' stub code" - Require GenZGC in the test - Round up object size at the end of the computation - Comment and rename for clarity - Add a regression test - Remove unused variable - ... and 8 more: https://git.openjdk.org/jdk/compare/ec2f38fd...5c56a5e5 Changes: https://git.openjdk.org/jdk/pull/15288/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15288&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312749 Stats: 114 lines in 4 files changed: 89 ins; 9 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/15288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15288/head:pull/15288 PR: https://git.openjdk.org/jdk/pull/15288 From stuefe at openjdk.org Thu Aug 17 12:47:35 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 17 Aug 2023 12:47:35 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v8] In-Reply-To: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> References: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> Message-ID: On Thu, 17 Aug 2023 12:37:03 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > David's and Christian's review comments. src/hotspot/share/memory/metaspace.cpp line 711: > 709: // it can get as low as 1:2. It is not a big deal though since ccs is only > 710: // reserved and will be committed on demand only. > 711: size_t max_ccs_size = 8 * (MaxMetaspaceSize / 10); ok ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297170669 From ayang at openjdk.org Thu Aug 17 12:47:51 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 17 Aug 2023 12:47:51 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: On Wed, 16 Aug 2023 20:47:11 GMT, Roman Kennke wrote: >>> I did that in an earlier version of this PR and it looked quite messy ... >> >> I just checked the first commit and the `MacroAssembler` part matches what I have in mind. I believe that diff being messy is due to "Calculations of min and max array and tlab sizes". >> >>> so we would have to check if the body is aligned or not, and if not, add an extra store >> >> The store, as I understand it, belongs to the body (payload) semantically. Mixing stores btw `initialize_header` and `initialize_body` is super confusing, IMO. >> >>> This is also consistent with how we store the klass-gap in instance objects there. >> >> klass-gap is part of the header, so it makes sense to be in `initialize_header`. > >> > I did that in an earlier version of this PR and it looked quite messy ... >> >> I just checked the first commit and the `MacroAssembler` part matches what I have in mind. I believe that diff being messy is due to "Calculations of min and max array and tlab sizes". > > Yes, that is another part of it. I can re-instate the parts where we initialize the leading 4 bytes in the body, if agree that this is the way to go. > >> > so we would have to check if the body is aligned or not, and if not, add an extra store >> >> The store, as I understand it, belongs to the body (payload) semantically. Mixing stores btw `initialize_header` and `initialize_body` is super confusing, IMO. > > > Yes, I understand that. > >> > This is also consistent with how we store the klass-gap in instance objects there. >> >> klass-gap is part of the header, so it makes sense to be in `initialize_header`. > > No, klass-gap really is not part of the header. For non-array objects, this gap is where the first bunch of fields go, it really is payload. So, arguably, we should move the clearing of the gap into initialize_body(), too - but not as part of this PR. There is sth odd about `instanceOopDesc` that the header/payload reported by public API `header_size` and `base_offset_in_bytes` can be overlapping, shown picturally: |<-header->|.... | | |<-payload->| Essentially, `header-size * HeapWordSize != base-offset-in-bytes`, blurring the boundary btw header and payload. Possibly, it's intentional to overapproximate "header" and underapproximate "payload", because some context dependent constraints prevent `header_size` from being klass specific, i.e. having knowledge to the corresponding fields (layout). Otherwise, one should avoid declaring the existence of "klass-gap" then filling it up using some fields from the object. A klass-gap is there if and only if the first field has special alignment requirement. > No, klass-gap really is not part of the header. For non-array objects, this gap is where the first bunch of fields go, it really is payload. I can see where that interpretation comes from since `base_offset_in_bytes == klass_gap_offset_in_bytes` when `UseCompressedClassPointers == true` and base-offset denotes the start of payload. It's not part of this diff -- in `C1_MacroAssembler::initialize_header`, can `movl(Address(obj, oopDesc::klass_offset_in_bytes()), t1);` use `movptr` like its 32bit counterpart? Since the klass-layout-info is unavailable in this context, including this "potential" gap as part of the header is kind of overapproximation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1297170883 From chagedorn at openjdk.org Thu Aug 17 12:54:30 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 17 Aug 2023 12:54:30 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v8] In-Reply-To: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> References: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> Message-ID: On Thu, 17 Aug 2023 12:37:03 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > David's and Christian's review comments. The elf/dwarf changes look good to me. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15233#pullrequestreview-1582552605 From pchilanomate at openjdk.org Thu Aug 17 14:13:32 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 17 Aug 2023 14:13:32 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v3] In-Reply-To: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> References: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> Message-ID: <5SvhPXmcByAEn4B9CRxUJC7csfCzGr8SnImkjaLBNqk=.fb4ec7a1-04cc-4bd8-81ca-187536f1c295@github.com> On Tue, 15 Aug 2023 12:01:41 GMT, Fredrik Bredberg wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Removed the on_heap parameter from FrameValues::print_on Thanks for the fixes @fbredber, looks good to me. Patricio ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14545#pullrequestreview-1582722092 From aph at openjdk.org Thu Aug 17 14:26:30 2023 From: aph at openjdk.org (Andrew Haley) Date: Thu, 17 Aug 2023 14:26:30 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v3] In-Reply-To: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> References: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> Message-ID: On Tue, 15 Aug 2023 12:01:41 GMT, Fredrik Bredberg wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Removed the on_heap parameter from FrameValues::print_on Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14545#pullrequestreview-1582751737 From coleenp at openjdk.org Thu Aug 17 14:27:31 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Aug 2023 14:27:31 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v8] In-Reply-To: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> References: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> Message-ID: On Thu, 17 Aug 2023 12:37:03 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > David's and Christian's review comments. Thank you Christian. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15233#issuecomment-1682382890 From bulasevich at openjdk.org Thu Aug 17 15:29:29 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 17 Aug 2023 15:29:29 GMT Subject: RFR: 8313419: Template interpreter produces no safepoint check for return bytecodes In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 13:49:55 GMT, Fredrik Bredberg wrote: > would appreciate if @RealFYang and @bulasevich could take it for a real test drive. Right now (after commit "8301996: Move field resolution" commit) arm32 is broken. I tested this change with the latest working revision: tier1-tier3 is fine. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15248#issuecomment-1682484190 From rkennke at openjdk.org Thu Aug 17 16:02:31 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 17 Aug 2023 16:02:31 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v17] In-Reply-To: References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: On Thu, 17 Aug 2023 04:34:42 GMT, Julian Waters wrote: > Thanks Roman, though I think there is discussion around offsetof and offset_of and the consensus was that it can't be replaced without causing issues, at least for now offsetof() can certainly not be replaced wholesale, because offset_of() is only specified to work for standard layout types. But I believe it could be used in places where we know that we are dealing with types that fit the spec. But I'm not deeply familiar with the constraints there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11431#issuecomment-1682537506 From pchilanomate at openjdk.org Thu Aug 17 17:07:31 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 17 Aug 2023 17:07:31 GMT Subject: RFR: 8313419: Template interpreter produces no safepoint check for return bytecodes In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 13:22:19 GMT, Fredrik Bredberg wrote: > The template interpreter produces a safepoint check for return bytecodes (TemplateTable::_return(TosState state)) on x86, ppc64le and s390, but not on aarch64, arm32, and riscv64. > > This PR adds the missing safepoint check to aarch64, arm32, and riscv64. > > Tested tier1-tier7 on aarch64. Both arm32, and riscv64 was sanity tested using Qemu. Looks good to me. src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2206: > 2204: __ push(state); > 2205: __ push_cont_fastpath(rthread); > 2206: __ call_VM(noreg, CAST_FROM_FN_PTR(address, InterpreterRuntime::at_safepoint)); Looking at the code generated for the existing safepoint poll (`TemplateInterpreterGenerator::generate_safept_entry_for()`) I see we add a full memory barrier after the return from `InterpreterRuntime::at_safepoint()`. That would call for adding it here too although I don't see why we need that. The SafepointMechanism logic already executes the proper barriers after we process pending operations. Same thing for riscv. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15248#pullrequestreview-1583055387 PR Review Comment: https://git.openjdk.org/jdk/pull/15248#discussion_r1297495880 From rkennke at openjdk.org Thu Aug 17 18:58:41 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 17 Aug 2023 18:58:41 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> Message-ID: <3dMQjgPviPNAuH-FzX_rkqQCsbKFsXbVdNN2t_DgAjc=.3411115c-3f11-4b3b-bb9c-0ce400f5a57b@github.com> On Thu, 17 Aug 2023 12:45:09 GMT, Albert Mingkun Yang wrote: > There is sth odd about `instanceOopDesc` that the header/payload reported by public API `header_size` and `base_offset_in_bytes` can be overlapping, shown picturally: > > ``` > |<-header->|.... | > | |<-payload->| > ``` > > Essentially, `header-size * HeapWordSize != base-offset-in-bytes`, blurring the boundary btw header and payload. > > Possibly, it's intentional to overapproximate "header" and underapproximate "payload", because some context dependent constraints prevent `header_size` from being klass specific, i.e. having knowledge to the corresponding fields (layout). Otherwise, one should avoid declaring the existence of "klass-gap" then filling it up using some fields from the object. A klass-gap is there if and only if the first field has special alignment requirement. With this patch, header_size() is really only a helper-method that aligns-up header_size_in_bytes() to the next word boundary, and returns that size in word-units, for use by code that need such a thing (e.g. various min/max size calculations that operate with heap-words). The source of truth regarding header-size vs payload-offset is the two methods header_size_in_bytes() and base_offset_in_bytes(). Maybe it makes sense to move out header_size() to avoid the confusion? > > No, klass-gap really is not part of the header. For non-array objects, this gap is where the first bunch of fields go, it really is payload. > > I can see where that interpretation comes from since `base_offset_in_bytes == klass_gap_offset_in_bytes` when `UseCompressedClassPointers == true` and base-offset denotes the start of payload. > > It's not part of this diff -- in `C1_MacroAssembler::initialize_header`, can `movl(Address(obj, oopDesc::klass_offset_in_bytes()), t1);` use `movptr` like its 32bit counterpart? It could, but it doesn't seem to be a good fit because a narrowKlass is not a ptr. narrowKlass are explicitly only a 32bit int value and should be treated as such. > Since the klass-layout-info is unavailable in this context, including this "potential" gap as part of the header is kind of overapproximation. Yeah. If the gap is not used by instance fields or array elements, they don't actually belong to neither the header nor to the payload. It's just an alignment gap that sits in between the two. Strictly speaking they don't even need to be cleared (and I believe C2 would not clear it in any case) because it's not accessed, ever. But we don't have that info for instances, so we clear it anyway. *If* the gap is used (and that is common), it's clearly payload. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1297619380 From rkennke at openjdk.org Thu Aug 17 19:07:36 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 17 Aug 2023 19:07:36 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v51] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Move alignment-gap-clearing into allocate_array() (aarch64) - Move header_size_in_bytes closer to length_offset_in_bytes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/b54cd4bf..7418fab0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=50 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=49-50 Stats: 48 lines in 2 files changed: 25 ins; 22 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From rkennke at openjdk.org Thu Aug 17 19:08:05 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 17 Aug 2023 19:08:05 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 14:14:46 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > RISCV fixes by @RealYFang @albertnetymk I have moved the gap-clearing out of initialize_header() and into allocate_array() for aarch64 parts: https://github.com/openjdk/jdk/pull/11044/commits/7418fab09cad0d47efa5fd8ab487b4386e10bf76 I couldn't move it into initialize_body() because that method is also used by initialize_object() and would require more work to get the len_in_bytes consistent. I added a TODO comment to that code block. If that is what you had in mind, I would do the same for x86_64 version of the code path. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1682814365 From dholmes at openjdk.org Fri Aug 18 00:35:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Aug 2023 00:35:32 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 12:10:51 GMT, Coleen Phillimore wrote: >> src/hotspot/share/logging/logOutput.cpp line 69: >> >>> 67: >>> 68: static int tag_cmp(const LogTagType *a, const LogTagType *b) { >>> 69: return primitive_compare(a, b); >> >> This looks very odd given we are dealing with pointers not primitives. > > Was it odd before or odd now? What we want to do is compare pointers for a sort function. This primitive_compare has been used in other places as an improvement. It is the name `primitive_compare` - I only previously saw it used for integer types. Using it with pointers seems "wrong". Don't we have to convert to `intptr_t` to compare pointers numerically anyway? >> src/hotspot/share/services/threadService.hpp line 107: >> >>> 105: static jlong get_peak_thread_count() { return _peak_threads_count->get_value(); } >>> 106: static int get_live_thread_count() { return _atomic_threads_count; } >>> 107: static int get_daemon_thread_count() { return _atomic_daemon_threads_count; } >> >> Given all the other jlong usage in these functions, and that these are used for the return value of `jlong get_long_attribute(jmmLongAttribute att)` in management.cpp, I think these should stay as jlong returning functions. > > If they stay jlong returns (note that these fields are in fact int), then we need to add casting to all the callers. Casting is worse than returning the correct types. If someone wants to make these fields jlong someday then they can propagate the change to the callers. This change corrects the types. I don't follow. The fields are int so cast them to jlong before returning them. All the callers of these methods expect jlong so there can't be any issue there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297870904 PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297871632 From haosun at openjdk.org Fri Aug 18 01:14:46 2023 From: haosun at openjdk.org (Hao Sun) Date: Fri, 18 Aug 2023 01:14:46 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v3] In-Reply-To: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> References: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> Message-ID: On Tue, 15 Aug 2023 12:01:41 GMT, Fredrik Bredberg wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Removed the on_heap parameter from FrameValues::print_on Thanks for your update on "on_heap" parameter. AArch64 part looks good to me. ------------- Marked as reviewed by haosun (Committer). PR Review: https://git.openjdk.org/jdk/pull/14545#pullrequestreview-1583692711 From coleenp at openjdk.org Fri Aug 18 01:23:35 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 18 Aug 2023 01:23:35 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 00:22:10 GMT, David Holmes wrote: >> Was it odd before or odd now? What we want to do is compare pointers for a sort function. This primitive_compare has been used in other places as an improvement. > > It is the name `primitive_compare` - I only previously saw it used for integer types. Using it with pointers seems "wrong". Don't we have to convert to `intptr_t` to compare pointers numerically anyway? template bool primitive_equals(const K& k0, const K& k1) { return k0 == k1; } template int primitive_compare(const K& k0, const K& k1) { return ((k0 < k1) ? -1 : (k0 == k1) ? 0 : 1); } This is the primitive_compare we added with one of these patches. This compares pointers and because of the template, it doesn't need to look like this: int Symbol::fast_compare(const Symbol* other) const { return (((uintptr_t)this < (uintptr_t)other) ? -1 : ((uintptr_t)this == (uintptr_t) other) ? 0 : 1); } I can file another RFE so that we can argue about the name. The name was what we agreed upon earlier, and I showed it with primtiive_equals and primitive_hash because it provides the same sort of default pointer comparison. Please file an RFE so that this can be discussed independently of this PR. We can change them all at one time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297892748 From coleenp at openjdk.org Fri Aug 18 01:27:36 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 18 Aug 2023 01:27:36 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: <1YiY6Qz1uBsTPc7wmO-UXeGA5U_uVBSqAiVTwzCbL38=.0a720f8a-90dd-44bb-a728-9cb688db47c5@github.com> On Fri, 18 Aug 2023 00:24:07 GMT, David Holmes wrote: >> If they stay jlong returns (note that these fields are in fact int), then we need to add casting to all the callers. Casting is worse than returning the correct types. If someone wants to make these fields jlong someday then they can propagate the change to the callers. This change corrects the types. > > I don't follow. The fields are int so cast them to jlong before returning them. All the callers of these methods expect jlong so there can't be any issue there. You don't need to cast from int to jlong. The callers of these methods expect int: src/hotspot/share/services/threadService.cpp:1103:55: warning: conversion from 'jlong' {aka 'long int'} to 'int' may change value [-Wconversion] 1103 | int init_size = ThreadService::get_live_thread_count(); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ Changing int to jlong here, gets a new warning: src/hotspot/share/services/threadService.cpp:1104:54: warning: conversion from 'jlong' {aka 'long int'} to 'int' may change value [-Wconversion] 1104 | _threads_array = new GrowableArray(init_size); | ^~~~~~~~~ If you look up in the header file, the field is an int. It makes sense to return an int: static volatile int _atomic_threads_count; static volatile int _atomic_daemon_threads_count; Correcting the types means returning a type that matches the declaration so that its consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297894123 From dholmes at openjdk.org Fri Aug 18 02:10:38 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Aug 2023 02:10:38 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: <1YiY6Qz1uBsTPc7wmO-UXeGA5U_uVBSqAiVTwzCbL38=.0a720f8a-90dd-44bb-a728-9cb688db47c5@github.com> References: <1YiY6Qz1uBsTPc7wmO-UXeGA5U_uVBSqAiVTwzCbL38=.0a720f8a-90dd-44bb-a728-9cb688db47c5@github.com> Message-ID: On Fri, 18 Aug 2023 01:24:20 GMT, Coleen Phillimore wrote: >> I don't follow. The fields are int so cast them to jlong before returning them. All the callers of these methods expect jlong so there can't be any issue there. > > You don't need to cast from int to jlong. The callers of these methods expect int: > > > src/hotspot/share/services/threadService.cpp:1103:55: warning: conversion from 'jlong' {aka 'long int'} to 'int' may change value [-Wconversion] > 1103 | int init_size = ThreadService::get_live_thread_count(); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ > > > Changing int to jlong here, gets a new warning: > > > src/hotspot/share/services/threadService.cpp:1104:54: warning: conversion from 'jlong' {aka 'long int'} to 'int' may change value [-Wconversion] > 1104 | _threads_array = new GrowableArray(init_size); > | ^~~~~~~~~ > > > If you look up in the header file, the field is an int. It makes sense to return an int: > > > static volatile int _atomic_threads_count; > static volatile int _atomic_daemon_threads_count; > > > Correcting the types means returning a type that matches the declaration so that its consistent. I'd missed the GrowableArray code - the other callers expect jlong/64-bit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297911413 From dholmes at openjdk.org Fri Aug 18 02:17:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Aug 2023 02:17:27 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v8] In-Reply-To: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> References: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> Message-ID: On Thu, 17 Aug 2023 12:37:03 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > David's and Christian's review comments. Nothing further from me. Thanks! ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15233#pullrequestreview-1583727228 From dholmes at openjdk.org Fri Aug 18 02:17:29 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Aug 2023 02:17:29 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 01:20:59 GMT, Coleen Phillimore wrote: >> It is the name `primitive_compare` - I only previously saw it used for integer types. Using it with pointers seems "wrong". Don't we have to convert to `intptr_t` to compare pointers numerically anyway? > > template bool primitive_equals(const K& k0, const K& k1) { > return k0 == k1; > } > > template int primitive_compare(const K& k0, const K& k1) { > return ((k0 < k1) ? -1 : (k0 == k1) ? 0 : 1); > } > > > This is the primitive_compare we added with one of these patches. This compares pointers and because of the template, it doesn't need to look like this: > > > int Symbol::fast_compare(const Symbol* other) const { > return (((uintptr_t)this < (uintptr_t)other) ? -1 > : ((uintptr_t)this == (uintptr_t) other) ? 0 : 1); > } > > > I can file another RFE so that we can argue about the name. The name was what we agreed upon earlier, and I showed it with primtiive_equals and primitive_hash because it provides the same sort of default pointer comparison. > Please file an RFE so that this can be discussed independently of this PR. We can change them all at one time. [JDK-8314553](https://bugs.openjdk.org/browse/JDK-8314553) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1297913877 From duke at openjdk.org Fri Aug 18 04:41:25 2023 From: duke at openjdk.org (sid8606) Date: Fri, 18 Aug 2023 04:41:25 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v12] In-Reply-To: References: Message-ID: > Implementation of "Foreign Function & Memory API" for s390x (Big Endian). sid8606 has updated the pull request incrementally with two additional commits since the last revision: - Calculate the code size. - Fix missing spcaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14801/files - new: https://git.openjdk.org/jdk/pull/14801/files/a28c92d6..dad186f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=10-11 Stats: 11 lines in 3 files changed: 0 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14801.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801 PR: https://git.openjdk.org/jdk/pull/14801 From duke at openjdk.org Fri Aug 18 04:41:30 2023 From: duke at openjdk.org (sid8606) Date: Fri, 18 Aug 2023 04:41:30 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: <5j-qoK4YcY7h8xUGAGnrumzLQ3pWplhlGesEEhV6MFA=.987f91c3-e920-4b3a-b961-b54baadb758e@github.com> References: <5j-qoK4YcY7h8xUGAGnrumzLQ3pWplhlGesEEhV6MFA=.987f91c3-e920-4b3a-b961-b54baadb758e@github.com> Message-ID: On Tue, 8 Aug 2023 09:59:39 GMT, Martin Doerr wrote: >> sid8606 has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentation >> >> Signed-off-by: Sidraya > > src/hotspot/cpu/s390/downcallLinker_s390.cpp line 95: > >> 93: >> 94: static const int native_invoker_code_base_size = 384; >> 95: static const int native_invoker_size_per_args = 8; > > Sizes were taken from PPC64. Are they correct for s390? Calculated code size and rounded off as per the s390x cache line size. Thank you > src/hotspot/cpu/s390/downcallLinker_s390.cpp line 156: > >> 154: #endif >> 155: >> 156: int allocated_frame_size = 0; > > Line not needed. Fixed. Thank you > src/hotspot/cpu/s390/downcallLinker_s390.cpp line 163: > >> 161: assert(!_needs_return_buffer, "unexpected needs_return_buffer"); >> 162: RegSpiller out_reg_spiller(_output_registers); >> 163: int spill_offset = -1; > > Line not needed. Fixed. Thank you > src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 130: > >> 128: } >> 129: switch (to_reg.stack_size()) { >> 130: case 8: __ reg2mem_opt(as_Register(from_reg), Address(Z_SP, reg2offset(to_reg, out_bias)), true);break; > > Coding style: Spaces missing. Fixed. Thank you > src/hotspot/cpu/s390/upcallLinker_s390.cpp line 118: > >> 116: >> 117: static const int upcall_stub_code_base_size = 1536; // depends on GC (resolve_jobject) >> 118: static const int upcall_stub_size_per_arg = 16; // arg save & restore + move > > Again sizes from PPC64. Should be checked! Calculated code size and rounded off as per the s390x cache line size. Thank you ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994858 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994949 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994309 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994258 PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994768 From dholmes at openjdk.org Fri Aug 18 05:54:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Aug 2023 05:54:54 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily Message-ID: We combine: address os::current_stack_base(); size_t os::current_stack_size(); into void os::current_stack_base_and_size(address* stack_base, size_t* stack_size) and so avoid making two underlying system calls. The os/platform specific specializations are handled by the `current_stack_region` calls. It made sense to modify that to export the `base` directly rather than the `bottom`. In doing that change it made sense to standardise on the the style of the code used (variable names etc) to make it easier to see where the 5 different versions were the same and where they differ. Having 5 versions is unfortunate ( 3 BSD: one per arch - zero, x64, aarch64; and 2 linux: zero and everything else), but trying to combine them with ifdefs would be even worse in my opinion. In theory there should be zero functional changes here. Testing: - Tiers 1-3 - All our internal builds in tiers 1-5 - GHA Thanks. ------------- Commit messages: - Fix typo - Missing casts on BSD. - Rework current_stack_region to report the base directly, rather than bottom. - Fix return type - 8303852: current_stack_region() gets called twice unnecessarily Changes: https://git.openjdk.org/jdk/pull/15321/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303852 Stats: 260 lines in 13 files changed: 42 ins; 113 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/15321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15321/head:pull/15321 PR: https://git.openjdk.org/jdk/pull/15321 From jwaters at openjdk.org Fri Aug 18 06:42:26 2023 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 18 Aug 2023 06:42:26 GMT Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: <0q4dRwKukiB1v4hppNrykoNLmd07R9ZJtHfvsHsyirg=.d34bef16-261f-4c21-a89e-37e4a581eb43@github.com> On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) Hi Andrew, majority of the work to remove C++17 breaking code from the JDK is actually already complete, this PR cleans out the last 2 places that cannot pass C++17 (a mismatched throw specifier and a register storage class qualifier), after which the JDK is fully compilable as C++17. I had taken Mark's rejection to mean that going to C++17 is not worth a JEP, unlike JEP-347. Is this still too soon? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1683426702 From dholmes at openjdk.org Fri Aug 18 07:07:25 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Aug 2023 07:07:25 GMT Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) Hi Julian, Given the JEP was closed/rejected as being unnecessary it didn't really make sense to present this as an Implementation of the JEP. This is simply the last couple of fixes to make code C++17 clean and to switch to requiring C++17. The former seems quite reasonable to me. The latter does require further discussion and buy-in. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1683450635 From fyang at openjdk.org Fri Aug 18 07:32:31 2023 From: fyang at openjdk.org (Fei Yang) Date: Fri, 18 Aug 2023 07:32:31 GMT Subject: RFR: 8313419: Template interpreter produces no safepoint check for return bytecodes In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 13:49:55 GMT, Fredrik Bredberg wrote: > I've done basic testing on riscv64 and arm32 using Qemu, but would appreciate if @RealFYang and @bulasevich could take it for a real test drive. Hi, this has passed tier1-3 and hotspot:tier4 tests on linux-riscv64 platform. Hope that helps. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15248#issuecomment-1683487066 From stefank at openjdk.org Fri Aug 18 07:47:47 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 18 Aug 2023 07:47:47 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v51] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 19:07:36 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Move alignment-gap-clearing into allocate_array() (aarch64) > - Move header_size_in_bytes closer to length_offset_in_bytes There is something odd going on with the `arrayOopDesc::header_size()` implementation. In some configurations the array length is within the header size, but that's not always the case. This picture shows "header_size_in_bytes()" for different 64-bits configurations: ====================================== Array ======================================== ===================== Full Klass ==================== === Compressed Klass == Aligned Field Unaligned Field Auto Aligned Field +-----------------------+ +-----------------------+ +-----------------------+ | Mark 0 | | Mark 0 | | Mark 0 | +-----------------------+ +-----------------------+ +-----------------------+ | Mark 1 | | Mark 1 | | Mark 1 | +-----------------------+ +-----------------------+ +-----------------------+ | Klass 0 | | Klass 0 | | Compressed Klass | +-----------------------+ +-----------------------+ +-----------------------+ | Klass 1 | | Klass 1 | | Length | +-----------------------+ +-----------------------+ +- +-----------------------+ | Length | | Length | | | Field 0 | +-----------------------+ -+ +-----------------------+ -+ | +-----------------------+ | Gap | | | Field 0 | | | | Field 1 | +-----------------------+ | +-----------------------+ | | +-----------------------+ | Field 0 | | | Field 1 | | | +-----------------------+ | +-----------------------+ | | | Field 1 | | | Padding | | | +-----------------------+ | +-----------------------+ | | | | | +-----------------------------+-+ | +------- new arrayOopDesc::header_size_in_bytes() This looks reasonable. If I draw the same picture for `header_size()` I get this: ====================================== Array ======================================== ===================== Full Klass ==================== === Compressed Klass == Aligned Field Unaligned Field Auto Aligned Field +-----------------------+ +-----------------------+ +-----------------------+ | Mark 0 | | Mark 0 | | Mark 0 | +-----------------------+ +-----------------------+ +-----------------------+ | Mark 1 | | Mark 1 | | Mark 1 | +-----------------------+ +-----------------------+ +-----------------------+ | Klass 0 | | Klass 0 | | Compressed Klass | +-----------------------+ +-----------------------+ +-----------------------+ | Klass 1 | | Klass 1 | | Length | +-----------------------+ -+ +-----------------------+ +- +-----------------------+ | Length | | | Length | | | Field 0 | +-----------------------+ | +-----------------------+ | +-----------------------+ | Gap | | | Field 0 | | | Field 1 | +-----------------------+ | +-----------------------+ -+ | +-----------------------+ | Field 0 | | | Field 1 | | | +-----------------------+ | +-----------------------+ | | | Field 1 | | | Padding | | | +-----------------------+ | +-----------------------+ | | | | | +-----------------------------+-+ | +------- new arrayOopDesc::header_size() I've verified that this is the case by running the following gtest: TEST_VM(arrayOopDesc, header_size_in_bytes) { #ifdef _LP64 { FlagSetting fs(UseCompressedClassPointers, false); // Array length starts at 16 EXPECT_EQ(arrayOopDesc::length_offset_in_bytes(), 16); // Header size in bytes includes the length. EXPECT_EQ(arrayOopDesc::header_size_in_bytes(), 20); // arrayOopDesc::header_size implies that one of the elements are included in the header EXPECT_EQ(arrayOopDesc::header_size(T_BOOLEAN) * HeapWordSize, 24); // Without compressed oops not even the length is included in the header FlagSetting fs2(UseCompressedOops, false); EXPECT_EQ(arrayOopDesc::header_size(T_OBJECT) * HeapWordSize, 16); // With compressed oops the length and and one of the oops are included in the header FlagSetting fs3(UseCompressedOops, true); EXPECT_EQ(arrayOopDesc::header_size(T_OBJECT) * HeapWordSize, 24); } #endif } (Note: I had to turn off the assert in `header_size_in_bytes()` to get the test to work) The problem is that `header_size_in_bytes` used to return a HeapWordSize-aligned value, which allowed for a non-lossy division in the line `align_object_offset(typesize_in_bytes/HeapWordSize)`. I think this should be fixed and I think it would make sense to add complete tests for arrayOopDesc::heap_size(), similar to what you did for base_offset_in_bytes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1683504300 From stuefe at openjdk.org Fri Aug 18 08:22:35 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 18 Aug 2023 08:22:35 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 02:45:54 GMT, David Holmes wrote: > We combine: > > address os::current_stack_base(); > size_t os::current_stack_size(); > > into > > void os::current_stack_base_and_size(address* stack_base, size_t* stack_size) > > and so avoid making two underlying system calls. The os/platform specific specializations are handled by the `current_stack_region` calls. It made sense to modify that to export the `base` directly rather than the `bottom`. In doing that change it made sense to standardise on the the style of the code used (variable names etc) to make it easier to see where the 5 different versions were the same and where they differ. Having 5 versions is unfortunate ( 3 BSD: one per arch - zero, x64, aarch64; and 2 linux: zero and everything else), but trying to combine them with ifdefs would be even worse in my opinion. > > In theory there should be zero functional changes here. > > Testing: > - Tiers 1-3 > - All our internal builds in tiers 1-5 > - GHA > > Thanks. Hi David, looks good. some thoughts: - the implementations for zero and non-zero Linux are identical and could be merged. I looked at them side by side. The zero implementation looks a bit bitrotted (e.g. does not have the latest guard size adjustments) so unifying them would make zero more correct. - bsd aarch64 and x64 could be merged - the only difference is a workaround in x64 that is missing on arm, from 8020753: "JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size". That workaround claims to fix the problem of not-page-aligned stack size for the primordial thread. I just tested on my M1 arm, and the primordial thread has a stack size of 2060K (java -Xlog:os* -version), which is not page-aligned (16K pages). So either this workaround is not needed (since the JVM on M1 seems happy enough) or it is a hidden bug and we need the workaround. In both cases, we could merge both versions of current_stack_region. - the bsd zero variant is almost equal to the arm variant, so we could merge those. And then, since you equalized the interfaces of os::XX::current_stack_region() and os::get_stack_base_and_size, would it be possible to drop the former and implement the latter for the various OSes? All these are thoughts, and possibly for future RFEs. THis patch looks ok as it is too. Cheers, Thomas src/hotspot/os/linux/os_linux.cpp line 5412: > 5410: fatal("pthread_attr_getguardsize failed with error = %d", rslt); > 5411: } > 5412: bottom += guard_size; Why do we keep correcting bottom? src/hotspot/os/linux/os_linux.cpp line 5428: > 5426: } > 5427: > 5428: nit: lose some newlines? src/hotspot/os/windows/os_windows.cpp line 444: > 442: // AllocationBase. > 443: while (1) { > 444: VirtualQuery(stack_bottom+size, &minfo, sizeof(minfo)); nit: spaces around +, since you are here? ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15321#pullrequestreview-1583904296 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1298045263 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1298040841 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1298041135 From mdoerr at openjdk.org Fri Aug 18 08:22:41 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 18 Aug 2023 08:22:41 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v12] In-Reply-To: References: Message-ID: <30UqWPs530NugPVkGESGKTIwoqUlXLh4BYZsRgLkajQ=.16105e12-3aca-4ec4-bc35-472aff07f988@github.com> On Fri, 18 Aug 2023 04:41:25 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with two additional commits since the last revision: > > - Calculate the code size. > - Fix missing spcaces Thanks for cleaning it up. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1584089670 From duke at openjdk.org Fri Aug 18 09:08:31 2023 From: duke at openjdk.org (sid8606) Date: Fri, 18 Aug 2023 09:08:31 GMT Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 04:41:25 GMT, sid8606 wrote: >> Implementation of "Foreign Function & Memory API" for s390x (Big Endian). > > sid8606 has updated the pull request incrementally with two additional commits since the last revision: > > - Calculate the code size. > - Fix missing spcaces Thanks a lot for all discussions, feedback and the reviews! This was really helpful! I'm planning to integrate tomorrow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1683601556 From cstein at openjdk.org Fri Aug 18 09:53:48 2023 From: cstein at openjdk.org (Christian Stein) Date: Fri, 18 Aug 2023 09:53:48 GMT Subject: RFR: 8314495: Update to use jtreg 7.3.1 Message-ID: Please review the change to update to using jtreg 7.3,1. The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda This change set also fixes: - https://bugs.openjdk.org/browse/JDK-8313902 - https://bugs.openjdk.org/browse/JDK-8313903 Testing: _tier1-tier5 pending..._ ------------- Commit messages: - Un-problem-list tests failing with jtreg 7.3 - 8314495: Update to use jtreg 7.3.1 Changes: https://git.openjdk.org/jdk/pull/15323/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15323&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314495 Stats: 12 lines in 9 files changed: 0 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/15323.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15323/head:pull/15323 PR: https://git.openjdk.org/jdk/pull/15323 From dholmes at openjdk.org Fri Aug 18 09:53:48 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Aug 2023 09:53:48 GMT Subject: RFR: 8314495: Update to use jtreg 7.3.1 In-Reply-To: References: Message-ID: <4iFRb_Qh7PqBCUiY84xDyDOK7GzCXKDCKyz6eBwIBZI=.387bf6ce-d2f2-481f-9a38-74f97629828d@github.com> On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.3,1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda > > This change set also fixes: > - https://bugs.openjdk.org/browse/JDK-8313902 > - https://bugs.openjdk.org/browse/JDK-8313903 > > Testing: _tier1-tier5 pending..._ Looks good to me! Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1582016262 From jsjolen at openjdk.org Fri Aug 18 10:45:38 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 18 Aug 2023 10:45:38 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it Message-ID: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Given some `GrowableArray` where `E` is non-copyable with a move constructor then currently this will fail to compile. This is because `GrowableArray`'s expand and shrink calls the copy constructor. We cast the values to rvalues (akin to `std::move`) to instead call the move constructor if available. If there is no move constructor but there is a copy constructor, then that will be called instead. ------------- Commit messages: - Move - do not copy Changes: https://git.openjdk.org/jdk/pull/15344/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15344&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314571 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15344.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15344/head:pull/15344 PR: https://git.openjdk.org/jdk/pull/15344 From eastigeevich at openjdk.org Fri Aug 18 12:00:31 2023 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 18 Aug 2023 12:00:31 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v6] In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 18:56:36 GMT, Boris Ulasevich wrote: >> This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 >> >> The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. >> >> InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: >> >> >> Cortex-A53 (Pi 3 Model B Rev 1.2) >> >> test1stInt2Types 37.5 37.358 0.38 >> test1stInt3Types 160.166 148.04 8.19 >> test1stInt5Types 158.131 147.955 6.88 >> test2ndInt2Types 52.634 53.291 -1.23 >> test2ndInt3Types 201.39 181.603 10.90 >> test2ndInt5Types 195.722 176.707 10.76 >> testIfaceCall 157.453 140.498 12.07 >> testIfaceExtCall 175.46 154.351 13.68 >> testMonomorphic 32.052 32.039 0.04 >> AVG: 6.85 >> >> Cortex-A72 (Pi 4 Model B Rev 1.2) >> >> test1stInt2Types 27.4796 27.4738 0.02 >> test1stInt3Types 66.0085 64.9374 1.65 >> test1stInt5Types 67.9812 66.2316 2.64 >> test2ndInt2Types 32.0581 32.062 -0.01 >> test2ndInt3Types 68.2715 65.6643 3.97 >> test2ndInt5Types 68.1012 65.8024 3.49 >> testIfaceCall 64.0684 64.1811 -0.18 >> testIfaceExtCall 91.6226 81.5867 12.30 >> testMonomorphic 26.7161 26.7142 0.01 >> AVG: 2.66 >> >> Neoverse N1 (m6g.metal) >> >> test1stInt2Types 2.9104 2.9086 0.06 >> test1stInt3Types 10.9642 10.2909 6.54 >> test1stInt5Types 10.9607 10.2856 6.56 >> test2ndInt2Types 3.3410 3.3478 -0.20 >> test2ndInt3Types 12.3291 11.3089 9.02 >> test2ndInt5Types 12.328 11.2704 9.38 >> testIfaceCall 11.0598 10.3657 6.70 >> testIfaceExtCall 13.0692 11.2826 15.84 >> testMonomorphic 2.2354 2.2341 0.06 >> AVG: 6.00 >> >> Neoverse V1 (c7g.2xlarge) >> >> test1stInt2Types 2.2317 2.2320 -0.01 >> test1stInt3Types 6.6884 6.1911 8.03 >> test1stInt5Types 6.7334 6.2193 8.27 >> test2ndInt2Types 2.4002 2.4013 -0.04 >> test2ndInt3Types 7.9603 7.0372 13.12 >> test2ndInt5Types 7.9532 7.0474 12.85 >> testIfaceCall 6.7028 6.3272 5.94 >> testIfaceExtCall 8.3253 6.941... > > Boris Ulasevich 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: > > rework loop_scan_resolved_entry cycle as proposed LGTM. Thanks for the great job. ------------- Marked as reviewed by eastigeevich (Committer). PR Review: https://git.openjdk.org/jdk/pull/13792#pullrequestreview-1584437000 From coleenp at openjdk.org Fri Aug 18 12:08:38 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 18 Aug 2023 12:08:38 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v8] In-Reply-To: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> References: <6lWy0WgbwhAWEcM00khsUXjHHBGm5G50K-7i5nS5VCc=.b2ff2329-5238-48d0-89be-4481d95db323@github.com> Message-ID: On Thu, 17 Aug 2023 12:37:03 GMT, Coleen Phillimore wrote: >> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > David's and Christian's review comments. Thanks David, Thomas, Christian and Dean for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15233#issuecomment-1683820346 From coleenp at openjdk.org Fri Aug 18 12:08:40 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 18 Aug 2023 12:08:40 GMT Subject: RFR: 8314265: Fix -Wconversion warnings in miscellaneous runtime code [v6] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 02:13:57 GMT, David Holmes wrote: >> template bool primitive_equals(const K& k0, const K& k1) { >> return k0 == k1; >> } >> >> template int primitive_compare(const K& k0, const K& k1) { >> return ((k0 < k1) ? -1 : (k0 == k1) ? 0 : 1); >> } >> >> >> This is the primitive_compare we added with one of these patches. This compares pointers and because of the template, it doesn't need to look like this: >> >> >> int Symbol::fast_compare(const Symbol* other) const { >> return (((uintptr_t)this < (uintptr_t)other) ? -1 >> : ((uintptr_t)this == (uintptr_t) other) ? 0 : 1); >> } >> >> >> I can file another RFE so that we can argue about the name. The name was what we agreed upon earlier, and I showed it with primtiive_equals and primitive_hash because it provides the same sort of default pointer comparison. >> Please file an RFE so that this can be discussed independently of this PR. We can change them all at one time. > > [JDK-8314553](https://bugs.openjdk.org/browse/JDK-8314553) Thanks for the RFE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1298372237 From coleenp at openjdk.org Fri Aug 18 12:08:42 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 18 Aug 2023 12:08:42 GMT Subject: Integrated: 8314265: Fix -Wconversion warnings in miscellaneous runtime code In-Reply-To: References: Message-ID: <-ze11mlDWyrmaiIJkMNob9liKabCGPkwQTwf3f5AozE=.107ec404-488a-4a36-8589-a63cdc1ee012@github.com> On Thu, 10 Aug 2023 20:31:20 GMT, Coleen Phillimore wrote: > Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion warnings in runtime code. This is the last one I'm going to do for runtime for a while. > Tested with tier1-4. This pull request has now been integrated. Changeset: 75212111 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/752121114f424d8e673ee8b7bb85f7705a82b9cc Stats: 92 lines in 35 files changed: 5 ins; 3 del; 84 mod 8314265: Fix -Wconversion warnings in miscellaneous runtime code Reviewed-by: stuefe, dholmes, chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/15233 From fbredberg at openjdk.org Fri Aug 18 12:14:30 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 18 Aug 2023 12:14:30 GMT Subject: RFR: 8313419: Template interpreter produces no safepoint check for return bytecodes In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 16:57:17 GMT, Patricio Chilano Mateo wrote: >> The template interpreter produces a safepoint check for return bytecodes (TemplateTable::_return(TosState state)) on x86, ppc64le and s390, but not on aarch64, arm32, and riscv64. >> >> This PR adds the missing safepoint check to aarch64, arm32, and riscv64. >> >> Tested tier1-tier7 on aarch64. Both arm32, and riscv64 was sanity tested using Qemu. > > src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 2206: > >> 2204: __ push(state); >> 2205: __ push_cont_fastpath(rthread); >> 2206: __ call_VM(noreg, CAST_FROM_FN_PTR(address, InterpreterRuntime::at_safepoint)); > > Looking at the code generated for the existing safepoint poll (`TemplateInterpreterGenerator::generate_safept_entry_for()`) I see we add a full memory barrier after the return from `InterpreterRuntime::at_safepoint()`. That would call for adding it here too although I don't see why we need that. The SafepointMechanism logic already executes the proper barriers after we process pending operations. Same thing for riscv. That's an interesting find. I had a discussion with Erik (@fisk), and as you he didn't see any reason why it should be needed. He also very much doubted the need for the membar in `TemplateInterpreterGenerator::generate_safept_entry_for()`. In my view x86 is quite forgiving if you forget to add a membar, but PowerPC tend not to be. Since there's no membar in `generate_safept_entry_for()` on PowerPC and it still works ok, it does seem like it's not needed. So, for this reason I will not add any additional membar. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15248#discussion_r1298378973 From erikj at openjdk.org Fri Aug 18 12:16:28 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 18 Aug 2023 12:16:28 GMT Subject: RFR: 8314495: Update to use jtreg 7.3.1 In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.3,1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda > > This change set also fixes: > - https://bugs.openjdk.org/browse/JDK-8313902 > - https://bugs.openjdk.org/browse/JDK-8313903 > > Testing: _tier1-tier5 pending..._ Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1584457571 From fbredberg at openjdk.org Fri Aug 18 12:30:35 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 18 Aug 2023 12:30:35 GMT Subject: RFR: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames [v3] In-Reply-To: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> References: <_M3c_UqSn78VRYrgoiN_bHVuMY3GFyNR06FRwpWSM6M=.df9c034d-8671-4b1e-a497-ea13781bdf41@github.com> Message-ID: <6gWoi0Ia5N9QanNQWENw5XGygFrCQn1XAXHZvI1WnOU=.97f04542-644f-4782-867a-24fc1a05054b@github.com> On Tue, 15 Aug 2023 12:01:41 GMT, Fredrik Bredberg wrote: >> Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. >> Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. >> >> By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. >> >> This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. >> >> Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Removed the on_heap parameter from FrameValues::print_on Thank you guys for review comments, and the help with testing. If no one else has anything to add, I'll integrate (as soon as I can convince a sponsor). ------------- PR Comment: https://git.openjdk.org/jdk/pull/14545#issuecomment-1683845960 From fbredberg at openjdk.org Fri Aug 18 12:34:26 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 18 Aug 2023 12:34:26 GMT Subject: RFR: 8313419: Template interpreter produces no safepoint check for return bytecodes In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 13:22:19 GMT, Fredrik Bredberg wrote: > The template interpreter produces a safepoint check for return bytecodes (TemplateTable::_return(TosState state)) on x86, ppc64le and s390, but not on aarch64, arm32, and riscv64. > > This PR adds the missing safepoint check to aarch64, arm32, and riscv64. > > Tested tier1-tier7 on aarch64. Both arm32, and riscv64 was sanity tested using Qemu. Thank you guys for review comments, and the help with testing. If no one else has anything to add, I'll integrate (as soon as I can convince a sponsor). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15248#issuecomment-1683852442 From duke at openjdk.org Fri Aug 18 13:08:28 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Fri, 18 Aug 2023 13:08:28 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v2] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 06:49:26 GMT, Fei Yang wrote: >> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: >> >> Change fsgnj_d(dst, src, src) to fmv_d(dst, src) > > src/hotspot/cpu/riscv/riscv.ad line 7706: > >> 7704: match(Set dst (RoundDoubleMode src rmode)); >> 7705: ins_cost(2 * XFER_COST + BRANCH_COST); >> 7706: effect(TEMP_DEF dst, TEMP tmp1, TEMP tmp2, TEMP tmp3, KILL cr); > > Do we kill `cr` anywhere in the assembly code? According to documentation we have situations when convert instruction can set an error flag in the status register: > All floating-point conversion instructions set the Inexact exception flag if the rounded result differs from the operand value and the Invalid exception flag is not set. [1] [1] https://five-embeddev.com/riscv-isa-manual/latest/f.html#single-precision-floating-point-conversion-and-move-instructions ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1298430830 From stefank at openjdk.org Fri Aug 18 13:51:36 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 18 Aug 2023 13:51:36 GMT Subject: RFR: 8305898: Alternative self-forwarding mechanism [v19] In-Reply-To: <9KKpqN3GBvUxwDZPz68AmuWoTTGglMX9fK7iMZ74fPA=.03ac87b0-b3e2-4b88-9509-8940c4cd21a7@github.com> References: <9KKpqN3GBvUxwDZPz68AmuWoTTGglMX9fK7iMZ74fPA=.03ac87b0-b3e2-4b88-9509-8940c4cd21a7@github.com> Message-ID: On Fri, 11 Aug 2023 18:40:36 GMT, Roman Kennke wrote: >> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers, when compaction fails, to indicate that the object has been looked at, but failed compaction into to-space. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the bit #3 (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored. > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - Merge branch 'JDK-8305896' into JDK-8305898 > - Merge branch 'JDK-8305896' into JDK-8305898 > - Merge branch 'JDK-8305896' into JDK-8305898 > - Update comment about mark-word layout > - Merge branch 'JDK-8305896' into JDK-8305898 > - Fix tests on 32bit builds > - Merge branch 'JDK-8305896' into JDK-8305898 > - Merge branch 'JDK-8305896' into JDK-8305898 > - wqRevert "Rename self-forwarded -> forward-failed" > > This reverts commit 4d9713ca239da8e294c63887426bfb97240d3130. > - Merge branch 'JDK-8305896' into JDK-8305898 > - ... and 21 more: https://git.openjdk.org/jdk/compare/d2b41e25...cd5f2374 src/hotspot/share/oops/oop.inline.hpp line 292: > 290: m = m.set_self_forwarded(); > 291: assert(forwardee(m) == cast_to_oop(this), "encoding must be reversible"); > 292: set_mark(m); Could you explain why we need to restore the displaced mark word here? I wonder why it matters what the old mark word is and why this code can't be changed to something like this: markWord m = markWord::prototype().set_self_forwarded(); set_mark(m); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13779#discussion_r1298475144 From fbredberg at openjdk.org Fri Aug 18 14:32:41 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 18 Aug 2023 14:32:41 GMT Subject: Integrated: 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames In-Reply-To: References: Message-ID: On Mon, 19 Jun 2023 15:59:15 GMT, Fredrik Bredberg wrote: > Implementation of relativized last_sp (top_frame_sp on PowerPC) in interpreter frames for x64, aarch64, ppc64le and riscv. > Not relativized last_sp on arm, zero and s390 but done some changes to cope with the changed generic code. > > By changing the "last_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "last_sp" (and its close equivalent "top_frame_sp" on PowerPC). The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on supported platforms. The rest was sanity tested using Qemu. This pull request has now been integrated. Changeset: c36e0097 Author: Fredrik Bredberg Committer: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/c36e009772823c58a62fd2d45bbcc1390c4975ad Stats: 110 lines in 25 files changed: 62 ins; 3 del; 45 mod 8308984: Relativize last_sp (and top_frame_sp) in interpreter frames Reviewed-by: pchilanomate, aph, haosun ------------- PR: https://git.openjdk.org/jdk/pull/14545 From fbredberg at openjdk.org Fri Aug 18 14:36:37 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 18 Aug 2023 14:36:37 GMT Subject: Integrated: 8313419: Template interpreter produces no safepoint check for return bytecodes In-Reply-To: References: Message-ID: On Fri, 11 Aug 2023 13:22:19 GMT, Fredrik Bredberg wrote: > The template interpreter produces a safepoint check for return bytecodes (TemplateTable::_return(TosState state)) on x86, ppc64le and s390, but not on aarch64, arm32, and riscv64. > > This PR adds the missing safepoint check to aarch64, arm32, and riscv64. > > Tested tier1-tier7 on aarch64. Both arm32, and riscv64 was sanity tested using Qemu. This pull request has now been integrated. Changeset: bcba5e97 Author: Fredrik Bredberg Committer: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/bcba5e97857fd57ea4571341ad40194bb823cd0b Stats: 35 lines in 3 files changed: 35 ins; 0 del; 0 mod 8313419: Template interpreter produces no safepoint check for return bytecodes Reviewed-by: pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/15248 From aboldtch at openjdk.org Fri Aug 18 14:42:47 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 18 Aug 2023 14:42:47 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v51] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 19:07:36 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Move alignment-gap-clearing into allocate_array() (aarch64) > - Move header_size_in_bytes closer to length_offset_in_bytes https://github.com/openjdk/jdk/commit/b1f76655514c0371b10748f05ba9596ff38ee56c I had a look at this and tried to move the whole payload initialisation into `initialize_body`. This makes the C1 changes more one-to-one with how the runtime allocates. That is, make `initialize_header` do what the `ObjArrayAllocator` would do with `do_zero = false`. Which is to initialise the Object up to `arrayOopDesc::header_size_in_bytes()`. Then have `initialize_body` initialise `base_offset_in_bytes` to the end of the object, leaving the potential alignment gap uninitialised. It is curious that we align the end to the padding instead of the smallest word containing the payload and just leave the end padding uninitialised like with the header gap. But I guess running with larger than BytesPerWord MinObjectAlignment is not common (on 64bit). There are also some mismatches in the current pr between parameter names in the header files and cpp files. Which I fixed. https://github.com/openjdk/jdk/commit/844bd7e6390caf42aad1b4eef9d1adfd3df66b2e I also looked at rewriting the ZObjArrayAllocator so that the extra unaligned write is only done for the segmented case as the normal call to `ObjArrayAllocator::initialize(mem);` already handles it. All patches, includes some more things I'm testing on-top of this. https://github.com/openjdk/jdk/compare/pr/11044...xmas92:jdk:array_align_testing ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1684019678 From jsjolen at openjdk.org Fri Aug 18 16:15:25 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 18 Aug 2023 16:15:25 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it In-Reply-To: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: On Fri, 18 Aug 2023 10:39:28 GMT, Johan Sj?len wrote: > Given some `GrowableArray` where `E` is non-copyable with a move constructor will currently fail to compile. This is because `GrowableArray`'s expand and shrink calls the copy constructor. We cast the values to rvalues (akin to `std::move`) to instead call the move constructor if available. If there is no move constructor but there is a copy constructor, then that will be called instead. Passes tier1, tier2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15344#issuecomment-1684138167 From rkennke at openjdk.org Fri Aug 18 16:23:47 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 18 Aug 2023 16:23:47 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v51] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 07:44:41 GMT, Stefan Karlsson wrote: > There is something odd going on with the `arrayOopDesc::header_size()` implementation. In some configurations the array length is within the header size, but that's not always the case. > > This picture shows "header_size_in_bytes()" for different 64-bits configurations: > > ``` > ====================================== Array ======================================== > ===================== Full Klass ==================== === Compressed Klass == > Aligned Field Unaligned Field Auto Aligned Field > +-----------------------+ +-----------------------+ +-----------------------+ > | Mark 0 | | Mark 0 | | Mark 0 | > +-----------------------+ +-----------------------+ +-----------------------+ > | Mark 1 | | Mark 1 | | Mark 1 | > +-----------------------+ +-----------------------+ +-----------------------+ > | Klass 0 | | Klass 0 | | Compressed Klass | > +-----------------------+ +-----------------------+ +-----------------------+ > | Klass 1 | | Klass 1 | | Length | > +-----------------------+ +-----------------------+ +- +-----------------------+ > | Length | | Length | | | Field 0 | > +-----------------------+ -+ +-----------------------+ -+ | +-----------------------+ > | Gap | | | Field 0 | | | | Field 1 | > +-----------------------+ | +-----------------------+ | | +-----------------------+ > | Field 0 | | | Field 1 | | | > +-----------------------+ | +-----------------------+ | | > | Field 1 | | | Padding | | | > +-----------------------+ | +-----------------------+ | | > | | | > +-----------------------------+-+ > | > +------- new arrayOopDesc::header_size_in_bytes() > ``` > > This looks reasonable. If I draw the same picture for `header_size()` I get this: > > ``` > ====================================== Array ======================================== > ===================== Full Klass ==================== === Compressed Klass == > Aligned Field Unaligned Field Auto Aligned Field > +-----------------------+ +-----------------------+ +-----------------------+ > | Mark 0 | | Mark 0 | | Mark 0 | > +-----------------------+ +-----------------------+ +-----------------------+ > | Mark 1 | | Mark 1 | | Mark 1 | > +-----------------------+ +-----------------------+ +-----------------------+ > | Klass 0 | | Klass 0 | | Compressed Klass | > +-----------------------+ +-----------------------+ +-----------------------+ > | Klass 1 | | Klass 1 | | Length | > +-----------------------+ -+ +-----------------------+ +- +-----------------------+ > | Length | | | Length | | | Field 0 | > +-----------------------+ | +-----------------------+ | +-----------------------+ > | Gap | | | Field 0 | | | Field 1 | > +-----------------------+ | +-----------------------+ -+ | +-----------------------+ > | Field 0 | | | Field 1 | | | > +-----------------------+ | +-----------------------+ | | > | Field 1 | | | Padding | | | > +-----------------------+ | +-----------------------+ | | > | | | > +-----------------------------+-+ > | > +------- new arrayOopDesc::header_size() > ``` > > I've verified that this is the case by running the following gtest: > > ``` > TEST_VM(arrayOopDesc, header_size_in_bytes) { > #ifdef _LP64 > { > FlagSetting fs(UseCompressedClassPointers, false); > // Array length starts at 16 > EXPECT_EQ(arrayOopDesc::length_offset_in_bytes(), 16); > > // Header size in bytes includes the length. > EXPECT_EQ(arrayOopDesc::header_size_in_bytes(), 20); > > // arrayOopDesc::header_size implies that one of the elements are included in the header > EXPECT_EQ(arrayOopDesc::header_size(T_BOOLEAN) * HeapWordSize, 24); > > // Without compressed oops not even the length is included in the header > FlagSetting fs2(UseCompressedOops, false); > EXPECT_EQ(arrayOopDesc::header_size(T_OBJECT) * HeapWordSize, 16); > > // With compressed oops the length and and one of the oops are included in the header > FlagSetting fs3(UseCompressedOops, true); > EXPECT_EQ(arrayOopDesc::header_size(T_OBJECT) * HeapWordSize, 24); > } > #endif > } > ``` > > (Note: I had to turn off the assert in `header_size_in_bytes()` to get the test to work) > > The problem is that `header_size_in_bytes` used to return a HeapWordSize-aligned value, which allowed for a non-lossy division in the line `align_object_offset(typesize_in_bytes/HeapWordSize)`. > > I think this should be fixed and I think it would make sense to add complete tests for arrayOopDesc::heap_size(), similar to what you did for base_offset_in_bytes. Thanks, Stefan for checking this. Yes, arrayOop::header_size() is confusing. The only purpose of this method is to help a few code paths which need the header_size_in_bytes() to be aligned-up and converted to word-size. Not quite sure how to deal with it. Move it out to some different place? Name it differently? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1684147706 From iris at openjdk.org Fri Aug 18 18:39:25 2023 From: iris at openjdk.org (Iris Clark) Date: Fri, 18 Aug 2023 18:39:25 GMT Subject: RFR: 8314495: Update to use jtreg 7.3.1 In-Reply-To: References: Message-ID: <3efOFjO6mEklYsdbGon5OWAsK7ffNDSd-lpSzMHnjCk=.264978af-605d-4943-ad17-e50dcb9b1416@github.com> On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.3,1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda > > This change set also fixes: > - https://bugs.openjdk.org/browse/JDK-8313902 > - https://bugs.openjdk.org/browse/JDK-8313903 > > Testing: tier1-tier5 OK Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1585041001 From jwaters at openjdk.org Sat Aug 19 06:56:43 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 19 Aug 2023 06:56:43 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Document changes in awt_DnDDS.cpp Bumping, anyone from security? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1684866389 From kbarrett at openjdk.org Sat Aug 19 07:20:27 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 19 Aug 2023 07:20:27 GMT Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) Changes requested by kbarrett (Reviewer). There may be other changes needed either in preparation or as part of making the change to the language version. - Dynamic allocation of over-aligned types is supported in C++17. We might need to update our allocation base classes (like CHeapObj<>) to account for this as part of the update. I'm not sure it can be deferred to a separate followup. - C++17 exception specifications are part of the type system. "Valid C++14 code may fail to compile or produce different results ..." This needs to be looked at before changing the language selection switch. - Dynamic exception specifications were previously deprecated, and are removed by C++17. It looks like some compilers are still permitting the no-throw case, but we might need to convert to using noexcept before changing the language selection switch. There may be others that I've forgotten or haven't noticed. make/autoconf/flags-cflags.m4 line 577: > 575: # CXXFLAGS C++ language level for all of JDK, including Hotspot. > 576: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang || test "x$TOOLCHAIN_TYPE" = xxlc; then > 577: LANGSTD_CXXFLAGS="-std=c++17" No, this change cannot be made yet. As noted in the prior JEP discussion, we need to wait for the aix-ppc port maintainers to upgrade the compiler they are using. I happened to check last with them about their progress. While progress has been made, they are not yet ready to throw that switch. Hoping to finish that work sometime this fall. ------------- PR Review: https://git.openjdk.org/jdk/pull/14988#pullrequestreview-1585595153 PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1684875974 PR Review Comment: https://git.openjdk.org/jdk/pull/14988#discussion_r1299140565 From kbarrett at openjdk.org Sat Aug 19 07:23:29 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 19 Aug 2023 07:23:29 GMT Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) This change needs to be motivated. One way to do that would be to file CRs to change the style guide to permit various features. Label them with `cpp17`. Discuss them prior to making the language change, describing why they are important. A sufficient set of such provides an argument for making the language change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1684876746 From aph at openjdk.org Sat Aug 19 07:48:28 2023 From: aph at openjdk.org (Andrew Haley) Date: Sat, 19 Aug 2023 07:48:28 GMT Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: On Sat, 19 Aug 2023 07:20:15 GMT, Kim Barrett wrote: > This change needs to be motivated. One way to do that would be to file CRs to change the style guide to permit various features. Label them with `cpp17`. Discuss them prior to making the language change, describing why they are important. A sufficient set of such provides an argument for making the language change. Is it impractical to drop the obsolete features of C++11, working in the common subset of C++11 and C++17? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14988#issuecomment-1684883361 From qamai at openjdk.org Sat Aug 19 10:07:28 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 19 Aug 2023 10:07:28 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it In-Reply-To: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: On Fri, 18 Aug 2023 10:39:28 GMT, Johan Sj?len wrote: > Given some `GrowableArray` where `E` is non-copyable with a move constructor will currently fail to compile. This is because `GrowableArray`'s expand and shrink calls the copy constructor. We cast the values to rvalues (akin to `std::move`) to instead call the move constructor if available. If there is no move constructor but there is a copy constructor, then that will be called instead. src/hotspot/share/utilities/growableArray.hpp line 545: > 543: if (len > 0) { > 544: new_data = static_cast(this)->allocate(); > 545: for (int i = 0; i < len; ++i) ::new (&new_data[i]) E(static_cast(old_data[i])); Why not use `std::move`? Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15344#discussion_r1299166458 From jsjolen at openjdk.org Sat Aug 19 23:45:27 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 19 Aug 2023 23:45:27 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it In-Reply-To: References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: On Sat, 19 Aug 2023 10:04:36 GMT, Quan Anh Mai wrote: >> Given some `GrowableArray` where `E` is non-copyable with a move constructor will currently fail to compile. This is because `GrowableArray`'s expand and shrink calls the copy constructor. We cast the values to rvalues (akin to `std::move`) to instead call the move constructor if available. If there is no move constructor but there is a copy constructor, then that will be called instead. > > src/hotspot/share/utilities/growableArray.hpp line 545: > >> 543: if (len > 0) { >> 544: new_data = static_cast(this)->allocate(); >> 545: for (int i = 0; i < len; ++i) ::new (&new_data[i]) E(static_cast(old_data[i])); > > Why not use `std::move`? Thanks. Hi, in short: Yes, I believe that I can switch and that `std::move` is better. In long: I can't find any mention of `std::move` not being allowed in the style guide, using it seems to be in the same spirit as other std library usage (`#include ` for example) and since it is just a better version of what I wrote here let's do the switch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15344#discussion_r1299279909 From qamai at openjdk.org Sun Aug 20 06:14:31 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 20 Aug 2023 06:14:31 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it In-Reply-To: References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: On Sat, 19 Aug 2023 23:42:32 GMT, Johan Sj?len wrote: >> src/hotspot/share/utilities/growableArray.hpp line 545: >> >>> 543: if (len > 0) { >>> 544: new_data = static_cast(this)->allocate(); >>> 545: for (int i = 0; i < len; ++i) ::new (&new_data[i]) E(static_cast(old_data[i])); >> >> Why not use `std::move`? Thanks. > > Hi, in short: Yes, I believe that I can switch and that `std::move` is better. > > In long: I can't find any mention of `std::move` not being allowed in the style guide, using it seems to be in the same spirit as other std library usage (`#include ` for example) and since it is just a better version of what I wrote here let's do the switch. I believe "Rvalue references and move semantics" falls under the "Undecided Features" category. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15344#discussion_r1299310750 From jpai at openjdk.org Sun Aug 20 06:58:36 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 20 Aug 2023 06:58:36 GMT Subject: RFR: 8314495: Update to use jtreg 7.3.1 In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.3,1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda > > This change set also fixes: > - https://bugs.openjdk.org/browse/JDK-8313902 > - https://bugs.openjdk.org/browse/JDK-8313903 > > Testing: tier1-tier5 OK Looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1585812406 From iwalulya at openjdk.org Sun Aug 20 10:12:34 2023 From: iwalulya at openjdk.org (Ivan Walulya) Date: Sun, 20 Aug 2023 10:12:34 GMT Subject: Withdrawn: 8314406: Provide a shared doubly LinkedList implementation In-Reply-To: References: Message-ID: On Wed, 16 Aug 2023 15:49:39 GMT, Ivan Walulya wrote: > Hi all, > > Please review this refactoring change to move the ZGC ZList to utilities. Mainly code motion with addition of the necessary tests. > > Another notable change is allowing the List elements to exist in multiple lists at the same time. > > Testing: > - Linux x86_64 fastdebug `gtest:all`. > - Mach5 GTestWrapper > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15312 From dholmes at openjdk.org Sun Aug 20 22:39:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 20 Aug 2023 22:39:54 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily [v2] In-Reply-To: References: Message-ID: > We combine: > > address os::current_stack_base(); > size_t os::current_stack_size(); > > into > > void os::current_stack_base_and_size(address* stack_base, size_t* stack_size) > > and so avoid making two underlying system calls. The os/platform specific specializations are handled by the `current_stack_region` calls. It made sense to modify that to export the `base` directly rather than the `bottom`. In doing that change it made sense to standardise on the the style of the code used (variable names etc) to make it easier to see where the 5 different versions were the same and where they differ. Having 5 versions is unfortunate ( 3 BSD: one per arch - zero, x64, aarch64; and 2 linux: zero and everything else), but trying to combine them with ifdefs would be even worse in my opinion. > > In theory there should be zero functional changes here. > > Testing: > - Tiers 1-3 > - All our internal builds in tiers 1-5 > - GHA > > Thanks. David Holmes has updated the pull request incrementally with two additional commits since the last revision: - Excess newlines - Add spaces around operator ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15321/files - new: https://git.openjdk.org/jdk/pull/15321/files/434fdb99..bc7a94ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15321&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15321&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15321/head:pull/15321 PR: https://git.openjdk.org/jdk/pull/15321 From dholmes at openjdk.org Sun Aug 20 22:39:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 20 Aug 2023 22:39:54 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily [v2] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 06:12:44 GMT, Thomas Stuefe wrote: >> David Holmes has updated the pull request incrementally with two additional commits since the last revision: >> >> - Excess newlines >> - Add spaces around operator > > src/hotspot/os/linux/os_linux.cpp line 5412: > >> 5410: fatal("pthread_attr_getguardsize failed with error = %d", rslt); >> 5411: } >> 5412: bottom += guard_size; > > Why do we keep correcting bottom? So we can check it in the assert at the end. > src/hotspot/os/linux/os_linux.cpp line 5428: > >> 5426: } >> 5427: >> 5428: > > nit: lose some newlines? Done > src/hotspot/os/windows/os_windows.cpp line 444: > >> 442: // AllocationBase. >> 443: while (1) { >> 444: VirtualQuery(stack_bottom+size, &minfo, sizeof(minfo)); > > nit: spaces around +, since you are here? Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1299444812 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1299445095 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1299444992 From dholmes at openjdk.org Sun Aug 20 22:55:25 2023 From: dholmes at openjdk.org (David Holmes) Date: Sun, 20 Aug 2023 22:55:25 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily [v2] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 08:20:08 GMT, Thomas Stuefe wrote: >> David Holmes has updated the pull request incrementally with two additional commits since the last revision: >> >> - Excess newlines >> - Add spaces around operator > > Hi David, > > looks good. > > some thoughts: > > - the implementations for zero and non-zero Linux are identical and could be merged. I looked at them side by side. The zero implementation looks a bit bitrotted (e.g. does not have the latest guard size adjustments) so unifying them would make zero more correct. > > - bsd aarch64 and x64 could be merged - the only difference is a workaround in x64 that is missing on arm, from 8020753: "JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size". That workaround claims to fix the problem of not-page-aligned stack size for the primordial thread. I just tested on my M1 arm, and the primordial thread has a stack size of 2060K (java -Xlog:os* -version), which is not page-aligned (16K pages). So either this workaround is not needed (since the JVM on M1 seems happy enough) or it is a hidden bug and we need the workaround. In both cases, we could merge both versions of current_stack_region. > - the bsd zero variant is almost equal to the arm variant, so we could merge those. > > And then, since you equalized the interfaces of os::XX::current_stack_region() and os::get_stack_base_and_size, would it be possible to drop the former and implement the latter for the various OSes? > > All these are thoughts, and possibly for future RFEs. THis patch looks ok as it is too. > > Cheers, Thomas Thanks for looking at this @tstuefe - as I noted I didn't try to merge things further as I thought it would makes things more complex. But to address your specific points: > the implementations for zero and non-zero Linux are identical and could be merged. But as you then state they are not actually identical because zero is missing some of the guard page checks. But zero also has the IA64 code which causes a subtle change in the way size needs to be adjusted. So they are not the same and while they could potentially be merged I much prefer zero code to be kept isolated to zero so that the folks interested in zero can deal with it. > bsd aarch64 and x64 could be merged - the only difference is a workaround in x64 that is missing on arm, from 8020753 I did wonder about that workaround but it was not something I wanted to touch in this PR. If it is not needed afterall, or actually needed on Aarch64 then that is something for a different RFE (or actual bug if the workaround is needed on aarch64). > the bsd zero variant is almost equal to the arm variant, so we could merge those. Again I like to see zero code isolated, but in addition there is nowhere to put such code except in the shared os_bsd.cpp and then have it ifdef'd out for x86. That said, if the x86 and aarch64 should be the same then yes we could have a single shared version. But again future RFE (I will file one). > And then, since you equalized the interfaces of os::XX::current_stack_region() and os::get_stack_base_and_size, would it be possible to drop the former and implement the latter for the various OSes? Yes I think it can. The arch specific versions would just be moved to os namespace instead, and no shared implementation just to redirect to the arch-specific ones. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15321#issuecomment-1685417382 From gcao at openjdk.org Mon Aug 21 02:08:45 2023 From: gcao at openjdk.org (Gui Cao) Date: Mon, 21 Aug 2023 02:08:45 GMT Subject: RFR: 8314618: RISC-V: -XX:MaxVectorSize does not work as expected Message-ID: Hi all, we found that when the specified -XX:MaxVectorSize=16 no bigger than the detected _initial_vector_length=32, it causes the MaxVectorSize to be set incorrectly. MaxVectorSize is updated in src/hotspot/cpu/riscv/vm_version_riscv.cpp#VM_Version::c2_initialize(). if (UseRVV) { if (FLAG_IS_DEFAULT(MaxVectorSize)) { MaxVectorSize = _initial_vector_length; } else if (MaxVectorSize < 16) { warning("RVV does not support vector length less than 16 bytes. Disabling RVV."); UseRVV = false; } else if (is_power_of_2(MaxVectorSize)) { if (MaxVectorSize > _initial_vector_length) { warning("Current system only supports max RVV vector length %d. Set MaxVectorSize to %d", _initial_vector_length, _initial_vector_length); } MaxVectorSize = _initial_vector_length; } else { vm_exit_during_initialization(err_msg("Unsupported MaxVectorSize: %d", (int)MaxVectorSize)); } } It's that RISC-V only supports max-width vectorization at first, so it's unconditionally set to hardware max-width here. However, after https://github.com/openjdk/jdk/commit/43c71ddf923d442499449948f4bf8a7c79249af0, vectors with small widths are supported, so here it needs to be adjusted accordingly. The correct should be If MaxVectorSize is less than _initial_vector_length, then MaxVectorSize should be used as the final value. This issue affects C2 autovectorization and some specific Vector API interfaces such as VectorSupport.getMaxLaneCount. We can verify the problem using the following test case: import jdk.internal.vm.vector.VectorSupport; public class GetMaxVectorSizeTest { public static void main(String[] args) { final int maxLaneCount = VectorSupport.getMaxLaneCount(byte.class); System.out.println("maxLaneCount:" + maxLaneCount); } } The compile command is as follows: javac --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest.java RISC-V without the -XX:MaxVectorSize=16 has the following execution results(risc-v rvv vector length is set 256 bit): zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:+UnlockExperimentalVMOptions -XX:+UseRVV --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest maxLaneCount:32 RISC-V using the -XX:MaxVectorSize=16 results in the following(risc-v rvv vector length is set 256 bit): zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:MaxVectorSize=16 -XX:+UnlockExperimentalVMOptions -XX:+UseRVV --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest maxLaneCount:32 AArch64 without the -XX:MaxVectorSize=16 has the following execution results(aarch64 sve vector length is set 256 bit): zifeihan at d915263bc793:~/jdk/build/linux-aarch64-server-fastdebug/jdk/bin$ ./java --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest maxLaneCount:32 AArch64 using the -XX:MaxVectorSize=16 results in the following(aarch64 sve vector length is set 256 bit): zifeihan at d915263bc793:~/jdk/build/linux-aarch64-server-fastdebug/jdk/bin$ ./java -XX:MaxVectorSize=16 --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest maxLaneCount:16 X86 without the -XX:MaxVectorSize=16 has the following execution results(x86 avx512, vector length is set 512 bit): zifeihan at plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$ java --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest maxLaneCount:64 X86 using the -XX:MaxVectorSize=16 results in the following(x86 avx512, vector length is set 512 bit): zifeihan at plct-c8:~/jdk/build/linux-riscv64-server-fastdebug/jdk/bin$ java -XX:MaxVectorSize=16 --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest maxLaneCount:16 Testing: qemu with UseRVV: - [x] Tier1 tests (release) - [ ] Tier2 tests (release) - [ ] Tier3 tests (release) - [x] test/jdk/jdk/incubator/vector (fastdebug) ------------- Commit messages: - 8314618: RISC-V: -XX:MaxVectorSize does not work as expected Changes: https://git.openjdk.org/jdk/pull/15356/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15356&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314618 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15356.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15356/head:pull/15356 PR: https://git.openjdk.org/jdk/pull/15356 From fyang at openjdk.org Mon Aug 21 02:32:23 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 21 Aug 2023 02:32:23 GMT Subject: RFR: 8314618: RISC-V: -XX:MaxVectorSize does not work as expected In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 02:01:35 GMT, Gui Cao wrote: > Hi all, we found that when the specified -XX:MaxVectorSize=16 no bigger than the detected _initial_vector_length=32, it causes the MaxVectorSize to be set incorrectly. > > MaxVectorSize is updated in src/hotspot/cpu/riscv/vm_version_riscv.cpp#VM_Version::c2_initialize(). > > > if (UseRVV) { > if (FLAG_IS_DEFAULT(MaxVectorSize)) { > MaxVectorSize = _initial_vector_length; > } else if (MaxVectorSize < 16) { > warning("RVV does not support vector length less than 16 bytes. Disabling RVV."); > UseRVV = false; > } else if (is_power_of_2(MaxVectorSize)) { > if (MaxVectorSize > _initial_vector_length) { > warning("Current system only supports max RVV vector length %d. Set MaxVectorSize to %d", > _initial_vector_length, _initial_vector_length); > } > MaxVectorSize = _initial_vector_length; > } else { > vm_exit_during_initialization(err_msg("Unsupported MaxVectorSize: %d", (int)MaxVectorSize)); > } > } > > > It's that RISC-V only supports max-width vectorization at first, so it's unconditionally set to hardware max-width here. However, after https://github.com/openjdk/jdk/commit/43c71ddf923d442499449948f4bf8a7c79249af0, vectors with small widths are supported, so here it needs to be adjusted accordingly. The correct should be If MaxVectorSize is less than _initial_vector_length, then MaxVectorSize should be used as the final value. > > This issue affects C2 autovectorization and some specific Vector API interfaces such as VectorSupport.getMaxLaneCount. > > We can verify the problem using the following test case: > > > import jdk.internal.vm.vector.VectorSupport; > > public class GetMaxVectorSizeTest { > public static void main(String[] args) { > final int maxLaneCount = VectorSupport.getMaxLaneCount(byte.class); > System.out.println("maxLaneCount:" + maxLaneCount); > } > } > > > The compile command is as follows: > > > javac --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest.java > > > RISC-V without the -XX:MaxVectorSize=16 has the following execution results(risc-v rvv vector length is set 256 bit): > > zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:+UnlockExperimentalVMOptions -XX:+UseRVV --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest > maxLaneCount:32 > > > RISC-V using the -XX:MaxVectorSize=16 results in the following(risc-v rvv vector length is set 256 bit): > > > zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin... Looks reasonable. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15356#pullrequestreview-1586076017 From dzhang at openjdk.org Mon Aug 21 03:08:26 2023 From: dzhang at openjdk.org (Dingli Zhang) Date: Mon, 21 Aug 2023 03:08:26 GMT Subject: RFR: 8314618: RISC-V: -XX:MaxVectorSize does not work as expected In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 02:01:35 GMT, Gui Cao wrote: > Hi all, we found that when the specified -XX:MaxVectorSize=16 no bigger than the detected _initial_vector_length=32, it causes the MaxVectorSize to be set incorrectly. > > MaxVectorSize is updated in src/hotspot/cpu/riscv/vm_version_riscv.cpp#VM_Version::c2_initialize(). > > > if (UseRVV) { > if (FLAG_IS_DEFAULT(MaxVectorSize)) { > MaxVectorSize = _initial_vector_length; > } else if (MaxVectorSize < 16) { > warning("RVV does not support vector length less than 16 bytes. Disabling RVV."); > UseRVV = false; > } else if (is_power_of_2(MaxVectorSize)) { > if (MaxVectorSize > _initial_vector_length) { > warning("Current system only supports max RVV vector length %d. Set MaxVectorSize to %d", > _initial_vector_length, _initial_vector_length); > } > MaxVectorSize = _initial_vector_length; > } else { > vm_exit_during_initialization(err_msg("Unsupported MaxVectorSize: %d", (int)MaxVectorSize)); > } > } > > > It's that RISC-V only supports max-width vectorization at first, so it's unconditionally set to hardware max-width here. However, after https://github.com/openjdk/jdk/commit/43c71ddf923d442499449948f4bf8a7c79249af0, vectors with small widths are supported, so here it needs to be adjusted accordingly. The correct should be If MaxVectorSize is less than _initial_vector_length, then MaxVectorSize should be used as the final value. > > This issue affects C2 autovectorization and some specific Vector API interfaces such as VectorSupport.getMaxLaneCount. > > We can verify the problem using the following test case: > > > import jdk.internal.vm.vector.VectorSupport; > > public class GetMaxVectorSizeTest { > public static void main(String[] args) { > final int maxLaneCount = VectorSupport.getMaxLaneCount(byte.class); > System.out.println("maxLaneCount:" + maxLaneCount); > } > } > > > The compile command is as follows: > > > javac --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest.java > > > RISC-V without the -XX:MaxVectorSize=16 has the following execution results(risc-v rvv vector length is set 256 bit): > > zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:+UnlockExperimentalVMOptions -XX:+UseRVV --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest > maxLaneCount:32 > > > RISC-V using the -XX:MaxVectorSize=16 results in the following(risc-v rvv vector length is set 256 bit): > > > zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin... LGTM, thanks! ------------- Marked as reviewed by dzhang (Author). PR Review: https://git.openjdk.org/jdk/pull/15356#pullrequestreview-1586105906 From haosun at openjdk.org Mon Aug 21 03:45:55 2023 From: haosun at openjdk.org (Hao Sun) Date: Mon, 21 Aug 2023 03:45:55 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v4] In-Reply-To: References: Message-ID: > ### Background > > 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. > > 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. > > 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. > > 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. > > 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. > > ### Goal > > This patch aims to make PAC-RET compatible with virtual threads. > > ### Requirements of virtual threads > > R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. > > R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. > > Note that more details can be found in the discussion [3]. > > ### Investigation > > We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. > > 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. > > 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. > > 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP should be preserved to make it easy to find this modifier in case of... Hao Sun 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 jdk-8287325 - Remove my temp test patch on jvmci_global.hpp and stubGenerator_aarch64.hpp - Use relative SP as the PAC modifier - Merge branch 'master' into jdk-8287325 - Merge branch 'master' into jdk-8287325 - Rename return_pc_at and patch_pc_at Rename return_pc_at to return_address_at. Rename patch_pc_at to patch_return_address_at. - 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret * Background 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. * Goal This patch aims to make PAC-RET compatible with virtual threads. * Requirements of virtual threads R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. Note that more details can be found in the discussion [3]. * Investigation We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. 3. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP should be preserved to make it easy to find this modifier in case of some exception scenarios (Recall the reason why we fail to use SP as the modifier). Finally, we choose to use value zero as the modifier. Trivially, it's compatible with virtual threads. However, compared to FP modifier, this solution would reduce the strength of PAC-RET protection to some extent. E.g., you get the same authentication code for each call to the function, whereas using FP gives you different codes as long as the stack depth is different. * Implementation of Zero modifier Here list the key updates of this patch. 1. vm_version_aarch64.cpp Remove the constraint on "enable-preview" and "PreserveFramePointer". 2. macroAssembler_aarch64.cpp For utility protect_return_address(), 1) use PACIAZ/PACIZA instructions directly. 2) argument "temp_reg" is removed since all functions use the same modifier. 3) all the use sites are updated accordingly. This involves the updates in many files. Similar updates are done to utility authenticate_return_address(). Besides, aarch64.ad and AArch64TestAssembler.java are updated accordingly. 3. pauth_linux_aarch64.inline.hpp For utilities pauth_sign_return_address() and pauth_authenticate_return_address(), remove the second argument and pass value zero to r16 register. Similarly, all the use sites are updated as well. This involves the updates in many files. 4. continuationHelper_aarch64.inline.hpp Introduce return_pc_at() and patch_pc_at() to avoid directly reading the saved PC or writing new signed PC on the stack in shared code. 5. Minor updates 1) sharedRuntime_aarch64.cpp: Add the missing authenticate_return_address() use for function gen_continuation_enter(). In functions generate_deopt_blob() and generate_uncommon_trap_blob(), remove the authentication on the caller (3) frame since the return address is not used. 2) stubGenerator_aarch64.cpp: Add the missing authenticate_return_address() use for function generate_cont_thaw(). 3) runtime.cpp: enable the authentication. * Test 1. Cross compilations on arm32/s390/ppc/riscv passed. 2. zero build and x86 build passed. 3. tier1~3 passed on Linux/AArch64 w/ and w/o PAC-RET. Co-Developed-by: Nick Gasson [1] https://bugs.openjdk.org/browse/JDK-8277204 [2] https://openjdk.org/jeps/425 [3] https://github.com/openjdk/jdk/pull/9067 [4] https://bugs.openjdk.org/browse/JDK-8288023 [5] https://bugs.openjdk.org/browse/JDK-8301819 [6] https://openjdk.org/jeps/444 [7] https://www.usenix.org/conference/usenixsecurity21/presentation/liljestrand [8] https://github.com/openjdk/jdk/pull/10441 ------------- Changes: https://git.openjdk.org/jdk/pull/13322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13322&range=03 Stats: 309 lines in 30 files changed: 181 ins; 18 del; 110 mod Patch: https://git.openjdk.org/jdk/pull/13322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13322/head:pull/13322 PR: https://git.openjdk.org/jdk/pull/13322 From dholmes at openjdk.org Mon Aug 21 03:46:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Aug 2023 03:46:10 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily [v3] In-Reply-To: References: Message-ID: > We combine: > > address os::current_stack_base(); > size_t os::current_stack_size(); > > into > > void os::current_stack_base_and_size(address* stack_base, size_t* stack_size) > > and so avoid making two underlying system calls. The os/platform specific specializations are handled by the `current_stack_region` calls. It made sense to modify that to export the `base` directly rather than the `bottom`. In doing that change it made sense to standardise on the the style of the code used (variable names etc) to make it easier to see where the 5 different versions were the same and where they differ. Having 5 versions is unfortunate ( 3 BSD: one per arch - zero, x64, aarch64; and 2 linux: zero and everything else), but trying to combine them with ifdefs would be even worse in my opinion. > > In theory there should be zero functional changes here. > > Testing: > - Tiers 1-3 > - All our internal builds in tiers 1-5 > - GHA > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Promote os::::current_stack_region to os::current_stack_base_and_size ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15321/files - new: https://git.openjdk.org/jdk/pull/15321/files/bc7a94ac..4e22dab0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15321&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15321&range=01-02 Stats: 18 lines in 8 files changed: 0 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15321/head:pull/15321 PR: https://git.openjdk.org/jdk/pull/15321 From dholmes at openjdk.org Mon Aug 21 04:51:28 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Aug 2023 04:51:28 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it In-Reply-To: References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: On Sat, 19 Aug 2023 23:42:32 GMT, Johan Sj?len wrote: >> src/hotspot/share/utilities/growableArray.hpp line 545: >> >>> 543: if (len > 0) { >>> 544: new_data = static_cast(this)->allocate(); >>> 545: for (int i = 0; i < len; ++i) ::new (&new_data[i]) E(static_cast(old_data[i])); >> >> Why not use `std::move`? Thanks. > > Hi, in short: Yes, I believe that I can switch and that `std::move` is better. > > In long: I can't find any mention of `std::move` not being allowed in the style guide, using it seems to be in the same spirit as other std library usage (`#include ` for example) and since it is just a better version of what I wrote here let's do the switch. @jdksjolen The guide lists what is permitted to be used, so if it isn't listed as permitted then it isn't presently permitted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15344#discussion_r1299595673 From cstein at openjdk.org Mon Aug 21 06:33:35 2023 From: cstein at openjdk.org (Christian Stein) Date: Mon, 21 Aug 2023 06:33:35 GMT Subject: Integrated: 8314495: Update to use jtreg 7.3.1 In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.3,1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda > > This change set also fixes: > - https://bugs.openjdk.org/browse/JDK-8313902 > - https://bugs.openjdk.org/browse/JDK-8313903 > > Testing: tier1-tier5 OK This pull request has now been integrated. Changeset: c50315de Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/c50315de8f13d316a7de08be53716cd88fa801c4 Stats: 12 lines in 9 files changed: 0 ins; 3 del; 9 mod 8314495: Update to use jtreg 7.3.1 Reviewed-by: dholmes, erikj, iris, jpai ------------- PR: https://git.openjdk.org/jdk/pull/15323 From aboldtch at openjdk.org Mon Aug 21 06:43:25 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 21 Aug 2023 06:43:25 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it In-Reply-To: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: On Fri, 18 Aug 2023 10:39:28 GMT, Johan Sj?len wrote: > Given some `GrowableArray` where `E` is non-copyable with a move constructor will currently fail to compile. This is because `GrowableArray`'s expand and shrink calls the copy constructor. We cast the values to rvalues (akin to `std::move`) to instead call the move constructor if available. If there is no move constructor but there is a copy constructor, then that will be called instead. I can just add that I was investigating adding some sort of UniquePtr like object that respected our different `[Any|Resource|CHeap]Obj` allocation strategies. That required me to add move semantics to growablearray. Here is my patch https://github.com/openjdk/jdk/commit/20cb959e79a67f13d1cc9c7ec07f89bc86eefd3a My implementation prefered copy where a copy constructor existed. However I also noted that the growable array iterators always make a copy, which means that for (auto& el : growableArray) will always make a copy. So this code also changed it so that the iterators return references, and a GrowableArrayConstIterator was added to make it work in const contexts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15344#issuecomment-1685740120 From duke at openjdk.org Mon Aug 21 07:18:51 2023 From: duke at openjdk.org (sid8606) Date: Mon, 21 Aug 2023 07:18:51 GMT Subject: Integrated: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 07:55:03 GMT, sid8606 wrote: > Implementation of "Foreign Function & Memory API" for s390x (Big Endian). This pull request has now been integrated. Changeset: ec1f7a84 Author: Sidraya Committer: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/ec1f7a8480db025a6f405817a106af8e92b69c44 Stats: 1523 lines in 19 files changed: 1469 ins; 4 del; 50 mod 8311630: [s390] Implementation of Foreign Function & Memory API (Preview) Reviewed-by: amitkumar, jvernee, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/14801 From jwaters at openjdk.org Mon Aug 21 08:16:32 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 21 Aug 2023 08:16:32 GMT Subject: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v4] In-Reply-To: References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com> Message-ID: <4HxoycfhUj3rvj-IBGIIkfQFqgJ0i15UiwmVX5MbVo0=.94d41007-b52d-41c3-bd76-8f6ea6a30321@github.com> On Thu, 17 Aug 2023 08:38:01 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future. It can be done with some effort, given that the significantly stricter gcc can now compile an experimental Windows JDK as of 2023, and will serve to significantly cut down on monstrosities in ancient Windows code > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Document changes in awt_DnDDS.cpp Bumping ------------- PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1685862875 From mdoerr at openjdk.org Mon Aug 21 09:19:28 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 21 Aug 2023 09:19:28 GMT Subject: RFR: 8314488: Compile the JDK as C++17 In-Reply-To: References: Message-ID: On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote: > Implementation of [JEP draft: Compile the JDK as C++17](https://bugs.openjdk.org/browse/JDK-8310260) Successfully tested on AIX with xlc 17.1.1. Works for us (SAP). Please check with others who might still use an older compiler (IBM). ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14988#pullrequestreview-1586571119 From stuefe at openjdk.org Mon Aug 21 09:29:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 21 Aug 2023 09:29:28 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily [v3] In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 03:46:10 GMT, David Holmes wrote: >> We combine: >> >> address os::current_stack_base(); >> size_t os::current_stack_size(); >> >> into >> >> void os::current_stack_base_and_size(address* stack_base, size_t* stack_size) >> >> and so avoid making two underlying system calls. The os/platform specific specializations are handled by the `current_stack_region` calls. It made sense to modify that to export the `base` directly rather than the `bottom`. In doing that change it made sense to standardise on the the style of the code used (variable names etc) to make it easier to see where the 5 different versions were the same and where they differ. Having 5 versions is unfortunate ( 3 BSD: one per arch - zero, x64, aarch64; and 2 linux: zero and everything else), but trying to combine them with ifdefs would be even worse in my opinion. >> >> In theory there should be zero functional changes here. >> >> Testing: >> - Tiers 1-3 >> - All our internal builds in tiers 1-5 >> - GHA >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Promote os::::current_stack_region to os::current_stack_base_and_size Still good. Thanks for fixing this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15321#issuecomment-1685972097 From jsjolen at openjdk.org Mon Aug 21 09:37:27 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 21 Aug 2023 09:37:27 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it In-Reply-To: References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: On Mon, 21 Aug 2023 04:48:51 GMT, David Holmes wrote: >> Hi, in short: Yes, I believe that I can switch and that `std::move` is better. >> >> In long: I can't find any mention of `std::move` not being allowed in the style guide, using it seems to be in the same spirit as other std library usage (`#include ` for example) and since it is just a better version of what I wrote here let's do the switch. > > @jdksjolen The guide lists what is permitted to be used, so if it isn't listed as permitted then it isn't presently permitted. Thank you David, then I guess I'd need to get the guide changed before my or Axel's proposal is merged. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15344#discussion_r1299865239 From thartmann at openjdk.org Mon Aug 21 09:41:31 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 21 Aug 2023 09:41:31 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 12:43:56 GMT, Roberto Casta?eda Lozano wrote: > This changeset ensures that the array copy stub underlying the intrinsic implementation of `Object.clone` only copies its (double-word aligned) payload, excluding the remaining object alignment padding words, when a non-default `ObjectAlignmentInBytes` value is used. This prevents the specialized ZGC stubs for `Object[]` array copy from processing undefined object alignment padding words as valid object pointers. For further details about the specific failure, see [initial analysis](https://bugs.openjdk.org/browse/JDK-8312749?focusedCommentId=14600658&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14600658) by Erik ?sterlund and Stefan Karlsson and comments in the regression test included in this changeset. > > As a side-benefit, the changeset simplifies the array size computation logic in `GraphKit::new_array()` by decoupling computation of header size and alignment padding size. > > #### Testing > > ##### Functionality > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - tier4-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; ZGC-specific tests only) > - tier6-9 (linux-x64; ZGC-specific tests only) > - tier1-3, and a few custom examples, applying [JDK-8139457](https://github.com/openjdk/jdk/pull/11044) (under review) on top of this changeset > > ##### Performance > > Tested performance on the following set of OpenJDK micro-benchmarks, on linux-x64 (for both G1 and ZGC, using different ObjectAlignmentInBytes values): > > - `openjdk.bench.java.lang.ArrayClone.byteClone` > - `openjdk.bench.java.lang.ArrayClone.intClone` > - `openjdk.bench.java.lang.ArrayFiddle.simple_clone` > - `openjdk.bench.java.lang.Clone.cloneLarge` > - `openjdk.bench.java.lang.Clone.cloneThreeDifferent` > > No significant regression was observed. Looks good to me! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 686: > 684: } > 685: payload_size = kit->gvn().transform(new URShiftXNode(payload_size, kit->intcon(LogBytesPerLong))); > 686: ArrayCopyNode* ac = ArrayCopyNode::make(kit, false, src_base, offset, dst_base, offset, payload_size, true, false); Suggestion: ArrayCopyNode* ac = ArrayCopyNode::make(kit, false, src_base, offset, dst_base, offset, payload_size, true, false); ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15288#pullrequestreview-1586603759 PR Review Comment: https://git.openjdk.org/jdk/pull/15288#discussion_r1299866583 From jsjolen at openjdk.org Mon Aug 21 09:54:07 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 21 Aug 2023 09:54:07 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it [v2] In-Reply-To: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: > Given some `GrowableArray` where `E` is non-copyable with a move constructor will currently fail to compile. This is because `GrowableArray`'s expand and shrink calls the copy constructor. We cast the values to rvalues (akin to `std::move`) to instead call the move constructor if available. If there is no move constructor but there is a copy constructor, then that will be called instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Use std::move ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15344/files - new: https://git.openjdk.org/jdk/pull/15344/files/27e9d7e7..eb3dbf32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15344&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15344&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15344.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15344/head:pull/15344 PR: https://git.openjdk.org/jdk/pull/15344 From jsjolen at openjdk.org Mon Aug 21 09:54:07 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 21 Aug 2023 09:54:07 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it [v2] In-Reply-To: References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: On Sun, 20 Aug 2023 06:11:42 GMT, Quan Anh Mai wrote: >> Hi, in short: Yes, I believe that I can switch and that `std::move` is better. >> >> In long: I can't find any mention of `std::move` not being allowed in the style guide, using it seems to be in the same spirit as other std library usage (`#include ` for example) and since it is just a better version of what I wrote here let's do the switch. > > I believe "Rvalue references and move semantics" falls under the "Undecided Features" category. @merykitty is correct, at the bottom of the style guide under undecided features: > Rvalue references and move semantics ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15344#discussion_r1299880031 From ayang at openjdk.org Mon Aug 21 10:25:28 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 21 Aug 2023 10:25:28 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 12:43:56 GMT, Roberto Casta?eda Lozano wrote: > This changeset ensures that the array copy stub underlying the intrinsic implementation of `Object.clone` only copies its (double-word aligned) payload, excluding the remaining object alignment padding words, when a non-default `ObjectAlignmentInBytes` value is used. This prevents the specialized ZGC stubs for `Object[]` array copy from processing undefined object alignment padding words as valid object pointers. For further details about the specific failure, see [initial analysis](https://bugs.openjdk.org/browse/JDK-8312749?focusedCommentId=14600658&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14600658) by Erik ?sterlund and Stefan Karlsson and comments in the regression test included in this changeset. > > As a side-benefit, the changeset simplifies the array size computation logic in `GraphKit::new_array()` by decoupling computation of header size and alignment padding size. > > #### Testing > > ##### Functionality > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - tier4-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; ZGC-specific tests only) > - tier6-9 (linux-x64; ZGC-specific tests only) > - tier1-3, and a few custom examples, applying [JDK-8139457](https://github.com/openjdk/jdk/pull/11044) (under review) on top of this changeset > > ##### Performance > > Tested performance on the following set of OpenJDK micro-benchmarks, on linux-x64 (for both G1 and ZGC, using different ObjectAlignmentInBytes values): > > - `openjdk.bench.java.lang.ArrayClone.byteClone` > - `openjdk.bench.java.lang.ArrayClone.intClone` > - `openjdk.bench.java.lang.ArrayFiddle.simple_clone` > - `openjdk.bench.java.lang.Clone.cloneLarge` > - `openjdk.bench.java.lang.Clone.cloneThreeDifferent` > > No significant regression was observed. If I understand it correctly, much of the diff is to ensure that `ArrayCopyNode::make` (in `BarrierSetC2::clone`) gets the correct value for the `length` arg, calculated as `align_up(array-length * elem-size, word-size) / word-size`. I wonder if it's possible to pass the actual array length (#slots) as `length` and move the merge-bytes-to-words-copying optimization to a lower level, e.g. inside `conjoint_jbytes`. Ofc, `BarrierSetC2::clone_at_expansion` and its derived siblings need to be adjusted accordingly, e.g. to use the actual elem-type. (Preexisting: having `ArrayCopyNode` to cover both array and instance cloning hinders the readability, IMO.) ------------- PR Review: https://git.openjdk.org/jdk/pull/15288#pullrequestreview-1586685925 From ayang at openjdk.org Mon Aug 21 10:28:43 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 21 Aug 2023 10:28:43 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: References: Message-ID: <1yFrFdxQSLklWfy7viP4ddKBxf_PtjC2rGBycs8OwMo=.f4b172ff-f5a0-4caa-8274-de72bb501c0d@github.com> On Thu, 17 Aug 2023 19:05:22 GMT, Roman Kennke wrote: > I couldn't move it into initialize_body() because that method is also used by initialize_object() and would require more work to get the len_in_bytes consistent. I see the patch from xmas92 moves that logic inside `initialize_body()` and it is clearer in separating header/body responsibility. Personally, I think one can take a step further, extending `zero_memory` to support non-word-alignment args. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1686064096 From ayang at openjdk.org Mon Aug 21 10:28:44 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 21 Aug 2023 10:28:44 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v50] In-Reply-To: <3dMQjgPviPNAuH-FzX_rkqQCsbKFsXbVdNN2t_DgAjc=.3411115c-3f11-4b3b-bb9c-0ce400f5a57b@github.com> References: <7mq6uSoypvnySjXKT4pNiPZFZR2LzUOMq8WmeQFV3ww=.5234a656-14ff-4b5d-8ce0-aad8fbd9a62a@github.com> <3dMQjgPviPNAuH-FzX_rkqQCsbKFsXbVdNN2t_DgAjc=.3411115c-3f11-4b3b-bb9c-0ce400f5a57b@github.com> Message-ID: On Thu, 17 Aug 2023 18:55:13 GMT, Roman Kennke wrote: > Maybe it makes sense to move out header_size() to avoid the confusion? I believe so. Having header-bytes aligned up to word sounds like sth the caller interests, not callee. > It could, but it doesn't seem to be a good fit because a narrowKlass is not a ptr. narrowKlass are explicitly only a 32bit int value and should be treated as such. That would get rid of the trailing zero-gap later, right? else if (UseCompressedClassPointers) { xorptr(t1, t1); store_klass_gap(obj, t1); } > If the gap is not used by instance fields or array elements, they don't actually belong to neither the header nor to the payload. It boils down to the def. of "header". Option 1: `header == markword + klass + (length) ==> array/obj == header + (gap) + payload/body` Option 2: `header == markword + klass + (length) + (gap) ==> array/obj == header + payload/body` It's kind of a preexisting issue though. > and I believe C2 would not clear it in any case I used a simple class to test. class A { long x; } In the C2 assembly, I believe the following three instructions correspond to markword, klass and the gap. 0x00007f7eccad9c60: mov QWORD PTR [rax],0x1 0x00007f7eccad9c67: mov DWORD PTR [rax+0x8],0x80208210; {metadata('hello$A')} 0x00007f7eccad9c6e: mov DWORD PTR [rax+0xc],0x0 (Ofc, I may have missed some jvm flags; the corresponding source `PhaseMacroExpand::initialize_object` is not obvious to me.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1299922319 From ayang at openjdk.org Mon Aug 21 12:32:35 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 21 Aug 2023 12:32:35 GMT Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion Message-ID: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Use unsigned type for heap-region-size related shifts in HeapRegion. Test: tier1-3 ------------- Commit messages: - g1-heap-region-log-uint Changes: https://git.openjdk.org/jdk/pull/15360/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15360&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314651 Stats: 22 lines in 8 files changed: 2 ins; 4 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/15360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15360/head:pull/15360 PR: https://git.openjdk.org/jdk/pull/15360 From stuefe at openjdk.org Mon Aug 21 12:42:29 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 21 Aug 2023 12:42:29 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it [v2] In-Reply-To: References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> Message-ID: <3XO9jpEvY1OxQzDr2QIcVAs6A9Ih5RvdFzYSMJo2ONo=.855b0057-1068-467a-9084-f0c65f85d5e9@github.com> On Mon, 21 Aug 2023 09:54:07 GMT, Johan Sj?len wrote: >> Given some `GrowableArray` where `E` is non-copyable with a move constructor will currently fail to compile. This is because `GrowableArray`'s expand and shrink calls the copy constructor. We cast the values to rvalues (akin to `std::move`) to instead call the move constructor if available. If there is no move constructor but there is a copy constructor, then that will be called instead. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Use std::move >From reading the title, I thought this would introduce realloc() - introduce the semantics of grow-in-place for the underlying Allocators. That would be quite useful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15344#issuecomment-1686253433 From jsjolen at openjdk.org Mon Aug 21 15:01:27 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 21 Aug 2023 15:01:27 GMT Subject: RFR: 8314571: GrowableArray should move its old data and not copy it [v2] In-Reply-To: <3XO9jpEvY1OxQzDr2QIcVAs6A9Ih5RvdFzYSMJo2ONo=.855b0057-1068-467a-9084-f0c65f85d5e9@github.com> References: <5qhT7CDsB-wvvdPHCEWjzx8xzZ_AFHtIgRr3ugtQD2Y=.92d80b23-715a-44c6-afbb-e8babf19fd2c@github.com> <3XO9jpEvY1OxQzDr2QIcVAs6A9Ih5RvdFzYSMJo2ONo=.855b0057-1068-467a-9084-f0c65f85d5e9@github.com> Message-ID: On Mon, 21 Aug 2023 12:40:02 GMT, Thomas Stuefe wrote: > From reading the title, I thought this would introduce realloc() - introduce the semantics of grow-in-place for the underlying Allocators. That would be quite useful. Arenas do have `Arealloc`, `ResourceArea`s are arenas, and of course `malloc` can `realloc` so all of our allocators could support this sort of implementation also. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15344#issuecomment-1686494365 From mchung at openjdk.org Mon Aug 21 20:15:30 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 21 Aug 2023 20:15:30 GMT Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked reflectively [v3] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 11:02:38 GMT, Volker Simonis wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively > > We actually have two problems here: > 1. If called refelctively, `getCallerClass()` can throw an UOE even if it was **not** called from a `@CallerSensitive` method (see inital test case). > 2. If called reflectively from a `@CallerSensitive` method, `getCallerClass()` will currently not throw a UOE as expected (see extended test in this PR). > > `getCallerClass()` **is** performance sensitive and we want to improve its performance rather than slow it down (see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)). I think performance-wise it would be better to do all the filtering in the VM, where we have all the required information at hand and minimize the amount of data that needs to be passed between Java and the VM. > > Before starting to implement a new version of the fix which moves all the checks to Java, I'd like to hear some more opinions about whether we agree to move all the filtering and checks from the VM to Java (even at the cost of performance regressions) or if we better want to go the other way and do all the filtering/checks in the JVM. @shipilev, @dholmes-ora, @dfuch, @AlanBateman - what do you think? @simonis please see #15370 to show the alternative fix for this issue and do the filtering in Java. The benchmark shows about 30-60 ns slowdown. I think it's acceptable with the benefit of keeping the filtering in the libraries rather than in VM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1686977577 From mchung at openjdk.org Mon Aug 21 20:37:47 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 21 Aug 2023 20:37:47 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only Message-ID: 8268829: Provide an optimized way to walk the stack with Class object only `StackWalker::walk` creates one `StackFrame` per frame and the current implementation allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks like logging may only interest in the Class object but not the method name nor the BCI, for example, filters out its implementation classes to find the caller class. It's similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option. If no method information is needed, this option can be used such that the stack walker will save the overhead (1) to extract the method information and (2) the memory used for the stack walking. In addition, this can also fix - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively Adding `NO_METHOD_TIME` option provides a simple way for existing code, for example logging frameworks, to take advantage of this enhancement with the least change as it can keep the existing implementation in traversing `StackFrame`s. For example: to find the first caller filtering a known list of implementation class, existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance` to create a stack walker instance: StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO); Optional> callerClass = walker.walk(s -> s.map(StackFrame::getDeclaringClass) .filter(interestingClasses::contains) .findFirst()); If method information is accessed on the `StackFrame`s produced by this stack walker such as `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. The alternative considered is to provide a new API: ` T walkClass(Function, ? extends T> function)` In this case, the caller would need to pass a function that takes a stream of `Class` object instead of `StackFrame`. Existing code would have to modify calls to the `walk` method to `walkClass` and the function body. ### Implementation Details If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]` buffer that is filled by the VM during stack walking. `ClassFrameInfo` holds the Class instance plus `flags` which indicate if it's caller sensitive or hidden. With this change, `StackWalker::getCallerClass` can also use `ClassFrameInfo[]` buffer to replace the special `Class` buffer and remove the special check in the VM. JDK-8311500 can be fixed in Java. If `NO_METHOD_NAME` is not set, the implementation creates `StackFrameInfo[]` buffer. `StackFrameInfo` is a subclass of `ClassFrameInfo`. It keeps `ResolvedMethodName` and all other method information. ### Performance The memory usage of the data structure (shown by -XX:PrintFieldLayout): | Type | Instance size | | ---- | ------------ | | `ClassFrameInfo` | 24 bytes | | `StackFrameInfo` | 48 bytes | | `ResolvedMethodName` | 24 bytes | | `MemberName` | 48 bytes | | `StackFrameInfo` (old) | 32 bytes | The existing implementation allocates a total of 104 bytes for each frame (`StackFrameInfo` + `MemberName` + `ResolvedMethodName`). The new implementation, without `NO_METHOD_INFO` option, allocates a total of 72 bytes for each frame (`StackFrameInfo` + `ResolvedMethodName`) which saves 30% of the buffer memory. With `NO_METHOD_INFO`, 24 bytes is allocated for each frame (only `ClassFrameInfo` is needed). In addition, it saves the overhead in creating `ResolvedMethodName` object in the VM. The microbenchmark shows that the runtime performance of stack walking with method information is 15-31% faster than the old implementation. Using `NO_METHOD_INFO` option, it is about 21-43% faster compared to traversing the frames without `NO_METHOD_INFO` in the new implementation. #### `StackWalker::getCallerClass` `StackWalkBench::getCallerClass` shows about 30-60 ns degradation. The old implementation creates a `Class` array of size 8 whereas the new implementation which creates a `ClassFrameInfo` array of size 8 initialized with 6 `ClassFrameInfo` elements. The new implementation of `getCallerClass` adds 144 bytes more, which is insignificant. The benefit of this is to do the filtering in Java rather than doing in VM. `StackWalkBench::getCallerClass` includes the cost of setting up the call stack. There is no good way to write a JMH benchmark just to measure the performance of `getCallerClass`. If I measured `getCallerClass` with a standalone benchmark, it shows `getCallerClass` takes roughly about 8500-10000 ns range on my macos-aarch64 machine. The 30-60 ns degradation is negligible. ------------- Commit messages: - fix trailing whitespace - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Update LocalLongHelper.java - clean up - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Add StackWalker.Option.NO_METHOD_INFO - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - ... and 3 more: https://git.openjdk.org/jdk/compare/78f74bc8...e9e2b390 Changes: https://git.openjdk.org/jdk/pull/15370/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8268829 Stats: 1026 lines in 30 files changed: 628 ins; 178 del; 220 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From mchung at openjdk.org Mon Aug 21 21:10:36 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 21 Aug 2023 21:10:36 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v2] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option. > If no method information is needed, this option can be used such that the > stack walker will save the overhead (1) to extract the method information > and (2) the memory used for the stack walking. In addition, this can also fix > > - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively > > Adding `NO_METHOD_TIME` option provides a simple way for existing code, > for example logging frameworks, to take advantage of this enhancement with > the least change as it can keep the existing implementation in traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance` > to create a stack walker instance: > > > StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(interestingClasses::contains) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > The alternative considered is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > ### Implementation Details > > If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]` > buffer that is filled by the VM during stack walking. `ClassFrameInfo` holds the > Class instance plus `flags` which indicate if it's caller sensitive or hidden. > With this change, `StackWalker::getCa... Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/e9e2b390..87775552 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=00-01 Stats: 6 lines in 4 files changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From cjplummer at openjdk.org Mon Aug 21 21:53:46 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 21 Aug 2023 21:53:46 GMT Subject: RFR: 8189685: need PerfMemory class update and a volatile_static_field support in VMStructs Message-ID: During [JDK-8151815](https://bugs.openjdk.org/browse/JDK-8151815) it was noted that the PerfMemory _initialized and _destroyed fields should be volatile, but VMStructs didn't have the needed support for doing that, so it was left as a future task. @YaSuenag provided a patch at the time to take care of the VMStructs support. I've integrated it, although it was far from clean due to some changes in VMStructs, and also moving OrderAccess::release_store to Atomic::release_store. One other change I made to the patch had to do with consistency with using "volatile static" vs "static volatile". We already have volatile_nonstatic_field. The patch renamed static_ptr_volatile_field to static_volatile_field to make it more general purpose, but this was inconsistent with the name of volatile_nonstatic_field, so I chose the name volatile_static_field instead. This carried over into some other areas like the names of the GENERATE_VOLATILE_STATIC_VM_STRUCT_ENTRY and CHECK_VOLATILE_STATIC_VM_STRUCT_ENTRY macros. ------------- Commit messages: - Make needed perfMemory fields volatile and added needed vmstructs support for volatile static. Changes: https://git.openjdk.org/jdk/pull/15373/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15373&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8189685 Stats: 22 lines in 5 files changed: 7 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/15373.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15373/head:pull/15373 PR: https://git.openjdk.org/jdk/pull/15373 From mchung at openjdk.org Mon Aug 21 22:35:27 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 21 Aug 2023 22:35:27 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v2] In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 21:10:36 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option. >> If no method information is needed, this option can be used such that the >> stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> Adding `NO_METHOD_TIME` option provides a simple way for existing code, >> for example logging frameworks, to take advantage of this enhancement with >> the least change as it can keep the existing implementation in traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance` >> to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> The alternative considered is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]` >> buffer that is filled by the VM during stack walking. `ClassFrameInfo` holds the >> Class instance plus `flag... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > clean up @vidmik gave the feedback about the name of the option `NO_METHOD_INFO`, generally preferred a positive word. I do agree. One option is to introduce `enum Kind { CLASS_INFO, METHOD_INFO}` instead of `NO_METHOD_INFO` and new factory methods `getInstance(Kind kind, Option... option)`. `getInstance()` is equivalent to `getInstance(METHOD_INFO)`. To collect class only, do getInstance(CLASS_INFO); getInstance(CLASS_INFO, RETAIN_CLASS_REFERENCE); I think a new enum is a cleaner way to specify what information to collect. Any feedback/thought before I update this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1687140453 From gcao at openjdk.org Tue Aug 22 02:47:37 2023 From: gcao at openjdk.org (Gui Cao) Date: Tue, 22 Aug 2023 02:47:37 GMT Subject: RFR: 8314618: RISC-V: -XX:MaxVectorSize does not work as expected In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 02:29:10 GMT, Fei Yang wrote: >> Hi all, we found that when the specified -XX:MaxVectorSize=16 no bigger than the detected _initial_vector_length=32, it causes the MaxVectorSize to be set incorrectly. >> >> MaxVectorSize is updated in src/hotspot/cpu/riscv/vm_version_riscv.cpp#VM_Version::c2_initialize(). >> >> >> if (UseRVV) { >> if (FLAG_IS_DEFAULT(MaxVectorSize)) { >> MaxVectorSize = _initial_vector_length; >> } else if (MaxVectorSize < 16) { >> warning("RVV does not support vector length less than 16 bytes. Disabling RVV."); >> UseRVV = false; >> } else if (is_power_of_2(MaxVectorSize)) { >> if (MaxVectorSize > _initial_vector_length) { >> warning("Current system only supports max RVV vector length %d. Set MaxVectorSize to %d", >> _initial_vector_length, _initial_vector_length); >> } >> MaxVectorSize = _initial_vector_length; >> } else { >> vm_exit_during_initialization(err_msg("Unsupported MaxVectorSize: %d", (int)MaxVectorSize)); >> } >> } >> >> >> It's that RISC-V only supports max-width vectorization at first, so it's unconditionally set to hardware max-width here. However, after https://github.com/openjdk/jdk/commit/43c71ddf923d442499449948f4bf8a7c79249af0, vectors with small widths are supported, so here it needs to be adjusted accordingly. The correct should be If MaxVectorSize is less than _initial_vector_length, then MaxVectorSize should be used as the final value. >> >> This issue affects C2 autovectorization and some specific Vector API interfaces such as VectorSupport.getMaxLaneCount. >> >> We can verify the problem using the following test case: >> >> >> import jdk.internal.vm.vector.VectorSupport; >> >> public class GetMaxVectorSizeTest { >> public static void main(String[] args) { >> final int maxLaneCount = VectorSupport.getMaxLaneCount(byte.class); >> System.out.println("maxLaneCount:" + maxLaneCount); >> } >> } >> >> >> The compile command is as follows: >> >> >> javac --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest.java >> >> >> RISC-V without the -XX:MaxVectorSize=16 has the following execution results(risc-v rvv vector length is set 256 bit): >> >> zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:+UnlockExperimentalVMOptions -XX:+UseRVV --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest >> maxLaneCount:32 >> >> >> RISC-V using the -XX:MaxVectorSize=16 results in the following(risc-v rv... > > Looks reasonable. @RealFYang @DingliZhang Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15356#issuecomment-1687332499 From gcao at openjdk.org Tue Aug 22 02:50:42 2023 From: gcao at openjdk.org (Gui Cao) Date: Tue, 22 Aug 2023 02:50:42 GMT Subject: Integrated: 8314618: RISC-V: -XX:MaxVectorSize does not work as expected In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 02:01:35 GMT, Gui Cao wrote: > Hi all, we found that when the specified -XX:MaxVectorSize=16 no bigger than the detected _initial_vector_length=32, it causes the MaxVectorSize to be set incorrectly. > > MaxVectorSize is updated in src/hotspot/cpu/riscv/vm_version_riscv.cpp#VM_Version::c2_initialize(). > > > if (UseRVV) { > if (FLAG_IS_DEFAULT(MaxVectorSize)) { > MaxVectorSize = _initial_vector_length; > } else if (MaxVectorSize < 16) { > warning("RVV does not support vector length less than 16 bytes. Disabling RVV."); > UseRVV = false; > } else if (is_power_of_2(MaxVectorSize)) { > if (MaxVectorSize > _initial_vector_length) { > warning("Current system only supports max RVV vector length %d. Set MaxVectorSize to %d", > _initial_vector_length, _initial_vector_length); > } > MaxVectorSize = _initial_vector_length; > } else { > vm_exit_during_initialization(err_msg("Unsupported MaxVectorSize: %d", (int)MaxVectorSize)); > } > } > > > It's that RISC-V only supports max-width vectorization at first, so it's unconditionally set to hardware max-width here. However, after https://github.com/openjdk/jdk/commit/43c71ddf923d442499449948f4bf8a7c79249af0, vectors with small widths are supported, so here it needs to be adjusted accordingly. The correct should be If MaxVectorSize is less than _initial_vector_length, then MaxVectorSize should be used as the final value. > > This issue affects C2 autovectorization and some specific Vector API interfaces such as VectorSupport.getMaxLaneCount. > > We can verify the problem using the following test case: > > > import jdk.internal.vm.vector.VectorSupport; > > public class GetMaxVectorSizeTest { > public static void main(String[] args) { > final int maxLaneCount = VectorSupport.getMaxLaneCount(byte.class); > System.out.println("maxLaneCount:" + maxLaneCount); > } > } > > > The compile command is as follows: > > > javac --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest.java > > > RISC-V without the -XX:MaxVectorSize=16 has the following execution results(risc-v rvv vector length is set 256 bit): > > zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin$ ./java -XX:+UnlockExperimentalVMOptions -XX:+UseRVV --add-exports java.base/jdk.internal.vm.vector=ALL-UNNAMED GetMaxVectorSizeTest > maxLaneCount:32 > > > RISC-V using the -XX:MaxVectorSize=16 results in the following(risc-v rvv vector length is set 256 bit): > > > zifeihan at plct-c8:~/jdk-rvv/build/linux-riscv64-server-fastdebug/jdk/bin... This pull request has now been integrated. Changeset: a66b5df1 Author: Gui Cao Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/a66b5df14a163d2990e6dd746906942367e4fdb2 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod 8314618: RISC-V: -XX:MaxVectorSize does not work as expected Reviewed-by: fyang, dzhang ------------- PR: https://git.openjdk.org/jdk/pull/15356 From kbarrett at openjdk.org Tue Aug 22 04:20:51 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 22 Aug 2023 04:20:51 GMT Subject: RFR: 8314694: Separate checked_cast from globalDefinitions.hpp Message-ID: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> Please review this change which moves checked_cast from globalDefinitions.hpp to a separate file. As part of this change we modify files that use checked_cast to directly include that new file. There are around 80 such files, and that change constitutes the majority of the changed files and lines in this PR. This PR doesn't fix the definition of checked_cast (see JDK-8314258). It just moves the existing definition to a new file, in preparation for fixing it later. (I'm running tests on a fixed implementation.) An alternative is to move checked_cast to a new file but have globalDefinitions.hpp include that new file. This would avoid touching the include lists of currently using files. It seems to me better to actually separate it. Fortunately, there was only one copyright update needed. Most of the uses were added recently as part of addressing -Wconversion warnings, so those files have already had copyright updates recently. The other change was to move pointer_delta_as_int next to the related pointer_delta, and change it to use a direct assert and static_cast, rather than checked_cast. With the exception of the simple change to pointer_delta_as_int the changes in this PR are very simple and almost mechanical. To find the files needing an additional include and to demonstrate completing that task, I applied this command to the hotspot directory: egrep -r --files-with-matches --exclude-dir=.git " checked_cast<" . | \ xargs egrep --files-without-match "utilities/checkedCast.hpp" So perhaps this change is trivial, despite the number of files. Testing: mach5 tier1 ------------- Commit messages: - include checkedCast.hpp in cpu files - include checkedCast.hpp in cpu/aarch64 files - include checkedCast.hpp in cpu/x86 files - include checkedCast.hpp in os files - include checkedCast.hpp in remaining share files - include checkedCast.hpp in classfile files - include checkedCast.hpp in code files - include checkedCast.hpp in oops files - include checkedCast.hpp in opto files - include checkedCast.hpp in prims files - ... and 4 more: https://git.openjdk.org/jdk/compare/78f74bc8...261d5c02 Changes: https://git.openjdk.org/jdk/pull/15377/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15377&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314694 Stats: 161 lines in 82 files changed: 137 ins; 23 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15377/head:pull/15377 PR: https://git.openjdk.org/jdk/pull/15377 From kbarrett at openjdk.org Tue Aug 22 06:10:32 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 22 Aug 2023 06:10:32 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v17] In-Reply-To: References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: On Fri, 23 Jun 2023 02:31:11 GMT, Julian Waters wrote: >> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)). >> >> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used. >> >> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right >> >> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446)) > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'openjdk:master' into alignas > - Merge branch 'master' into alignas > - Merge branch 'openjdk:master' into alignas > - alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - ... and 7 more: https://git.openjdk.org/jdk/compare/5a82fa3b...bb9ae391 I think some of the uses of ZCACHE_ALIGNED might be wrong, but I don't think they are made any worse by this change. So looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/11431#pullrequestreview-1588430390 From jwaters at openjdk.org Tue Aug 22 06:13:51 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 22 Aug 2023 06:13:51 GMT Subject: RFR: 8250269: Replace ATTRIBUTE_ALIGNED with alignas [v17] In-Reply-To: References: <9QKV9cYFTo_1D8R-mI80lnewNkA0ceJNKFPbrvICxl4=.d6736b76-8324-4084-bede-6e144b4f6c04@github.com> Message-ID: On Fri, 23 Jun 2023 02:31:11 GMT, Julian Waters wrote: >> C++11 added the alignas attribute, for the purpose of specifying alignment on types, much like compiler specific syntax such as gcc's __attribute__((aligned(x))) or Visual C++'s __declspec(align(x)). >> >> We can phase out the use of the macro in favor of the standard attribute. In the meantime, we can replace the compiler specific definitions of ATTRIBUTE_ALIGNED with a portable definition. We might deprecate the use of the macro but changing its implementation quickly and cleanly applies the feature where the macro is being used. >> >> Note: With certain parts of HotSpot using ATTRIBUTE_ALIGNED so indiscriminately, this commit will likely take some time to get right >> >> This will require adding the alignas attribute to the list of language features approved for use in HotSpot code. (Completed with [8297912](https://github.com/openjdk/jdk/pull/11446)) > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'openjdk:master' into alignas > - Merge branch 'master' into alignas > - Merge branch 'openjdk:master' into alignas > - alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - Merge branch 'openjdk:master' into alignas > - ... and 7 more: https://git.openjdk.org/jdk/compare/5a82fa3b...bb9ae391 Thanks Kim! ------------- PR Comment: https://git.openjdk.org/jdk/pull/11431#issuecomment-1687504623 From stuefe at openjdk.org Tue Aug 22 06:57:28 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 22 Aug 2023 06:57:28 GMT Subject: RFR: 8314694: Separate checked_cast from globalDefinitions.hpp In-Reply-To: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> References: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> Message-ID: On Tue, 22 Aug 2023 04:13:13 GMT, Kim Barrett wrote: > Please review this change which moves checked_cast from globalDefinitions.hpp > to a separate file. As part of this change we modify files that use > checked_cast to directly include that new file. There are around 80 such > files, and that change constitutes the majority of the changed files and lines > in this PR. > > This PR doesn't fix the definition of checked_cast (see JDK-8314258). It just > moves the existing definition to a new file, in preparation for fixing it > later. (I'm running tests on a fixed implementation.) > > An alternative is to move checked_cast to a new file but have > globalDefinitions.hpp include that new file. This would avoid touching the > include lists of currently using files. It seems to me better to actually > separate it. > > Fortunately, there was only one copyright update needed. Most of the uses were > added recently as part of addressing -Wconversion warnings, so those files > have already had copyright updates recently. > > The other change was to move pointer_delta_as_int next to the related > pointer_delta, and change it to use a direct assert and static_cast, rather > than checked_cast. > > With the exception of the simple change to pointer_delta_as_int the changes > in this PR are very simple and almost mechanical. To find the files needing > an additional include and to demonstrate completing that task, I applied this > command to the hotspot directory: > > > egrep -r --files-with-matches --exclude-dir=.git " checked_cast<" . | \ > xargs egrep --files-without-match "utilities/checkedCast.hpp" > > > So perhaps this change is trivial, despite the number of files. > > Testing: > mach5 tier1 Looks good. Interesting how many of the touched cpp files did not include globalDefinitions.hpp. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15377#pullrequestreview-1588580027 From rcastanedalo at openjdk.org Tue Aug 22 07:53:03 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 22 Aug 2023 07:53:03 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) [v2] In-Reply-To: References: Message-ID: > This changeset ensures that the array copy stub underlying the intrinsic implementation of `Object.clone` only copies its (double-word aligned) payload, excluding the remaining object alignment padding words, when a non-default `ObjectAlignmentInBytes` value is used. This prevents the specialized ZGC stubs for `Object[]` array copy from processing undefined object alignment padding words as valid object pointers. For further details about the specific failure, see [initial analysis](https://bugs.openjdk.org/browse/JDK-8312749?focusedCommentId=14600658&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14600658) by Erik ?sterlund and Stefan Karlsson and comments in the regression test included in this changeset. > > As a side-benefit, the changeset simplifies the array size computation logic in `GraphKit::new_array()` by decoupling computation of header size and alignment padding size. > > #### Testing > > ##### Functionality > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - tier4-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; ZGC-specific tests only) > - tier6-9 (linux-x64; ZGC-specific tests only) > - tier1-3, and a few custom examples, applying [JDK-8139457](https://github.com/openjdk/jdk/pull/11044) (under review) on top of this changeset > > ##### Performance > > Tested performance on the following set of OpenJDK micro-benchmarks, on linux-x64 (for both G1 and ZGC, using different ObjectAlignmentInBytes values): > > - `openjdk.bench.java.lang.ArrayClone.byteClone` > - `openjdk.bench.java.lang.ArrayClone.intClone` > - `openjdk.bench.java.lang.ArrayFiddle.simple_clone` > - `openjdk.bench.java.lang.Clone.cloneLarge` > - `openjdk.bench.java.lang.Clone.cloneThreeDifferent` > > No significant regression was observed. Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision: Remove extra whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15288/files - new: https://git.openjdk.org/jdk/pull/15288/files/5c56a5e5..9b60e679 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15288&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15288&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15288/head:pull/15288 PR: https://git.openjdk.org/jdk/pull/15288 From rcastanedalo at openjdk.org Tue Aug 22 07:53:04 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 22 Aug 2023 07:53:04 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) In-Reply-To: References: Message-ID: <7QMMwkGUvN7YnPhwa8y5cb6lruJJnCWeR6D50_GWdXY=.e8f1936f-e4e4-4464-877c-9c045415823e@github.com> On Tue, 15 Aug 2023 12:43:56 GMT, Roberto Casta?eda Lozano wrote: > This changeset ensures that the array copy stub underlying the intrinsic implementation of `Object.clone` only copies its (double-word aligned) payload, excluding the remaining object alignment padding words, when a non-default `ObjectAlignmentInBytes` value is used. This prevents the specialized ZGC stubs for `Object[]` array copy from processing undefined object alignment padding words as valid object pointers. For further details about the specific failure, see [initial analysis](https://bugs.openjdk.org/browse/JDK-8312749?focusedCommentId=14600658&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14600658) by Erik ?sterlund and Stefan Karlsson and comments in the regression test included in this changeset. > > As a side-benefit, the changeset simplifies the array size computation logic in `GraphKit::new_array()` by decoupling computation of header size and alignment padding size. > > #### Testing > > ##### Functionality > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - tier4-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; ZGC-specific tests only) > - tier6-9 (linux-x64; ZGC-specific tests only) > - tier1-3, and a few custom examples, applying [JDK-8139457](https://github.com/openjdk/jdk/pull/11044) (under review) on top of this changeset > > ##### Performance > > Tested performance on the following set of OpenJDK micro-benchmarks, on linux-x64 (for both G1 and ZGC, using different ObjectAlignmentInBytes values): > > - `openjdk.bench.java.lang.ArrayClone.byteClone` > - `openjdk.bench.java.lang.ArrayClone.intClone` > - `openjdk.bench.java.lang.ArrayFiddle.simple_clone` > - `openjdk.bench.java.lang.Clone.cloneLarge` > - `openjdk.bench.java.lang.Clone.cloneThreeDifferent` > > No significant regression was observed. Thanks for reviewing, Tobias! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15288#issuecomment-1687653525 From ayang at openjdk.org Tue Aug 22 08:57:43 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 22 Aug 2023 08:57:43 GMT Subject: RFR: 8314749: Remove unimplemented _Copy_conjoint_oops_atomic Message-ID: Trivial removing dead code. ------------- Commit messages: - trivial Changes: https://git.openjdk.org/jdk/pull/15383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314749 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15383/head:pull/15383 PR: https://git.openjdk.org/jdk/pull/15383 From stuefe at openjdk.org Tue Aug 22 09:18:46 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 22 Aug 2023 09:18:46 GMT Subject: RFR: JDK-8314752: Use google test string comparision macros Message-ID: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> Small improvement to use google test's string comparison macros instead of raw C-functions. This makes the code more readable and provides us with automatic error output in case of string mismatches (so we don't have to print the values via "<<"). ------------- Commit messages: - start Changes: https://git.openjdk.org/jdk/pull/15355/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15355&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314752 Stats: 84 lines in 14 files changed: 8 ins; 15 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/15355.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15355/head:pull/15355 PR: https://git.openjdk.org/jdk/pull/15355 From rkennke at openjdk.org Tue Aug 22 11:52:33 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 22 Aug 2023 11:52:33 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: References: Message-ID: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Move away arrayOopDesc::header_size() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/7418fab0..aa9e06c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=50-51 Stats: 31 lines in 3 files changed: 14 ins; 11 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From coleenp at openjdk.org Tue Aug 22 11:57:28 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 22 Aug 2023 11:57:28 GMT Subject: RFR: 8314694: Separate checked_cast from globalDefinitions.hpp In-Reply-To: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> References: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> Message-ID: On Tue, 22 Aug 2023 04:13:13 GMT, Kim Barrett wrote: > Please review this change which moves checked_cast from globalDefinitions.hpp > to a separate file. As part of this change we modify files that use > checked_cast to directly include that new file. There are around 80 such > files, and that change constitutes the majority of the changed files and lines > in this PR. > > This PR doesn't fix the definition of checked_cast (see JDK-8314258). It just > moves the existing definition to a new file, in preparation for fixing it > later. (I'm running tests on a fixed implementation.) > > An alternative is to move checked_cast to a new file but have > globalDefinitions.hpp include that new file. This would avoid touching the > include lists of currently using files. It seems to me better to actually > separate it. > > Fortunately, there was only one copyright update needed. Most of the uses were > added recently as part of addressing -Wconversion warnings, so those files > have already had copyright updates recently. > > The other change was to move pointer_delta_as_int next to the related > pointer_delta, and change it to use a direct assert and static_cast, rather > than checked_cast. > > With the exception of the simple change to pointer_delta_as_int the changes > in this PR are very simple and almost mechanical. To find the files needing > an additional include and to demonstrate completing that task, I applied this > command to the hotspot directory: > > > egrep -r --files-with-matches --exclude-dir=.git " checked_cast<" . | \ > xargs egrep --files-without-match "utilities/checkedCast.hpp" > > > So perhaps this change is trivial, despite the number of files. > > Testing: > mach5 tier1 Looks good! src/hotspot/share/utilities/globalDefinitions.hpp line 485: > 483: size_t delta = pointer_delta(left, right, sizeof(T)); > 484: assert(delta <= size_t(INT_MAX), "pointer delta out of range: %zu", delta); > 485: return static_cast(delta); I see what you did here... ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15377#pullrequestreview-1589256447 PR Review Comment: https://git.openjdk.org/jdk/pull/15377#discussion_r1301529527 From rkennke at openjdk.org Tue Aug 22 11:58:50 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 22 Aug 2023 11:58:50 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Tue, 22 Aug 2023 11:52:33 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move away arrayOopDesc::header_size() > [b1f7665](https://github.com/openjdk/jdk/commit/b1f76655514c0371b10748f05ba9596ff38ee56c) I had a look at this and tried to move the whole payload initialisation into `initialize_body`. This makes the C1 changes more one-to-one with how the runtime allocates. That is, make `initialize_header` do what the `ObjArrayAllocator` would do with `do_zero = false`. Which is to initialise the Object up to `arrayOopDesc::header_size_in_bytes()`. Then have `initialize_body` initialise `base_offset_in_bytes` to the end of the object, leaving the potential alignment gap uninitialised. > > It is curious that we align the end to the padding instead of the smallest word containing the payload and just leave the end padding uninitialised like with the header gap. But I guess running with larger than BytesPerWord MinObjectAlignment is not common (on 64bit). > > There are also some mismatches in the current pr between parameter names in the header files and cpp files. Which I fixed. > > [844bd7e](https://github.com/openjdk/jdk/commit/844bd7e6390caf42aad1b4eef9d1adfd3df66b2e) I also looked at rewriting the ZObjArrayAllocator so that the extra unaligned write is only done for the segmented case as the normal call to `ObjArrayAllocator::initialize(mem);` already handles it. > > All patches, includes some more things I'm testing on-top of this. [pr/11044...xmas92:jdk:array_align_testing](https://github.com/openjdk/jdk/compare/pr/11044...xmas92:jdk:array_align_testing) Thanks, this looks great! I'm going to give it a try. This could now also subsume the filling of the klass-gap from initialize_header(), right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1688042724 From coleenp at openjdk.org Tue Aug 22 12:10:26 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 22 Aug 2023 12:10:26 GMT Subject: RFR: JDK-8314752: Use google test string comparision macros In-Reply-To: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> References: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> Message-ID: <3JQHsP9mfCAWfUVZBtBh9fUJ-a-Aqkf18WLFlaCj4UU=.8574c778-1b2f-4b49-ab08-9b459e021326@github.com> On Sun, 20 Aug 2023 10:09:49 GMT, Thomas Stuefe wrote: > Small improvement to use google test's string comparison macros instead of raw C-functions. > > This makes the code more readable and provides us with automatic error output in case of string mismatches (so we don't have to print the values via "<<"). Seems reasonable. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15355#pullrequestreview-1589280269 From jsjolen at openjdk.org Tue Aug 22 12:23:42 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 22 Aug 2023 12:23:42 GMT Subject: RFR: 8314644: Change "Rvalue references and move semantics" into an accepted feature Message-ID: Hi, I'd like to propose that rvalue references and move semantics are now considered permitted in the style guide. This change would allow for move constructors to be written. This enables more performant code, if the move ctr is less expensive than the copy ctr, but also more correct code. For the latter part, look at "8314571: GrowableArray should move its old data and not copy it". Here we can avoid using copy assignment, instead using move constructors, which more accurately reflects what is happening: The old elements are in fact moved, and not copied. Two useful std functions will become available to us with this change: 1. `std::move`, for explicitly moving a value. This is a slightly more powerful `static_cast(T)`, in that it also handles `T&` corectly. 2. `std::forward`, which simplifies the usage of perfect forwarding. Perfect forwarding is a technique where in copying is minimized. To quote Scott Meyers ( https://cppandbeyond.com/2011/04/25/session-announcement-adventures-in-perfect-forwarding/ ): > Perfecting forwarding is an important C++0x technique built atop rvalue references. It allows move semantics to be automatically applied, even when the source and the destination of a move are separated by intervening function calls. Common examples include constructors and setter functions that forward arguments they receive to the data members of the class they are initializing or setting, as well as standard library functions like make_shared, which ?perfect-forwards? its arguments to the class constructor of whatever object the to-be-created shared_ptr is to point to. Looking forward to your feedback, thank you. Johan ------------- Commit messages: - Also update html - Move over Rvalue references and move semantics to permitted features Changes: https://git.openjdk.org/jdk/pull/15386/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15386&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314644 Stats: 8 lines in 2 files changed: 5 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15386/head:pull/15386 PR: https://git.openjdk.org/jdk/pull/15386 From fjiang at openjdk.org Tue Aug 22 12:31:30 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 22 Aug 2023 12:31:30 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v2] In-Reply-To: References: Message-ID: On Fri, 18 Aug 2023 13:06:05 GMT, Ilya Gavrilin wrote: >> src/hotspot/cpu/riscv/riscv.ad line 7706: >> >>> 7704: match(Set dst (RoundDoubleMode src rmode)); >>> 7705: ins_cost(2 * XFER_COST + BRANCH_COST); >>> 7706: effect(TEMP_DEF dst, TEMP tmp1, TEMP tmp2, TEMP tmp3, KILL cr); >> >> Do we kill `cr` anywhere in the assembly code? > > According to documentation we have situations when convert instruction can set an error flag in the status register: >> All floating-point conversion instructions set the Inexact exception flag if the rounded result differs from the operand value and the Invalid exception flag is not set. [1] > > [1] https://five-embeddev.com/riscv-isa-manual/latest/f.html#single-precision-floating-point-conversion-and-move-instructions There is no dedicated flag register on risc-v. We choose `t1` as the flag register to bridge the RegFlag semantics in share and opto. Kill `cr` here is not needed since nowhere uses `t1` as tmp register. https://github.com/openjdk/jdk/blob/3e1b1bf94e7acf9717b837085e61fc05a7765de4/src/hotspot/cpu/riscv/riscv.ad#L404-L407 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1301571670 From dcubed at openjdk.org Tue Aug 22 15:18:51 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 22 Aug 2023 15:18:51 GMT Subject: RFR: 8314749: Remove unimplemented _Copy_conjoint_oops_atomic In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 08:51:12 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15383#pullrequestreview-1589688082 From kbarrett at openjdk.org Tue Aug 22 16:39:17 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 22 Aug 2023 16:39:17 GMT Subject: RFR: 8314694: Separate checked_cast from globalDefinitions.hpp In-Reply-To: References: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> Message-ID: On Tue, 22 Aug 2023 06:54:20 GMT, Thomas Stuefe wrote: >> Please review this change which moves checked_cast from globalDefinitions.hpp >> to a separate file. As part of this change we modify files that use >> checked_cast to directly include that new file. There are around 80 such >> files, and that change constitutes the majority of the changed files and lines >> in this PR. >> >> This PR doesn't fix the definition of checked_cast (see JDK-8314258). It just >> moves the existing definition to a new file, in preparation for fixing it >> later. (I'm running tests on a fixed implementation.) >> >> An alternative is to move checked_cast to a new file but have >> globalDefinitions.hpp include that new file. This would avoid touching the >> include lists of currently using files. It seems to me better to actually >> separate it. >> >> Fortunately, there was only one copyright update needed. Most of the uses were >> added recently as part of addressing -Wconversion warnings, so those files >> have already had copyright updates recently. >> >> The other change was to move pointer_delta_as_int next to the related >> pointer_delta, and change it to use a direct assert and static_cast, rather >> than checked_cast. >> >> With the exception of the simple change to pointer_delta_as_int the changes >> in this PR are very simple and almost mechanical. To find the files needing >> an additional include and to demonstrate completing that task, I applied this >> command to the hotspot directory: >> >> >> egrep -r --files-with-matches --exclude-dir=.git " checked_cast<" . | \ >> xargs egrep --files-without-match "utilities/checkedCast.hpp" >> >> >> So perhaps this change is trivial, despite the number of files. >> >> Testing: >> mach5 tier1 > > Looks good. > > Interesting how many of the touched cpp files did not include globalDefinitions.hpp. Thanks for reviews @tstuefe and @coleenp . > Interesting how many of the touched cpp files did not include globalDefinitions.hpp. Oh, there are much worse things than that! Take a look at utilities/elfFile.hpp :( There was some exploration of the "Include What You Use" tool a long time ago, but it seemed like it didn't quite do what we wanted. https://include-what-you-use.org/ I'll run the command to check for using files that are missing the new include before integration. That might show more files needing the include added. For example, https://github.com/openjdk/jdk/pull/15289 is ready to integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15377#issuecomment-1688526986 From ayang at openjdk.org Tue Aug 22 17:41:47 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 22 Aug 2023 17:41:47 GMT Subject: Integrated: 8314749: Remove unimplemented _Copy_conjoint_oops_atomic In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 08:51:12 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. This pull request has now been integrated. Changeset: ce1ded1a Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/ce1ded1a4f36b55717793f2bed4a64ce0353fc34 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8314749: Remove unimplemented _Copy_conjoint_oops_atomic Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/15383 From ayang at openjdk.org Tue Aug 22 17:40:48 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 22 Aug 2023 17:40:48 GMT Subject: RFR: 8314749: Remove unimplemented _Copy_conjoint_oops_atomic In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 08:51:12 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15383#issuecomment-1688615663 From mchung at openjdk.org Tue Aug 22 19:01:53 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 22 Aug 2023 19:01:53 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v3] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option. > If no method information is needed, this option can be used such that the > stack walker will save the overhead (1) to extract the method information > and (2) the memory used for the stack walking. In addition, this can also fix > > - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively > > Adding `NO_METHOD_TIME` option provides a simple way for existing code, > for example logging frameworks, to take advantage of this enhancement with > the least change as it can keep the existing implementation in traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance` > to create a stack walker instance: > > > StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(interestingClasses::contains) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > The alternative considered is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > ### Implementation Details > > If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]` > buffer that is filled by the VM during stack walking. `ClassFrameInfo` holds the > Class instance plus `flags` which indicate if it's caller sensitive or hidden. > With this change, `StackWalker::getCa... Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Replace NO_METHOD_INFO option with StackWalker.Kind enums - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - clean up - fix trailing whitespace - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Update LocalLongHelper.java - clean up - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - Add StackWalker.Option.NO_METHOD_INFO - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class - ... and 6 more: https://git.openjdk.org/jdk/compare/ce1ded1a...434d90cb ------------- Changes: https://git.openjdk.org/jdk/pull/15370/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=02 Stats: 1195 lines in 33 files changed: 694 ins; 204 del; 297 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From kbarrett at openjdk.org Tue Aug 22 19:14:17 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 22 Aug 2023 19:14:17 GMT Subject: RFR: JDK-8314752: Use google test string comparison macros In-Reply-To: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> References: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> Message-ID: On Sun, 20 Aug 2023 10:09:49 GMT, Thomas Stuefe wrote: > Small improvement to use google test's string comparison macros instead of raw C-functions. > > This makes the code more readable and provides us with automatic error output in case of string mismatches (so we don't have to print the values via "<<"). Looks good. test/hotspot/gtest/runtime/test_classPrinter.cpp line 59: > 57: ASSERT_THAT(o1, HasSubstr("method wait : (J)V")) << "must find java/lang/Object::wait(long)"; > 58: ASSERT_THAT(o1, HasSubstr("method wait : ()V")) << "must find java/lang/Object::wait()"; > 59: ASSERT_THAT(o1, Not(HasSubstr("method finalize : ()V"))) << "must not find java/lang/Object::finalize"; It required some research for me to understand how `Not` is working here and below. It's relying on ADL. That used to be at best unreliable or not work at all in some common compilers, but I think that's mostly fixed now. Since we don't use namespaces in HotSpot, ADL is not encountered much in our code. I'm okay with this, but others might be surprised too. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15355#pullrequestreview-1590119587 PR Review Comment: https://git.openjdk.org/jdk/pull/15355#discussion_r1302062858 From mchung at openjdk.org Tue Aug 22 19:14:18 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 22 Aug 2023 19:14:18 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v2] In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 21:10:36 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> The alternative considered is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` of `CLASS_INFO` kind creates `ClassFrameInfo[]` buffer that >> is... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > clean up I revised the patch to introduce new enums `CLASS_INFO` and `METHOD_INFO` to specify the kind of information a stack walker collects. The PR's description has been updated to reflect the revised API. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1688761021 From jsjolen at openjdk.org Tue Aug 22 20:41:50 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 22 Aug 2023 20:41:50 GMT Subject: RFR: 8314644: Change "Rvalue references and move semantics" into an accepted feature In-Reply-To: References: Message-ID: <6FQ7r95svqQsIn2maBkKzmk8Oy-Gy8QPUU4gIrz6XcM=.7bf9d3ba-19ff-4728-8801-8d912b060baf@github.com> On Tue, 22 Aug 2023 12:16:49 GMT, Johan Sj?len wrote: > Hi, > > I'd like to propose that rvalue references and move semantics are now considered permitted in the style guide. This change would allow for move constructors to be written. This enables more performant code, if the move ctr is less expensive than the copy ctr, but also more correct code. For the latter part, look at "8314571: GrowableArray should move its old data and not copy it". Here we can avoid using copy assignment, instead using move constructors, which more accurately reflects what is happening: The old elements are in fact moved, and not copied. > > Two useful std functions will become available to us with this change: > > 1. `std::move`, for explicitly moving a value. This is a slightly more powerful `static_cast(T)`, in that it also handles `T&` corectly. > 2. `std::forward`, which simplifies the usage of perfect forwarding. Perfect forwarding is a technique where in copying is minimized. To quote Scott Meyers ( https://cppandbeyond.com/2011/04/25/session-announcement-adventures-in-perfect-forwarding/ ): > >> Perfecting forwarding is an important C++0x technique built atop rvalue references. It allows move semantics to be automatically applied, even when the source and the destination of a move are separated by intervening function calls. Common examples include constructors and setter functions that forward arguments they receive to the data members of the class they are initializing or setting, as well as standard library functions like make_shared, which ?perfect-forwards? its arguments to the class constructor of whatever object the to-be-created shared_ptr is to point to. > > Looking forward to your feedback, thank you. > Johan After internal discussion I have come to the conclusion that this probably won't move forward, but if we have any external contributors who would like to voice their opinion I am happy to hear them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15386#issuecomment-1688892278 From kbarrett at openjdk.org Tue Aug 22 21:25:48 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 22 Aug 2023 21:25:48 GMT Subject: RFR: 8314694: Separate checked_cast from globalDefinitions.hpp [v2] In-Reply-To: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> References: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> Message-ID: > Please review this change which moves checked_cast from globalDefinitions.hpp > to a separate file. As part of this change we modify files that use > checked_cast to directly include that new file. There are around 80 such > files, and that change constitutes the majority of the changed files and lines > in this PR. > > This PR doesn't fix the definition of checked_cast (see JDK-8314258). It just > moves the existing definition to a new file, in preparation for fixing it > later. (I'm running tests on a fixed implementation.) > > An alternative is to move checked_cast to a new file but have > globalDefinitions.hpp include that new file. This would avoid touching the > include lists of currently using files. It seems to me better to actually > separate it. > > Fortunately, there was only one copyright update needed. Most of the uses were > added recently as part of addressing -Wconversion warnings, so those files > have already had copyright updates recently. > > The other change was to move pointer_delta_as_int next to the related > pointer_delta, and change it to use a direct assert and static_cast, rather > than checked_cast. > > With the exception of the simple change to pointer_delta_as_int the changes > in this PR are very simple and almost mechanical. To find the files needing > an additional include and to demonstrate completing that task, I applied this > command to the hotspot directory: > > > egrep -r --files-with-matches --exclude-dir=.git " checked_cast<" . | \ > xargs egrep --files-without-match "utilities/checkedCast.hpp" > > > So perhaps this change is trivial, despite the number of files. > > Testing: > mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - add include needed post-JDK-8314274 - Merge branch 'master' into move-checked-cast - include checkedCast.hpp in cpu files - include checkedCast.hpp in cpu/aarch64 files - include checkedCast.hpp in cpu/x86 files - include checkedCast.hpp in os files - include checkedCast.hpp in remaining share files - include checkedCast.hpp in classfile files - include checkedCast.hpp in code files - include checkedCast.hpp in oops files - ... and 6 more: https://git.openjdk.org/jdk/compare/024359a0...3a3fbb0b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15377/files - new: https://git.openjdk.org/jdk/pull/15377/files/261d5c02..3a3fbb0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15377&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15377&range=00-01 Stats: 361 lines in 49 files changed: 176 ins; 142 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/15377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15377/head:pull/15377 PR: https://git.openjdk.org/jdk/pull/15377 From sspitsyn at openjdk.org Wed Aug 23 09:09:20 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 23 Aug 2023 09:09:20 GMT Subject: RFR: 8314694: Separate checked_cast from globalDefinitions.hpp [v2] In-Reply-To: References: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> Message-ID: On Tue, 22 Aug 2023 21:25:48 GMT, Kim Barrett wrote: >> Please review this change which moves checked_cast from globalDefinitions.hpp >> to a separate file. As part of this change we modify files that use >> checked_cast to directly include that new file. There are around 80 such >> files, and that change constitutes the majority of the changed files and lines >> in this PR. >> >> This PR doesn't fix the definition of checked_cast (see JDK-8314258). It just >> moves the existing definition to a new file, in preparation for fixing it >> later. (I'm running tests on a fixed implementation.) >> >> An alternative is to move checked_cast to a new file but have >> globalDefinitions.hpp include that new file. This would avoid touching the >> include lists of currently using files. It seems to me better to actually >> separate it. >> >> Fortunately, there was only one copyright update needed. Most of the uses were >> added recently as part of addressing -Wconversion warnings, so those files >> have already had copyright updates recently. >> >> The other change was to move pointer_delta_as_int next to the related >> pointer_delta, and change it to use a direct assert and static_cast, rather >> than checked_cast. >> >> With the exception of the simple change to pointer_delta_as_int the changes >> in this PR are very simple and almost mechanical. To find the files needing >> an additional include and to demonstrate completing that task, I applied this >> command to the hotspot directory: >> >> >> egrep -r --files-with-matches --exclude-dir=.git " checked_cast<" . | \ >> xargs egrep --files-without-match "utilities/checkedCast.hpp" >> >> >> So perhaps this change is trivial, despite the number of files. >> >> Testing: >> mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - add include needed post-JDK-8314274 > - Merge branch 'master' into move-checked-cast > - include checkedCast.hpp in cpu files > - include checkedCast.hpp in cpu/aarch64 files > - include checkedCast.hpp in cpu/x86 files > - include checkedCast.hpp in os files > - include checkedCast.hpp in remaining share files > - include checkedCast.hpp in classfile files > - include checkedCast.hpp in code files > - include checkedCast.hpp in oops files > - ... and 6 more: https://git.openjdk.org/jdk/compare/f0750585...3a3fbb0b Changes in `src/hotspot/share/prims` folder look good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15377#pullrequestreview-1590815334 From stuefe at openjdk.org Wed Aug 23 09:17:18 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 23 Aug 2023 09:17:18 GMT Subject: RFR: JDK-8314752: Use google test string comparison macros In-Reply-To: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> References: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> Message-ID: On Sun, 20 Aug 2023 10:09:49 GMT, Thomas Stuefe wrote: > Small improvement to use google test's string comparison macros instead of raw C-functions. > > This makes the code more readable and provides us with automatic error output in case of string mismatches (so we don't have to print the values via "<<"). Thanks Coleen and Kim! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15355#issuecomment-1689293550 From aboldtch at openjdk.org Wed Aug 23 09:17:13 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 23 Aug 2023 09:17:13 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: <6VSa_6lNMg-OTtbJGz__nvEClO_1g3SWKN28OXqmqSY=.59bb55f4-e274-4bea-ac5d-df5cebcfe8bb@github.com> On Tue, 22 Aug 2023 11:55:36 GMT, Roman Kennke wrote: > This could now also subsume the filling of the klass-gap from initialize_header(), right? When `initialize_header` is used to create an array header it does not fill the klass gap. But it is always done for Instance object headers as the way that C1 is currently structured we are in a context where we do not know wether the klass gap is going to be used for fields or not. So it must always be cleared. We could move this clearing to `initialize_body`, but that would require a larger refactoring. I think the first step would be to fix the nomenclature and structure of the different headers. We would need something similar to `arrayOopDesc::header_size_in_bytes()` for `oopDesc`. And if the goal is to avoid initialising padding bytes the C1 allocate_object and allocate_array paths need to be reworked to know where the fields start. > I wonder if it makes sense to do this in a follow-up PR, to keep this PR focused? It's already quite long-running and re-testing and re-reviewing it all only makes it longer? With regards to the ZGC changes, I spoke with @stefank and we agree that as long as they are correct it would be fine if they go in as is, and have us (the ZGC team) clean it up in a later patch. For the C1 code I defer to someone else. In general looks like the C1 code has a lot of potential for cleanups regardless. I'll make sure to review the current patch later today. I think I have some comments on some of the comments on changed methods and inconstancies in naming between declarations and definitions. But nothing that should have to trigger retesting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1689446209 From stuefe at openjdk.org Wed Aug 23 09:17:23 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 23 Aug 2023 09:17:23 GMT Subject: Integrated: JDK-8314752: Use google test string comparison macros In-Reply-To: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> References: <5PnPKMjnoejbvMtmborDOgG4HUjU1tuNe-aqtJpDCfo=.dd2e8c3f-6f4d-45c4-a5c9-0fb8cc51f45d@github.com> Message-ID: <6VBdAHJTfbtotqqGb5Cr3cyUyXiQAXo0SnYESfBzAQk=.f7d68b40-8831-4589-b372-553f0970a625@github.com> On Sun, 20 Aug 2023 10:09:49 GMT, Thomas Stuefe wrote: > Small improvement to use google test's string comparison macros instead of raw C-functions. > > This makes the code more readable and provides us with automatic error output in case of string mismatches (so we don't have to print the values via "<<"). This pull request has now been integrated. Changeset: a0d0f21f Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/a0d0f21f0844d402191f5285a154294a2b18059a Stats: 84 lines in 14 files changed: 8 ins; 15 del; 61 mod 8314752: Use google test string comparison macros Reviewed-by: coleenp, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/15355 From hgreule at openjdk.org Wed Aug 23 09:17:26 2023 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 23 Aug 2023 09:17:26 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Tue, 22 Aug 2023 11:52:33 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move away arrayOopDesc::header_size() Note that this can break existing Java applications: import java.lang.invoke.*; import java.util.*; java.nio.*; class Aligned { public static void main(String[] args) throws Throwable { var handle = MethodHandles.byteArrayViewVarHandle(long[].class, ByteOrder.nativeOrder()); byte[] array = new byte[64]; handle.compareAndSet(array, 0, 0, 1234567890L); System.out.println(Arrays.toString(array)); } } This code currently runs fine but fails with this patch and running with `-XX:-UseCompressedClassPointers` due to the misaligned access. While the Javadocs make no guarantee about the alignment of byte arrays and even suggests a way to calculate the alignment, this should be considered here I think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1689544136 From haosun at openjdk.org Wed Aug 23 09:30:46 2023 From: haosun at openjdk.org (Hao Sun) Date: Wed, 23 Aug 2023 09:30:46 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v5] In-Reply-To: References: Message-ID: <42DlUbYAMI2FteifOMiOcIy_1Mrq_vvpPxdVoZb5nUg=.5279c696-c97e-4bd0-bf2d-054281ee8307@github.com> > ### Background > > 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. > > 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. > > 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. > > 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. > > 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. > > ### Goal > > This patch aims to make PAC-RET compatible with virtual threads. > > ### Requirements of virtual threads > > R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. > > R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. > > Note that more details can be found in the discussion [3]. > > ### Investigation > > We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. > > 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. > > 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. > > 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP should be preserved to make it easy to find this modifier in case of... Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Update aarch64.ad and jvmci AArch64TestAssembler.java Before this patch, rscratch1 is clobbered. With this patch, we use the rscratch1 register after we save it on the stack. In this way, the code would be consistent with macroAssembler_aarch64.cpp. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13322/files - new: https://git.openjdk.org/jdk/pull/13322/files/d89bb83b..894b3697 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13322&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13322&range=03-04 Stats: 18 lines in 2 files changed: 13 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13322/head:pull/13322 PR: https://git.openjdk.org/jdk/pull/13322 From rkennke at openjdk.org Wed Aug 23 09:39:48 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 23 Aug 2023 09:39:48 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Tue, 22 Aug 2023 11:52:33 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move away arrayOopDesc::header_size() > Note that this can break existing Java applications: > > ```java > import java.lang.invoke.*; > import java.util.*; > java.nio.*; > > class Aligned { > public static void main(String[] args) throws Throwable { > var handle = MethodHandles.byteArrayViewVarHandle(long[].class, ByteOrder.nativeOrder()); > byte[] array = new byte[64]; > handle.compareAndSet(array, 0, 0, 1234567890L); > System.out.println(Arrays.toString(array)); > } > } > ``` > > This code currently runs fine but fails with this patch and running with `-XX:-UseCompressedClassPointers` due to the misaligned access. While the Javadocs make no guarantee about the alignment of byte arrays and even suggests a way to calculate the alignment, this should be considered here I think. Thanks for pointing that out! The [spec](https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/invoke/MethodHandles.html#byteArrayViewVarHandle-java.lang.Class-java.nio.ByteOrder-) says this: "Access of bytes at an index may be aligned or misaligned for T, with respect to the underlying memory address, A say, associated with the array and index. If access is misaligned then access for anything other than the get and set access modes will result in an IllegalStateException. In such cases atomic access is only guaranteed with respect to the largest power of two that divides the GCD of A and the size (in bytes) of T." This reads to me as if all primitive arrays are required, by that spec, to be 8-byte aligned, because how else could the above be guaranteed? If so, then this PR would need to be dropped, or at least be reworked to only change object arrays. WDYT? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1689625577 From qamai at openjdk.org Wed Aug 23 09:51:34 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 23 Aug 2023 09:51:34 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Tue, 22 Aug 2023 11:52:33 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move away arrayOopDesc::header_size() I don't see anywhere in that statement regarding the alignment with respects to the index value, only to the underlying memory address. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1689646071 From rkennke at openjdk.org Wed Aug 23 10:14:48 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 23 Aug 2023 10:14:48 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Wed, 23 Aug 2023 09:48:27 GMT, Quan Anh Mai wrote: > I don't see anywhere in that statement regarding the alignment with respects to the index value, only to the underlying memory address. > > The following section even goes into details about obtaining the misalignment of the array base using byte buffer, which leads to me believing that the only requirement is that the congruence class of the base modulo 8 should be consistent. Yeah. Who could clarify this? @PaulSandoz maybe? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1689684648 From hgreule at openjdk.org Wed Aug 23 10:23:39 2023 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 23 Aug 2023 10:23:39 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Wed, 23 Aug 2023 10:11:42 GMT, Roman Kennke wrote: > I don't see anywhere in that statement regarding the alignment with respects to the index value, only to the underlying memory address. > > The following section even goes into details about obtaining the misalignment of the array base using byte buffer, which leads to me believing that the only requirement is that the congruence class of the base modulo 8 should be consistent. Yes, from my understanding, it is spec-conformant as long as all byte arrays have the same offset at runtime. And with the following change, the code also works: int offset = ByteBuffer.wrap(new byte[0]).alignmentOffset(0, Long.BYTES); System.out.println("Offset: " + offset); // prints 4 var handle = MethodHandles.byteArrayViewVarHandle(long[].class, ByteOrder.nativeOrder()); byte[] array = new byte[64]; handle.compareAndSet(array, offset, 0, 1234567890L); System.out.println(Arrays.toString(array)); // different result due to the offset My comment was more about the observable change in behavior, especially as people might relying on the (currently "right", but actually wrong) assumption that all arrays are aligned. Maybe this PR needs a CSR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1689697316 From bulasevich at openjdk.org Wed Aug 23 10:56:52 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Wed, 23 Aug 2023 10:56:52 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v7] In-Reply-To: References: Message-ID: > This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 > > The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. > > InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: > > > Cortex-A53 (Pi 3 Model B Rev 1.2) > > test1stInt2Types 37.5 37.358 0.38 > test1stInt3Types 160.166 148.04 8.19 > test1stInt5Types 158.131 147.955 6.88 > test2ndInt2Types 52.634 53.291 -1.23 > test2ndInt3Types 201.39 181.603 10.90 > test2ndInt5Types 195.722 176.707 10.76 > testIfaceCall 157.453 140.498 12.07 > testIfaceExtCall 175.46 154.351 13.68 > testMonomorphic 32.052 32.039 0.04 > AVG: 6.85 > > Cortex-A72 (Pi 4 Model B Rev 1.2) > > test1stInt2Types 27.4796 27.4738 0.02 > test1stInt3Types 66.0085 64.9374 1.65 > test1stInt5Types 67.9812 66.2316 2.64 > test2ndInt2Types 32.0581 32.062 -0.01 > test2ndInt3Types 68.2715 65.6643 3.97 > test2ndInt5Types 68.1012 65.8024 3.49 > testIfaceCall 64.0684 64.1811 -0.18 > testIfaceExtCall 91.6226 81.5867 12.30 > testMonomorphic 26.7161 26.7142 0.01 > AVG: 2.66 > > Neoverse N1 (m6g.metal) > > test1stInt2Types 2.9104 2.9086 0.06 > test1stInt3Types 10.9642 10.2909 6.54 > test1stInt5Types 10.9607 10.2856 6.56 > test2ndInt2Types 3.3410 3.3478 -0.20 > test2ndInt3Types 12.3291 11.3089 9.02 > test2ndInt5Types 12.328 11.2704 9.38 > testIfaceCall 11.0598 10.3657 6.70 > testIfaceExtCall 13.0692 11.2826 15.84 > testMonomorphic 2.2354 2.2341 0.06 > AVG: 6.00 > > Neoverse V1 (c7g.2xlarge) > > test1stInt2Types 2.2317 2.2320 -0.01 > test1stInt3Types 6.6884 6.1911 8.03 > test1stInt5Types 6.7334 6.2193 8.27 > test2ndInt2Types 2.4002 2.4013 -0.04 > test2ndInt3Types 7.9603 7.0372 13.12 > test2ndInt5Types 7.9532 7.0474 12.85 > testIfaceCall 6.7028 6.3272 5.94 > testIfaceExtCall 8.3253 6.9416 19.93 > testMonomorphic 1.2446 1.2544 -0.79 > AVG: 7.48 > > > Testing... Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - rework loop_scan_resolved_entry cycle as proposed - 8307352: AARCH64: Improve itable_stub ------------- Changes: https://git.openjdk.org/jdk/pull/13792/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=06 Stats: 130 lines in 3 files changed: 112 ins; 15 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13792/head:pull/13792 PR: https://git.openjdk.org/jdk/pull/13792 From stefank at openjdk.org Wed Aug 23 11:46:44 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 23 Aug 2023 11:46:44 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v51] In-Reply-To: References: Message-ID: <7qIAavMrsULDmtfIonlARBpnwnoTxyVcD8dRNBR80TY=.95da0dc6-0292-4acd-8142-407a3783b965@github.com> On Fri, 18 Aug 2023 16:20:21 GMT, Roman Kennke wrote: > Thanks, Stefan for checking this. Yes, arrayOop::header_size() is confusing. The only purpose of this method is to help a few code paths which need the header_size_in_bytes() to be aligned-up and converted to word-size. Not quite sure how to deal with it. Move it out to some different place? Name it differently? I want to make sure that we are on the same page about this: Do you agree with my assessment that that arrayOopDesc::header_size() does *not* align-up arrayOopDesc::header_size_in_bytes() in *all* configurations, and that that needs to be fixed? That was the main point of my post above. Personally, I think we could keep the function in arrayOopDesc as long as we give descriptive name that shows the readers that the function returns a something larger than the actual header size. Maybe `aligned_header_size[_in_words]` or `align_up_header_size[_in_words]? ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1689811416 From stefank at openjdk.org Wed Aug 23 12:01:45 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 23 Aug 2023 12:01:45 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Tue, 22 Aug 2023 11:52:33 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move away arrayOopDesc::header_size() FWIW, we also have this comment in Buffer.java: // Used by heap byte buffers or direct buffers with Unsafe access // For heap byte buffers this field will be the address relative to the // array base address and offset into that array. The address might // not align on a word boundary for slices, nor align at a long word // (8 byte) boundary for byte[] allocations on 32-bit systems. // For direct buffers it is the start address of the memory region. The // address might not align on a word boundary for slices, nor when created // using JNI, see NewDirectByteBuffer(void*, long). // Should ideally be declared final // NOTE: hoisted here for speed in JNI GetDirectBufferAddress long address; which I think indicates that alignmentOffset can return 4 even without this patch if you run your program on a 32-bit JVM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1689831299 From mdoerr at openjdk.org Wed Aug 23 12:29:20 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 23 Aug 2023 12:29:20 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Please check windows-aarch64 build error: unresolved external symbol dlopen_ext ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1689871700 From haosun at openjdk.org Wed Aug 23 12:54:39 2023 From: haosun at openjdk.org (Hao Sun) Date: Wed, 23 Aug 2023 12:54:39 GMT Subject: Withdrawn: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 08:00:20 GMT, Hao Sun wrote: > ### Background > > 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. > > 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. > > 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. > > 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. > > 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. > > ### Goal > > This patch aims to make PAC-RET compatible with virtual threads. > > ### Requirements of virtual threads > > R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. > > R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. > > Note that more details can be found in the discussion [3]. > > ### Investigation > > We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. > > 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. > > 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. > > 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP should be preserved to make it easy to find this modifier in case of... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13322 From haosun at openjdk.org Wed Aug 23 12:58:29 2023 From: haosun at openjdk.org (Hao Sun) Date: Wed, 23 Aug 2023 12:58:29 GMT Subject: RFR: 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret [v5] In-Reply-To: <42DlUbYAMI2FteifOMiOcIy_1Mrq_vvpPxdVoZb5nUg=.5279c696-c97e-4bd0-bf2d-054281ee8307@github.com> References: <42DlUbYAMI2FteifOMiOcIy_1Mrq_vvpPxdVoZb5nUg=.5279c696-c97e-4bd0-bf2d-054281ee8307@github.com> Message-ID: On Wed, 23 Aug 2023 09:30:46 GMT, Hao Sun wrote: >> ### Background >> >> 1. PAC-RET branch protection was initially implemented on Linux/AArch64 in JDK-8277204 [1]. >> >> 2. However, it was broken with the introduction of virtual threads [2], mainly because the continuation freeze/thaw mechanism would trigger stack copying to/from memory, whereas the saved and signed LR on the stack doesn't get re-signed accordingly. >> >> 3. PR-9067 [3] tried to implement the re-sign part, but it was not accepted because option "PreserveFramePointer" is always turned on by PAC-RET but this would slow down virtual threads by ~5-20x. >> >> 4. As a workaround, JDK-8288023 [4] disables PAC-RET when preview language features are enabled. Note that virtual thread is one preview feature then. >> >> 5. Virtual thread will become a permanent feature in JDK-21 [5][6]. >> >> ### Goal >> >> This patch aims to make PAC-RET compatible with virtual threads. >> >> ### Requirements of virtual threads >> >> R-1: Option "PreserveFramePointer" should be turned off. That is, PAC-RET implementation should not rely on frame pointer FP. Otherwise, the fast path in stack copying will never be taken. >> >> R-2: Use some invariant values to stack copying as the modifier, so as to avoid the PAC re-sign for continuation thaw, as the fast path in stack copying doesn't walk the frame. >> >> Note that more details can be found in the discussion [3]. >> >> ### Investigation >> >> We considered to use (relative) stack pointer SP, thread ID, PACStack [7] and value zero as the candidate modifier. >> >> 1. SP: In some scenarios, we need to authenticate the return address in places where the current SP doesn't match the SP on function entry. E.g. see the usage in Runtime1::generate_handle_exception(). Hence, neither absolute nor relative SP works. >> >> 2. thread ID (tid): It's invariant to virtual thread, but it's nontrivial to access it from the JIT side. We need 1) firstly resolve the address of current thread (See [8] as an example), and 2) get the tid field in the way like java_lang_Thread::thread_id(). I suppose this would introduce big performance overhead. Then can we turn to use "rthread" register (JavaThread object address) as the modifier? Unfortunately, it's not an invariant to virtual threads and PAC re-sign is still needed. >> >> 5. PACStack uses the signed return address of caller as the modifier to sign the callee's return address. In this way, we get one PACed call chain. The modifier should be saved into somewhere around the frame record. Inevitably, FP sh... > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Update aarch64.ad and jvmci AArch64TestAssembler.java > > Before this patch, rscratch1 is clobbered. > With this patch, we use the rscratch1 register after we save it on the > stack. > > In this way, the code would be consistent with > macroAssembler_aarch64.cpp. Closed by accident. Reopen it. Sorry for the noise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13322#issuecomment-1689913535 From rkennke at openjdk.org Wed Aug 23 14:16:16 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 23 Aug 2023 14:16:16 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v53] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix wrong alignment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/aa9e06c4..ee1e921a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=52 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=51-52 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From rkennke at openjdk.org Wed Aug 23 14:18:44 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 23 Aug 2023 14:18:44 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Tue, 22 Aug 2023 11:52:33 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move away arrayOopDesc::header_size() > > Thanks, Stefan for checking this. Yes, arrayOop::header_size() is confusing. The only purpose of this method is to help a few code paths which need the header_size_in_bytes() to be aligned-up and converted to word-size. Not quite sure how to deal with it. Move it out to some different place? Name it differently? > > I want to make sure that we are on the same page about this: Do you agree with my assessment that that arrayOopDesc::header_size() does _not_ align-up arrayOopDesc::header_size_in_bytes() in _all_ configurations, and that that needs to be fixed? That was the main point of my post above. Ohh, I think I misunderstood. Sorry. Indeed, you are right, that is a bug. Arguably, it's even a pre-existing bug, except that it never materialized because header_size_in_bytes() would previously already answer with an up-aligned value. After my last refactoring, the only remaining place where this was used was arrayOopDesc::max_array_length() and I fixed it there. (On a side-note: that method is in dire need of a rewrite, it is too conservative now and too messy, and, AFAICT, only exists because of 32-bit builds.) > Personally, I think we could keep the function in arrayOopDesc as long as we give descriptive name that shows the readers that the function returns a something larger than the actual header size. Maybe `aligned_header_size[_in_words]` or `align_up_header_size[_in_words]? My last refactoring eliminated 1 use (in unsafe.cpp) which I find better. It also eliminated the use in collectedHeap.cpp by reducing it to an inlined version that only deals with T_INT. I also inlined it into max_array_length(), which is now also reduced to a simpler case. I believe it's better that we don't have this method to begin with, it's only confusing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1690045932 From pchilanomate at openjdk.org Wed Aug 23 14:43:40 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 23 Aug 2023 14:43:40 GMT Subject: RFR: 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter Message-ID: Please review the following fix. The check in SharedRuntime::reresolve_call_site() "caller.is_compiled_frame() && !caller.is_deoptimized_frame()" fails when caller is Continuation.enterSpecial because it is a native method. This means that if the static callsite to Continuation.enter was patched to point to an nmethod and then the nmethod was marked non-entrant we will always call SharedRuntime::handle_wrong_method() thereafter when resolving Continuation.enter because the callsite will never be reset back to the clean state. Thanks to @kuksenko for all the performance analysis while debugging this. I tested the patch by running the test included in the original report (loom-dev mailing list) and verifying the issue is fixed. I also run mach5 tiers1-3 for sanity testing and will run all the upper tiers too. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/15403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314850 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15403/head:pull/15403 PR: https://git.openjdk.org/jdk/pull/15403 From rpressler at openjdk.org Wed Aug 23 14:45:37 2023 From: rpressler at openjdk.org (Ron Pressler) Date: Wed, 23 Aug 2023 14:45:37 GMT Subject: RFR: 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 14:25:12 GMT, Patricio Chilano Mateo wrote: > Please review the following fix. The check in SharedRuntime::reresolve_call_site() "caller.is_compiled_frame() && !caller.is_deoptimized_frame()" fails when caller is Continuation.enterSpecial because it is a native method. This means that if the static callsite to Continuation.enter was patched to point to an nmethod and then the nmethod was marked non-entrant we will always call SharedRuntime::handle_wrong_method() thereafter when resolving Continuation.enter because the callsite will never be reset back to the clean state. Thanks to @kuksenko for all the performance analysis while debugging this. > I tested the patch by running the test included in the original report (loom-dev mailing list) and verifying the issue is fixed. I also run mach5 tiers1-3 for sanity testing and will run all the upper tiers too. > > Thanks, > Patricio Marked as reviewed by rpressler (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15403#pullrequestreview-1591776617 From stuefe at openjdk.org Wed Aug 23 14:46:41 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 23 Aug 2023 14:46:41 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code Message-ID: Small change that reduces the number of loads generated by the C++ compiler for a narrow Klass decoding operation (`CompressedKlassPointers::decode_xxx()`. Stock: three loads (with two probably sharing a cache line) - UseCompressedClassPointers, encoding base and shift. 8b7b62: 48 8d 05 7f 1b c3 00 lea 0xc31b7f(%rip),%rax # 14e96e8 8b7b69: 0f b6 00 movzbl (%rax),%eax 8b7b6c: 84 c0 test %al,%al 8b7b6e: 0f 84 9c 00 00 00 je 8b7c10 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> 8b7b74: 48 8d 15 05 62 c6 00 lea 0xc66205(%rip),%rdx # 151dd80 <_ZN23CompressedKlassPointers6_shiftE> 8b7b7b: 8b 7b 08 mov 0x8(%rbx),%edi 8b7b7e: 8b 0a mov (%rdx),%ecx 8b7b80: 48 8d 15 01 62 c6 00 lea 0xc66201(%rip),%rdx # 151dd88 <_ZN23CompressedKlassPointers5_baseE> 8b7b87: 48 d3 e7 shl %cl,%rdi 8b7b8a: 48 03 3a add (%rdx),%rdi Patched: one load loads all three. Since shift occupies the lowest 8 bits, compiled code uses 8bit register; ditto the UseCompressedOops flag. 8ba302: 48 8d 05 97 9c c2 00 lea 0xc29c97(%rip),%rax # 14e3fa0 <_ZN23CompressedKlassPointers6_comboE> 8ba309: 48 8b 08 mov (%rax),%rcx 8ba30c: f6 c5 01 test $0x1,%ch # use compressed klass pointers? 8ba30f: 0f 84 9b 00 00 00 je 8ba3b0 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> 8ba315: 8b 7b 08 mov 0x8(%rbx),%edi 8ba318: 48 d3 e7 shl %cl,%rdi # shift 8ba31b: 66 31 c9 xor %cx,%cx # zero out lower 16 bits of base 8ba31e: 48 01 cf add %rcx,%rdi # add base 8ba321: 8b 4f 08 mov 0x8(%rdi),%ecx --- Performance measurements: G1, doing a full GC over a heap filled with 256 mio life j.l.Object instances. I see a reduction of Full Pause times between 1.2% and 5%. I am unsure how reliable these numbers are since, despite my efforts (running tests on isolated CPUs etc.), the standard deviation was quite high at ?4%. Still, in general, numbers seemed to go down rather than up. --- Future extensions: This patch uses the fact that the encoding base is aligned to metaspace reserve alignment (16 Mb). We only use 16 of those 24 bits of alignment shadow and could use more. A future UseCOH flag can easily nestle alongside the UseCCP bit in the second byte, and then we could test that second byte of the combo for either 0,1 or 3 (all possible valid permutations of these flags). ------------- Commit messages: - use 16 bit alignment - with raw bit ops Changes: https://git.openjdk.org/jdk/pull/15389/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15389&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314890 Stats: 45 lines in 3 files changed: 35 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/15389.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15389/head:pull/15389 PR: https://git.openjdk.org/jdk/pull/15389 From stefank at openjdk.org Wed Aug 23 14:46:48 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 23 Aug 2023 14:46:48 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Wed, 23 Aug 2023 14:15:12 GMT, Roman Kennke wrote: > My last refactoring eliminated 1 use (in unsafe.cpp) which I find better. It also eliminated the use in collectedHeap.cpp by reducing it to an inlined version that only deals with T_INT. I also inlined it into max_array_length(), which is now also reduced to a simpler case. I believe it's better that we don't have this method to begin with, it's only confusing. Ahh. I missed that update. Sounds good to me. There's still one reference to that function in `src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1690096055 From ogillespie at openjdk.org Wed Aug 23 15:05:23 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Wed, 23 Aug 2023 15:05:23 GMT Subject: RFR: 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 14:25:12 GMT, Patricio Chilano Mateo wrote: > Please review the following fix. The check in SharedRuntime::reresolve_call_site() "caller.is_compiled_frame() && !caller.is_deoptimized_frame()" fails when caller is Continuation.enterSpecial because it is a native method. This means that if the static callsite to Continuation.enter was patched to point to an nmethod and then the nmethod was marked non-entrant we will always call SharedRuntime::handle_wrong_method() thereafter when resolving Continuation.enter because the callsite will never be reset back to the clean state. Thanks to @kuksenko for all the performance analysis while debugging this. > I tested the patch by running the test included in the original report (loom-dev mailing list) and verifying the issue is fixed. I also run mach5 tiers1-3 for sanity testing and will run all the upper tiers too. > > Thanks, > Patricio Thanks for working on this. I'm not sure if this is useful, but I just did a quick test with the patch and I see some interesting performance changes. Context switches in the test go from ~160k to ~1m, and total time increases from 4 seconds to 4.8 seconds. However I do see lower CPU utilization. import java.util.concurrent.*; public class Main { public static void main(String[] args) throws Exception { for (int i = 0; i < 100; i++) { ExecutorService = Executors.newVirtualThreadPerTaskExecutor(); long start = System.currentTimeMillis(); for (int j = 0; j < 100_000; j++) e.submit(Main::task); e.shutdown(); e.awaitTermination(100, TimeUnit.MINUTES); long dur = System.currentTimeMillis() - start; System.out.println(dur + "ms"); } } static void task() { } } perf stat java -XX:+UnlockExperimentalVMOptions -XX:-DoJVMTIVirtualThreadTransitions Main.java Before patch 45,069.79 msec task-clock # 11.214 CPUs utilized 159,503 context-switches # 0.004 M/sec 16,250 cpu-migrations # 0.361 K/sec 182,820 page-faults # 0.004 M/sec 4.019077281 seconds time elapsed 44.004389000 seconds user 1.844216000 seconds sys After patch 39,830.77 msec task-clock # 8.217 CPUs utilized <--- reduced 1,094,192 context-switches # 0.027 M/sec <--- increased 91,803 cpu-migrations # 0.002 M/sec 185,841 page-faults # 0.005 M/sec 4.847430580 seconds time elapsed <--- increased 34.643548000 seconds user 10.396489000 seconds sys I appreciate this test may be total unrealistic and flawed, and I haven't had time to check where the context-switches are coming from, but figured I'd share the early results just in case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15403#issuecomment-1690130076 From rpressler at openjdk.org Wed Aug 23 15:09:24 2023 From: rpressler at openjdk.org (Ron Pressler) Date: Wed, 23 Aug 2023 15:09:24 GMT Subject: RFR: 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 15:02:58 GMT, Oli Gillespie wrote: >> Please review the following fix. The check in SharedRuntime::reresolve_call_site() "caller.is_compiled_frame() && !caller.is_deoptimized_frame()" fails when caller is Continuation.enterSpecial because it is a native method. This means that if the static callsite to Continuation.enter was patched to point to an nmethod and then the nmethod was marked non-entrant we will always call SharedRuntime::handle_wrong_method() thereafter when resolving Continuation.enter because the callsite will never be reset back to the clean state. Thanks to @kuksenko for all the performance analysis while debugging this. >> I tested the patch by running the test included in the original report (loom-dev mailing list) and verifying the issue is fixed. I also run mach5 tiers1-3 for sanity testing and will run all the upper tiers too. >> >> Thanks, >> Patricio > > Thanks for working on this. > > I'm not sure if this is useful, but I just did a quick test with the patch and I see some interesting performance changes. Context switches in the test go from ~160k to ~1m, and total time increases from 4 seconds to 4.8 seconds. However I do see lower CPU utilization. > > > import java.util.concurrent.*; > > public class Main { > public static void main(String[] args) throws Exception { > for (int i = 0; i < 100; i++) { > ExecutorService = Executors.newVirtualThreadPerTaskExecutor(); > long start = System.currentTimeMillis(); > for (int j = 0; j < 100_000; j++) e.submit(Main::task); > e.shutdown(); e.awaitTermination(100, TimeUnit.MINUTES); > long dur = System.currentTimeMillis() - start; > System.out.println(dur + "ms"); > } > } > > static void task() { } > } > > > > perf stat java -XX:+UnlockExperimentalVMOptions -XX:-DoJVMTIVirtualThreadTransitions Main.java > > > Before patch > > 45,069.79 msec task-clock # 11.214 CPUs utilized > 159,503 context-switches # 0.004 M/sec > 16,250 cpu-migrations # 0.361 K/sec > 182,820 page-faults # 0.004 M/sec > > 4.019077281 seconds time elapsed > > 44.004389000 seconds user > 1.844216000 seconds sys > > > > After patch > > 39,830.77 msec task-clock # 8.217 CPUs utilized <--- reduced > 1,094,192 context-switches # 0.027 M/sec <--- increased > 91,803 cpu-migrations # 0.002 M/sec > 185,841 page-faults # 0.005 M/sec > > 4.847430580 seconds time elapsed <--- increased > > 34.643548000 seconds user > 10.396489000 seconds sys > > > I appreciate this test may be total unrealistic and flawed, and I haven't had time to check where the context-switches are coming from, but figured I'd share the early results just in case. @olivergillespie That happens because the scheduler is starved. This is a known phenomenon that usually appears in artificial benchmarks with a lot of work but low parallelism. We've considered trying to fix that, but a fix would probably harm real workloads. If you set the parallelism to a lower number you will see a lower latency. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15403#issuecomment-1690135711 From ogillespie at openjdk.org Wed Aug 23 15:17:22 2023 From: ogillespie at openjdk.org (Oli Gillespie) Date: Wed, 23 Aug 2023 15:17:22 GMT Subject: RFR: 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter In-Reply-To: References: Message-ID: <7N8rgZfyoLvJl7uOezqk5b-3-3ko_gCKdIiUNEOjVzM=.ef9220e8-445b-4b43-84fa-a2d70b230044@github.com> On Wed, 23 Aug 2023 14:25:12 GMT, Patricio Chilano Mateo wrote: > Please review the following fix. The check in SharedRuntime::reresolve_call_site() "caller.is_compiled_frame() && !caller.is_deoptimized_frame()" fails when caller is Continuation.enterSpecial because it is a native method. This means that if the static callsite to Continuation.enter was patched to point to an nmethod and then the nmethod was marked non-entrant we will always call SharedRuntime::handle_wrong_method() thereafter when resolving Continuation.enter because the callsite will never be reset back to the clean state. Thanks to @kuksenko for all the performance analysis while debugging this. > I tested the patch by running the test included in the original report (loom-dev mailing list) and verifying the issue is fixed. I also run mach5 tiers1-3 for sanity testing and will run all the upper tiers too. > > Thanks, > Patricio Thanks! Indeed lowering `jdk.virtualThreadScheduler.parallelism` helps a lot and the improvement of the patch compared to before is quite clear at lower values. I'll be sure to test out the patch in my real workloads later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15403#issuecomment-1690149138 From mbaesken at openjdk.org Wed Aug 23 15:18:03 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 23 Aug 2023 15:18:03 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2] In-Reply-To: References: Message-ID: > Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. > Some examples : > Events::log_dll_message for hs-err files reporting > JFR event NativeLibraryLoad > There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), > this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information > > Offer an interface (e.g. jvm.cpp) to support this. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: windows aarch64 build issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15264/files - new: https://git.openjdk.org/jdk/pull/15264/files/94e25ad7..9ceec5e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=00-01 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15264.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264 PR: https://git.openjdk.org/jdk/pull/15264 From aph at openjdk.org Wed Aug 23 15:20:20 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Aug 2023 15:20:20 GMT Subject: RFR: 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 14:25:12 GMT, Patricio Chilano Mateo wrote: > Please review the following fix. The check in SharedRuntime::reresolve_call_site() "caller.is_compiled_frame() && !caller.is_deoptimized_frame()" fails when caller is Continuation.enterSpecial because it is a native method. This means that if the static callsite to Continuation.enter was patched to point to an nmethod and then the nmethod was marked non-entrant we will always call SharedRuntime::handle_wrong_method() thereafter when resolving Continuation.enter because the callsite will never be reset back to the clean state. Thanks to @kuksenko for all the performance analysis while debugging this. > I tested the patch by running the test included in the original report (loom-dev mailing list) and verifying the issue is fixed. I also run mach5 tiers1-3 for sanity testing and will run all the upper tiers too. > > Thanks, > Patricio Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15403#pullrequestreview-1591852172 From bchristi at openjdk.org Wed Aug 23 15:40:24 2023 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 23 Aug 2023 15:40:24 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v3] In-Reply-To: References: Message-ID: <2I1tRJQUo2wc1SK2L6Ah3ru77BIIucxnUSbFe5wiIBY=.bebde1f8-1803-4ad4-9602-949aaa644840@github.com> On Tue, 22 Aug 2023 19:01:53 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, >>... > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Replace NO_METHOD_INFO option with StackWalker.Kind enums > - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class > - clean up > - fix trailing whitespace > - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class > - Update LocalLongHelper.java > - clean up > - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class > - Add StackWalker.Option.NO_METHOD_INFO > - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class > - ... and 6 more: https://git.openjdk.org/jdk/compare/ce1ded1a...434d90cb Sorry for not getting a look at this earlier. I don't think adding a new `Kind` enum is the best way to do this. StackWalkers would be configured along two different axes (`Kind` _and_ `Options`). It changes the mental model, in that all StackWalkers would now be divided into two `Kind`s. I feel like this bleeds the implementation into the API a bit. The existing `Option` enum already provides a way to configure which frames are walked, and what information to include in those frames. I think adding a new `Option` value fits better. It's true that compatibility dictates that the default behavior be to _include_ method info, so the new option must _omit_ method info. If the `NO_METHOD_INFO` is disliked, perhaps a better name can be found - `SKIP_METHOD_INFO` or `OMIT_METHOD_INFO`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1690187998 From kvn at openjdk.org Wed Aug 23 17:53:28 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 23 Aug 2023 17:53:28 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) [v2] In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 07:53:03 GMT, Roberto Casta?eda Lozano wrote: >> This changeset ensures that the array copy stub underlying the intrinsic implementation of `Object.clone` only copies its (double-word aligned) payload, excluding the remaining object alignment padding words, when a non-default `ObjectAlignmentInBytes` value is used. This prevents the specialized ZGC stubs for `Object[]` array copy from processing undefined object alignment padding words as valid object pointers. For further details about the specific failure, see [initial analysis](https://bugs.openjdk.org/browse/JDK-8312749?focusedCommentId=14600658&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14600658) by Erik ?sterlund and Stefan Karlsson and comments in the regression test included in this changeset. >> >> As a side-benefit, the changeset simplifies the array size computation logic in `GraphKit::new_array()` by decoupling computation of header size and alignment padding size. >> >> #### Testing >> >> ##### Functionality >> >> - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) >> - tier4-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; ZGC-specific tests only) >> - tier6-9 (linux-x64; ZGC-specific tests only) >> - tier1-3, and a few custom examples, applying [JDK-8139457](https://github.com/openjdk/jdk/pull/11044) (under review) on top of this changeset >> >> ##### Performance >> >> Tested performance on the following set of OpenJDK micro-benchmarks, on linux-x64 (for both G1 and ZGC, using different ObjectAlignmentInBytes values): >> >> - `openjdk.bench.java.lang.ArrayClone.byteClone` >> - `openjdk.bench.java.lang.ArrayClone.intClone` >> - `openjdk.bench.java.lang.ArrayFiddle.simple_clone` >> - `openjdk.bench.java.lang.Clone.cloneLarge` >> - `openjdk.bench.java.lang.Clone.cloneThreeDifferent` >> >> No significant regression was observed. > > Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra whitespace Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15288#pullrequestreview-1592121689 From dfuchs at openjdk.org Wed Aug 23 18:23:27 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 23 Aug 2023 18:23:27 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v3] In-Reply-To: References: Message-ID: <9NLO5FAeCdO7hf3exlczvF2zvCVfw6i-p2Ai7r_qkS8=.3040e411-c79b-4f4b-b2cf-71087f84333a@github.com> On Tue, 22 Aug 2023 19:01:53 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, >>... > > Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Replace NO_METHOD_INFO option with StackWalker.Kind enums > - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class > - clean up > - fix trailing whitespace > - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class > - Update LocalLongHelper.java > - clean up > - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class > - Add StackWalker.Option.NO_METHOD_INFO > - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class > - ... and 6 more: https://git.openjdk.org/jdk/compare/ce1ded1a...434d90cb src/java.base/share/classes/java/lang/StackFrameInfo.java line 38: > 36: SharedSecrets.getJavaLangInvokeAccess(); > 37: > 38: private final boolean retainClassRef; Shouldn't `private final boolean retainClassRef` move to ClassFrameInfo? Isn't it strange that CLASS_INFO still implies RETAIN_CLASS_REFERENCE? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1303378176 From aboldtch at openjdk.org Wed Aug 23 18:48:40 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 23 Aug 2023 18:48:40 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v53] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 14:16:16 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix wrong alignment Only some inconsistencies I found with regards to parameter names and comments. Other than that it looks correct. As I noted in an earlier comment the ZGC changes is something we can cleanup in a followup PR. As for the C1 changes it would be nice to refactor it to not clear the parts that are part of the body in the header initialisation. But personally I do not believe it has to stall this PR. But I'll defer that. No strong opinion. As for the nomenclature surrounding the header, some effort into making it more clear and consistent would be appreciated. This is just a tangential comment: Personally I would prefer to have the `<...>_in_bytes` refer to offsets or sizes in bytes and `<...>` refer to them in the smallest word size which contain the exact property. Also have a naming distinction between the `header` and the `array_header`. Mostly because every object has a header but only arrays have an array_header. The `header_size` (in words) and `array_header_size` may be, but `header_size_in_bytes` and `array_header_size_in_bytes` are different. src/hotspot/share/oops/arrayOop.hpp line 59: > 57: // aligned 0 mod 8. The typeArrayOop itself must be aligned at least this > 58: // strongly. > 59: static bool element_type_should_be_aligned(BasicType type) { The comment above makes it sound like this is only valid for `typeArrayOop`. Should be updated to reflect the change. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Array.java line 63: > 61: // aligned 0 mod 8. The typeArrayOop itself must be aligned at least this > 62: // strongly. > 63: private static boolean elementTypeShouldBeAligned(BasicType type) { Same comment as `arrayOopDesc::element_type_should_be_aligned` ------------- PR Review: https://git.openjdk.org/jdk/pull/11044#pullrequestreview-1591458933 PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1303370974 PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1303392574 From aboldtch at openjdk.org Wed Aug 23 18:48:42 2023 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 23 Aug 2023 18:48:42 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v52] In-Reply-To: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> References: <_6PJwvbzmNI0Wcd1augppjCXr3-joMD8oCm44OCcImo=.0f082e39-1e2b-4ce2-b356-2a31aa18e597@github.com> Message-ID: On Tue, 22 Aug 2023 11:52:33 GMT, Roman Kennke wrote: >> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. >> >> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. >> >> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. >> >> Testing: >> - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) >> - [x] tier1 (x86_64, x86_32, aarch64, riscv) >> - [x] tier2 (x86_64, aarch64, riscv) >> - [x] tier3 (x86_64, riscv) > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move away arrayOopDesc::header_size() src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 274: > 272: verify_oop(obj); > 273: } > 274: void C1_MacroAssembler::allocate_array(Register obj, Register len, Register t1, Register t2, int base_offset_in_bytes, int f, Register klass, Label& slow_case) { Should also update declaration in the header files. Same goes for all platforms ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/11044#discussion_r1302930157 From simonis at openjdk.org Wed Aug 23 19:18:30 2023 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 23 Aug 2023 19:18:30 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: <6bcJmpd_g-Qq9sIr6YtdL7DMiXKxHXeeCYXv2Jm_WO8=.703eba8b-1dc7-4340-8405-ecabfefa4754@github.com> References: <6bcJmpd_g-Qq9sIr6YtdL7DMiXKxHXeeCYXv2Jm_WO8=.703eba8b-1dc7-4340-8405-ecabfefa4754@github.com> Message-ID: On Mon, 7 Aug 2023 09:04:57 GMT, Boris Ulasevich wrote: > > I wonder if you can get rid of `temp_reg3` (and the `holder_offset` argument of `MacroAssembler::lookup_interface_method_stub()`) by defining `resolved_klass_reg` as `r17` in `VtableStubs::create_itable_stub()` and defining `Register holder_offset = method_result` as local variable in `MacroAssembler::lookup_interface_method_stub()` (the usages of `holder_offset` and `method_result` don't seem to overlap). > > I think it does not work. Non-overlapping registers are already optimized: resolved_klass and method_result are actually reusing the same rmethod(r12) register. > > > Otherwise looks good. > > Thanks! Sorry if my comment was unclear. What I meant was this: diff --git a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp index 8bf3b37f471..6e91df7156f 100644 --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp @@ -1209,11 +1209,13 @@ void MacroAssembler::lookup_interface_method_stub(Register recv_klass, Register method_result, Register temp_itbl_klass, Register scan_temp, - Register holder_offset, int itable_index, Label& L_no_such_interface) { + // 'method_result' is only used as output register at the very end of this method. + // Until then we can reuse it as 'holder_offset'. + Register holder_offset = method_result; assert_different_registers(resolved_klass, recv_klass, holder_klass, temp_itbl_klass, scan_temp, holder_offset); - assert_different_registers(method_result, recv_klass, holder_klass, temp_itbl_klass, scan_temp, holder_offset); + assert_different_registers(method_result, recv_klass, holder_klass, temp_itbl_klass, scan_temp); int vtable_start_offset = in_bytes(Klass::vtable_start_offset()); int itable_offset_entry_size = itableOffsetEntry::size() * wordSize; diff --git a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp index 72dd98ab617..004bed97b7f 100644 --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp @@ -949,7 +949,6 @@ class MacroAssembler: public Assembler { Register method_result, Register temp_reg, Register temp_reg2, - Register temp_reg3, int itable_index, Label& L_no_such_interface); diff --git a/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp b/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp index 73736566c90..6e345c96ce2 100644 --- a/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp @@ -175,10 +175,9 @@ VtableStub* VtableStubs::create_itable_stub(int itable_index) { // so all registers except arguments are free at this point. const Register recv_klass_reg = r10; const Register holder_klass_reg = r16; // declaring interface klass (DECC) - const Register resolved_klass_reg = rmethod; // resolved interface klass (REFC) + const Register resolved_klass_reg = r17; // resolved interface klass (REFC) const Register temp_reg = r11; const Register temp_reg2 = r15; - const Register temp_reg3 = r17; const Register icholder_reg = rscratch2; Label L_no_such_interface; @@ -195,7 +194,7 @@ VtableStub* VtableStubs::create_itable_stub(int itable_index) { // Receiver subtype check against REFC. // Get selected method from declaring class and itable index __ lookup_interface_method_stub(recv_klass_reg, holder_klass_reg, resolved_klass_reg, rmethod, - temp_reg, temp_reg2, temp_reg3, itable_index, L_no_such_interface); + temp_reg, temp_reg2, itable_index, L_no_such_interface); // Reduce "estimate" such that "padding" does not drop below 8. const ptrdiff_t estimate = 124; I.e. make `resolved_klass_reg` different from `method_result` such that `method_result` can be reused as `holder_offset` because the two don't overlap. I leave it up to you if you want these changes. A quick check showed that they compile and successfully execute tier1 tests. Otherwise still looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13792#issuecomment-1690505953 From simonis at openjdk.org Wed Aug 23 19:18:29 2023 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 23 Aug 2023 19:18:29 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v7] In-Reply-To: References: Message-ID: <5zhQUPlCrC11jQClmvBcKczReGqXhGtJJqYeFVyJtVA=.6b24fd17-be3a-472c-ae82-58f2224c5f80@github.com> On Wed, 23 Aug 2023 10:56:52 GMT, Boris Ulasevich wrote: >> This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 >> >> The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. >> >> InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: >> >> >> Cortex-A53 (Pi 3 Model B Rev 1.2) >> >> test1stInt2Types 37.5 37.358 0.38 >> test1stInt3Types 160.166 148.04 8.19 >> test1stInt5Types 158.131 147.955 6.88 >> test2ndInt2Types 52.634 53.291 -1.23 >> test2ndInt3Types 201.39 181.603 10.90 >> test2ndInt5Types 195.722 176.707 10.76 >> testIfaceCall 157.453 140.498 12.07 >> testIfaceExtCall 175.46 154.351 13.68 >> testMonomorphic 32.052 32.039 0.04 >> AVG: 6.85 >> >> Cortex-A72 (Pi 4 Model B Rev 1.2) >> >> test1stInt2Types 27.4796 27.4738 0.02 >> test1stInt3Types 66.0085 64.9374 1.65 >> test1stInt5Types 67.9812 66.2316 2.64 >> test2ndInt2Types 32.0581 32.062 -0.01 >> test2ndInt3Types 68.2715 65.6643 3.97 >> test2ndInt5Types 68.1012 65.8024 3.49 >> testIfaceCall 64.0684 64.1811 -0.18 >> testIfaceExtCall 91.6226 81.5867 12.30 >> testMonomorphic 26.7161 26.7142 0.01 >> AVG: 2.66 >> >> Neoverse N1 (m6g.metal) >> >> test1stInt2Types 2.9104 2.9086 0.06 >> test1stInt3Types 10.9642 10.2909 6.54 >> test1stInt5Types 10.9607 10.2856 6.56 >> test2ndInt2Types 3.3410 3.3478 -0.20 >> test2ndInt3Types 12.3291 11.3089 9.02 >> test2ndInt5Types 12.328 11.2704 9.38 >> testIfaceCall 11.0598 10.3657 6.70 >> testIfaceExtCall 13.0692 11.2826 15.84 >> testMonomorphic 2.2354 2.2341 0.06 >> AVG: 6.00 >> >> Neoverse V1 (c7g.2xlarge) >> >> test1stInt2Types 2.2317 2.2320 -0.01 >> test1stInt3Types 6.6884 6.1911 8.03 >> test1stInt5Types 6.7334 6.2193 8.27 >> test2ndInt2Types 2.4002 2.4013 -0.04 >> test2ndInt3Types 7.9603 7.0372 13.12 >> test2ndInt5Types 7.9532 7.0474 12.85 >> testIfaceCall 6.7028 6.3272 5.94 >> testIfaceExtCall 8.3253 6.941... > > Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - rework loop_scan_resolved_entry cycle as proposed > - 8307352: AARCH64: Improve itable_stub Marked as reviewed by simonis (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13792#pullrequestreview-1592261614 From pchilanomate at openjdk.org Wed Aug 23 19:34:24 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 23 Aug 2023 19:34:24 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily [v3] In-Reply-To: References: Message-ID: <0F1KS0LLDHEmyrfhBzjZNU25Xd4O4P7YIwnG5RP94ko=.c4d97d6f-1609-4e62-abdf-3cde7ce0e809@github.com> On Mon, 21 Aug 2023 03:46:10 GMT, David Holmes wrote: >> We combine: >> >> address os::current_stack_base(); >> size_t os::current_stack_size(); >> >> into >> >> void os::current_stack_base_and_size(address* stack_base, size_t* stack_size) >> >> and so avoid making two underlying system calls. The os/platform specific specializations are handled by the `current_stack_region` calls. It made sense to modify that to export the `base` directly rather than the `bottom`. In doing that change it made sense to standardise on the the style of the code used (variable names etc) to make it easier to see where the 5 different versions were the same and where they differ. Having 5 versions is unfortunate ( 3 BSD: one per arch - zero, x64, aarch64; and 2 linux: zero and everything else), but trying to combine them with ifdefs would be even worse in my opinion. >> >> In theory there should be zero functional changes here. >> >> Testing: >> - Tiers 1-3 >> - All our internal builds in tiers 1-5 >> - GHA >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Promote os::::current_stack_region to os::current_stack_base_and_size Looks good to me. src/hotspot/os/linux/os_linux.cpp line 5372: > 5370: // ** P1 (aka bottom) and size are the address and stack size > 5371: // returned from pthread_attr_getstack(). > 5372: // ** P2 (aka stack top or base) = P1 - size) Preexisting, but isn't P2 = P1 + size? Also an extra parenthesis was left at the end. src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp line 714: > 712: // ** P1 (aka bottom) and size are the address and stack size > 713: // returned from pthread_attr_getstack(). > 714: // ** P2 (aka stack top or base) = P1 - size) Same thing here. src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp line 192: > 190: > 191: if (rslt != 0) > 192: fatal("pthread_stackseg_np failed with error = %s", rslt); %d ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15321#pullrequestreview-1592267815 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1303448267 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1303450521 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1303452755 From mchung at openjdk.org Wed Aug 23 20:27:38 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 23 Aug 2023 20:27:38 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v4] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker > collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used > instead and such stack walker will save the overhead (1) to extract the method information > and (2) the memory used for the stack walking. In addition, this can also fix > > - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: > > > StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(interestingClasses::contains) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, > it only needs a small change in calling `getInstance` method to request class only info... Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: - fix whitespace - move retainClassRef to ClassFrameInfo as a bit set in the flags field - fixup the factory methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/434d90cb..30984253 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=02-03 Stats: 109 lines in 10 files changed: 44 ins; 28 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From mchung at openjdk.org Wed Aug 23 20:27:41 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 23 Aug 2023 20:27:41 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v3] In-Reply-To: <9NLO5FAeCdO7hf3exlczvF2zvCVfw6i-p2Ai7r_qkS8=.3040e411-c79b-4f4b-b2cf-71087f84333a@github.com> References: <9NLO5FAeCdO7hf3exlczvF2zvCVfw6i-p2Ai7r_qkS8=.3040e411-c79b-4f4b-b2cf-71087f84333a@github.com> Message-ID: On Wed, 23 Aug 2023 18:12:15 GMT, Daniel Fuchs wrote: >> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Replace NO_METHOD_INFO option with StackWalker.Kind enums >> - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class >> - clean up >> - fix trailing whitespace >> - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class >> - Update LocalLongHelper.java >> - clean up >> - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class >> - Add StackWalker.Option.NO_METHOD_INFO >> - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class >> - ... and 6 more: https://git.openjdk.org/jdk/compare/ce1ded1a...434d90cb > > src/java.base/share/classes/java/lang/StackFrameInfo.java line 38: > >> 36: SharedSecrets.getJavaLangInvokeAccess(); >> 37: >> 38: private final boolean retainClassRef; > > Shouldn't `private final boolean retainClassRef` move to ClassFrameInfo? Isn't it strange that CLASS_INFO still implies RETAIN_CLASS_REFERENCE? I was planning to move `retainClassRef` to `ClassFrameInfo` as a bit set in the `flags` field. Thanks for catching this and reminding me to do that. Now updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1303501735 From kbarrett at openjdk.org Wed Aug 23 20:49:21 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 23 Aug 2023 20:49:21 GMT Subject: RFR: 8314644: Change "Rvalue references and move semantics" into an accepted feature In-Reply-To: References: Message-ID: <4kSB2HvQqJFZNMDrg_VBq26C1G54N5s3iLJnBAO8pCM=.e9ea3af4-fa44-4bb9-bc7b-aa47d5f0daf9@github.com> On Tue, 22 Aug 2023 12:16:49 GMT, Johan Sj?len wrote: > Hi, > > I'd like to propose that rvalue references and move semantics are now considered permitted in the style guide. This change would allow for move constructors to be written. This enables more performant code, if the move ctr is less expensive than the copy ctr, but also more correct code. For the latter part, look at "8314571: GrowableArray should move its old data and not copy it". Here we can avoid using copy assignment, instead using move constructors, which more accurately reflects what is happening: The old elements are in fact moved, and not copied. > > Two useful std functions will become available to us with this change: > > 1. `std::move`, for explicitly moving a value. This is a slightly more powerful `static_cast(T)`, in that it also handles `T&` corectly. > 2. `std::forward`, which simplifies the usage of perfect forwarding. Perfect forwarding is a technique where in copying is minimized. To quote Scott Meyers ( https://cppandbeyond.com/2011/04/25/session-announcement-adventures-in-perfect-forwarding/ ): > >> Perfecting forwarding is an important C++0x technique built atop rvalue references. It allows move semantics to be automatically applied, even when the source and the destination of a move are separated by intervening function calls. Common examples include constructors and setter functions that forward arguments they receive to the data members of the class they are initializing or setting, as well as standard library functions like make_shared, which ?perfect-forwards? its arguments to the class constructor of whatever object the to-be-created shared_ptr is to point to. > > Looking forward to your feedback, thank you. > Johan Some thoughts of mine, cribbed from that internal discussion. I'll preface by saying that I'm not fundamentally opposed to permitting at least some uses of move semantics in HotSpot code. I've thought about making a proposal in this area myself. I haven't, in part, because I've seen very bad bugs in both directions, so I keep waffling on the question. Also, I have to admit that the size of the Josuttis book on move semantics (http://www.cppmove.com/) has kind of put me off. I enjoyed reading it. But foisting it on other HotSpot developers feels a bit much. And most of us will need some understanding of it if any of us start using it. A specific problem we currently have is that there are lots of classes with default copy/assign constructors that really shouldn?t. At least some of those probably ought to be movable but not copyable. Others probably ought to be explicitly non-copyable, to prevent accidents. Move semantics is an excellent tool for some problems, much better than alternatives. Movable but not copyable objects is one example. Perfect forwarding is another. Unfortunately, it also seems to be a very sharp tool. (So totally in keeping with C++ culture. :) ) I think that if we do allow it, we need to do so with eyes open, and that we will want to provide some well thought out guidance, guardrails, &etc. There are several problems we need to address with such a proposal. One is when to define a class to be movable. I think that?s usually fairly easy to decide. Another is when to enable use of move, and how. That?s mostly an issue for holders of movable objects (containers, objects with movable data members, &etc). That?s less easy. Still another is when to use std::move explicitly. My experience is that?s often a source of really bad bugs. Though maybe less often than our current frequently bogus default copy/assign. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15386#issuecomment-1690615432 From jpbempel at openjdk.org Wed Aug 23 21:26:25 2023 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Wed, 23 Aug 2023 21:26:25 GMT Subject: RFR: 8308762: Metaspace leak with Instrumentation.retransform In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 14:34:38 GMT, Coleen Phillimore wrote: >> Fix a small leak in constant pool merging during retransformation of a class. If this class has a catch block with `Throwable`, the class `Throwable` is pre-resolved in the constant pool, while all the other classes are in a unresolved state. So the constant pool merging process was considering the entry with pre-resolved class as different compared to the destination and create a new entry. We now try to consider it as equal specially for Methodref/Fieldref. > > Also there is a nice test harness for class redefinition in the test/hotspot/jtreg/serviceability/jvmti/RedefineClasses tests that you might be able to use to add a test for this. Hey @coleenp could you review my last changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14780#issuecomment-1690660646 From coleenp at openjdk.org Wed Aug 23 21:34:22 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 23 Aug 2023 21:34:22 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v4] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 20:27:38 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, >>... > > Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: > > - fix whitespace > - move retainClassRef to ClassFrameInfo as a bit set in the flags field > - fixup the factory methods The VM changes look good. Promoting ResolvedMethodName seems more efficient in terms of space than MemberName. Is there anything to prevent Java code from calling ResolvedMethodName rm = new ResolvedMethodName(); since the Method* needs to be registered in the JVMs Hashtable? (for redefinition) ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1592445140 From daniel.daugherty at oracle.com Wed Aug 23 21:39:51 2023 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 23 Aug 2023 17:39:51 -0400 Subject: RFR: 8314644: Change "Rvalue references and move semantics" into an accepted feature In-Reply-To: References: Message-ID: <73c7d0af-429d-8f38-b270-486700f65be3@oracle.com> A couple of questions: - Are these C++ features supported in all of the compilers that we use/support ? in OpenJDK? I mean the Tier1 platforms that Oracle supports in our CI and the ? other platforms that OpenJDK supports in the GHA setups. - How do we gauge the quality of support for these C++ features in the set of ? compilers that we use/support in OpenJDK? - Is it possible, feasible and desirable to create standalone tests for these ? C++ features so that we can use the new tests to evaluate compiler upgrades? Dan On 8/22/23 8:23 AM, Johan Sj?len wrote: > Hi, > > I'd like to propose that rvalue references and move semantics are now considered permitted in the style guide. This change would allow for move constructors to be written. This enables more performant code, if the move ctr is less expensive than the copy ctr, but also more correct code. For the latter part, look at "8314571: GrowableArray should move its old data and not copy it". Here we can avoid using copy assignment, instead using move constructors, which more accurately reflects what is happening: The old elements are in fact moved, and not copied. > > Two useful std functions will become available to us with this change: > > 1. `std::move`, for explicitly moving a value. This is a slightly more powerful `static_cast(T)`, in that it also handles `T&` corectly. > 2. `std::forward`, which simplifies the usage of perfect forwarding. Perfect forwarding is a technique where in copying is minimized. To quote Scott Meyers ( https://cppandbeyond.com/2011/04/25/session-announcement-adventures-in-perfect-forwarding/ ): > >> Perfecting forwarding is an important C++0x technique built atop rvalue references. It allows move semantics to be automatically applied, even when the source and the destination of a move are separated by intervening function calls. Common examples include constructors and setter functions that forward arguments they receive to the data members of the class they are initializing or setting, as well as standard library functions like make_shared, which ?perfect-forwards? its arguments to the class constructor of whatever object the to-be-created shared_ptr is to point to. > Looking forward to your feedback, thank you. > Johan > > ------------- > > Commit messages: > - Also update html > - Move over Rvalue references and move semantics to permitted features > > Changes: https://git.openjdk.org/jdk/pull/15386/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15386&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8314644 > Stats: 8 lines in 2 files changed: 5 ins; 3 del; 0 mod > Patch: https://git.openjdk.org/jdk/pull/15386.diff > Fetch: git fetch https://git.openjdk.org/jdk.git pull/15386/head:pull/15386 > > PR: https://git.openjdk.org/jdk/pull/15386 From kbarrett at openjdk.org Wed Aug 23 22:14:11 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 23 Aug 2023 22:14:11 GMT Subject: RFR: 8314694: Separate checked_cast from globalDefinitions.hpp [v3] In-Reply-To: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> References: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> Message-ID: > Please review this change which moves checked_cast from globalDefinitions.hpp > to a separate file. As part of this change we modify files that use > checked_cast to directly include that new file. There are around 80 such > files, and that change constitutes the majority of the changed files and lines > in this PR. > > This PR doesn't fix the definition of checked_cast (see JDK-8314258). It just > moves the existing definition to a new file, in preparation for fixing it > later. (I'm running tests on a fixed implementation.) > > An alternative is to move checked_cast to a new file but have > globalDefinitions.hpp include that new file. This would avoid touching the > include lists of currently using files. It seems to me better to actually > separate it. > > Fortunately, there was only one copyright update needed. Most of the uses were > added recently as part of addressing -Wconversion warnings, so those files > have already had copyright updates recently. > > The other change was to move pointer_delta_as_int next to the related > pointer_delta, and change it to use a direct assert and static_cast, rather > than checked_cast. > > With the exception of the simple change to pointer_delta_as_int the changes > in this PR are very simple and almost mechanical. To find the files needing > an additional include and to demonstrate completing that task, I applied this > command to the hotspot directory: > > > egrep -r --files-with-matches --exclude-dir=.git " checked_cast<" . | \ > xargs egrep --files-without-match "utilities/checkedCast.hpp" > > > So perhaps this change is trivial, despite the number of files. > > Testing: > mach5 tier1 Kim Barrett 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 17 additional commits since the last revision: - Merge branch 'master' into move-checked-cast - add include needed post-JDK-8314274 - Merge branch 'master' into move-checked-cast - include checkedCast.hpp in cpu files - include checkedCast.hpp in cpu/aarch64 files - include checkedCast.hpp in cpu/x86 files - include checkedCast.hpp in os files - include checkedCast.hpp in remaining share files - include checkedCast.hpp in classfile files - include checkedCast.hpp in code files - ... and 7 more: https://git.openjdk.org/jdk/compare/9f4151d6...59862b39 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15377/files - new: https://git.openjdk.org/jdk/pull/15377/files/3a3fbb0b..59862b39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15377&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15377&range=01-02 Stats: 1729 lines in 65 files changed: 1256 ins; 162 del; 311 mod Patch: https://git.openjdk.org/jdk/pull/15377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15377/head:pull/15377 PR: https://git.openjdk.org/jdk/pull/15377 From sviswanathan at openjdk.org Wed Aug 23 22:15:47 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 23 Aug 2023 22:15:47 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v2] In-Reply-To: <-IX3BljB1GgGEkEahSITcmKZnYnkBiT-9-FgA9uDPFY=.69cc9293-84f6-40da-951c-9b078522a418@github.com> References: <-IX3BljB1GgGEkEahSITcmKZnYnkBiT-9-FgA9uDPFY=.69cc9293-84f6-40da-951c-9b078522a418@github.com> Message-ID: On Thu, 10 Aug 2023 00:49:59 GMT, Scott Gibbons wrote: >> Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. >> >> Tested tier1. > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Move mxcsr code after denom > num test. src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp line 299: > 297: __ movl(rcx, rax); > 298: __ orl(rcx, 0x7f80); > 299: __ movl(Address(rsp, 0x04), rcx); No need to do stmxcsr, we could define mxcsr_rz on similar lines as mxcsr_std as part of StubGenerator::create_control_words() and use those in fmod. src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp line 325: > 323: __ andl(rax, 0x6000); > 324: __ cmpl(rax, 0x2000); > 325: __ jcc(Assembler::equal, L_10c1); Some of the jcc and jmp could be generated as short branches where feasible. Also the stub and the loop entries could be aligned to 16 bytes for better perf. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15210#discussion_r1303589868 PR Review Comment: https://git.openjdk.org/jdk/pull/15210#discussion_r1303590641 From kbarrett at openjdk.org Wed Aug 23 22:35:37 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 23 Aug 2023 22:35:37 GMT Subject: Integrated: 8314694: Separate checked_cast from globalDefinitions.hpp In-Reply-To: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> References: <_HJ33eynraYrhRwaMqafTXLb2yUidQX1V8lfs162q5U=.09e409d2-2b66-4705-9b43-3d3bc965f188@github.com> Message-ID: <4egkZY7xlfiAZ9XaLNnQWDCB3_71vWH9FpcTvirp-PE=.ae1a2d67-fa77-4985-8704-a79166986369@github.com> On Tue, 22 Aug 2023 04:13:13 GMT, Kim Barrett wrote: > Please review this change which moves checked_cast from globalDefinitions.hpp > to a separate file. As part of this change we modify files that use > checked_cast to directly include that new file. There are around 80 such > files, and that change constitutes the majority of the changed files and lines > in this PR. > > This PR doesn't fix the definition of checked_cast (see JDK-8314258). It just > moves the existing definition to a new file, in preparation for fixing it > later. (I'm running tests on a fixed implementation.) > > An alternative is to move checked_cast to a new file but have > globalDefinitions.hpp include that new file. This would avoid touching the > include lists of currently using files. It seems to me better to actually > separate it. > > Fortunately, there was only one copyright update needed. Most of the uses were > added recently as part of addressing -Wconversion warnings, so those files > have already had copyright updates recently. > > The other change was to move pointer_delta_as_int next to the related > pointer_delta, and change it to use a direct assert and static_cast, rather > than checked_cast. > > With the exception of the simple change to pointer_delta_as_int the changes > in this PR are very simple and almost mechanical. To find the files needing > an additional include and to demonstrate completing that task, I applied this > command to the hotspot directory: > > > egrep -r --files-with-matches --exclude-dir=.git " checked_cast<" . | \ > xargs egrep --files-without-match "utilities/checkedCast.hpp" > > > So perhaps this change is trivial, despite the number of files. > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: c077be47 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/c077be47688a845e99bce444f2354f1d819783a6 Stats: 163 lines in 83 files changed: 138 ins; 23 del; 2 mod 8314694: Separate checked_cast from globalDefinitions.hpp Reviewed-by: stuefe, coleenp, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/15377 From dholmes at openjdk.org Wed Aug 23 22:56:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 23 Aug 2023 22:56:35 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily [v4] In-Reply-To: References: Message-ID: > We combine: > > address os::current_stack_base(); > size_t os::current_stack_size(); > > into > > void os::current_stack_base_and_size(address* stack_base, size_t* stack_size) > > and so avoid making two underlying system calls. The os/platform specific specializations are handled by the `current_stack_region` calls. It made sense to modify that to export the `base` directly rather than the `bottom`. In doing that change it made sense to standardise on the the style of the code used (variable names etc) to make it easier to see where the 5 different versions were the same and where they differ. Having 5 versions is unfortunate ( 3 BSD: one per arch - zero, x64, aarch64; and 2 linux: zero and everything else), but trying to combine them with ifdefs would be even worse in my opinion. > > In theory there should be zero functional changes here. > > Testing: > - Tiers 1-3 > - All our internal builds in tiers 1-5 > - GHA > > Thanks. David Holmes has updated the pull request incrementally with two additional commits since the last revision: - extra parens - Fix pre-existing error in comment: P2 = P1 + size (not minus) Fix format specifier. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15321/files - new: https://git.openjdk.org/jdk/pull/15321/files/4e22dab0..a3a6102e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15321&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15321&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15321/head:pull/15321 PR: https://git.openjdk.org/jdk/pull/15321 From dholmes at openjdk.org Wed Aug 23 22:56:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 23 Aug 2023 22:56:37 GMT Subject: RFR: 8303852: current_stack_region() gets called twice unnecessarily [v3] In-Reply-To: <0F1KS0LLDHEmyrfhBzjZNU25Xd4O4P7YIwnG5RP94ko=.c4d97d6f-1609-4e62-abdf-3cde7ce0e809@github.com> References: <0F1KS0LLDHEmyrfhBzjZNU25Xd4O4P7YIwnG5RP94ko=.c4d97d6f-1609-4e62-abdf-3cde7ce0e809@github.com> Message-ID: On Wed, 23 Aug 2023 19:31:44 GMT, Patricio Chilano Mateo wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Promote os::::current_stack_region to os::current_stack_base_and_size > > Looks good to me. Thanks for the review @pchilano and for catching those typos! > src/hotspot/os/linux/os_linux.cpp line 5372: > >> 5370: // ** P1 (aka bottom) and size are the address and stack size >> 5371: // returned from pthread_attr_getstack(). >> 5372: // ** P2 (aka stack top or base) = P1 - size) > > Preexisting, but isn't P2 = P1 + size? Also an extra parenthesis was left at the end. Good catch! > src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp line 192: > >> 190: >> 191: if (rslt != 0) >> 192: fatal("pthread_stackseg_np failed with error = %s", rslt); > > %d Fixed - thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15321#issuecomment-1690745328 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1303618308 PR Review Comment: https://git.openjdk.org/jdk/pull/15321#discussion_r1303617402 From dholmes at openjdk.org Wed Aug 23 22:56:38 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 23 Aug 2023 22:56:38 GMT Subject: Integrated: 8303852: current_stack_region() gets called twice unnecessarily In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 02:45:54 GMT, David Holmes wrote: > We combine: > > address os::current_stack_base(); > size_t os::current_stack_size(); > > into > > void os::current_stack_base_and_size(address* stack_base, size_t* stack_size) > > and so avoid making two underlying system calls. The os/platform specific specializations are handled by the `current_stack_region` calls. It made sense to modify that to export the `base` directly rather than the `bottom`. In doing that change it made sense to standardise on the the style of the code used (variable names etc) to make it easier to see where the 5 different versions were the same and where they differ. Having 5 versions is unfortunate ( 3 BSD: one per arch - zero, x64, aarch64; and 2 linux: zero and everything else), but trying to combine them with ifdefs would be even worse in my opinion. > > In theory there should be zero functional changes here. > > Testing: > - Tiers 1-3 > - All our internal builds in tiers 1-5 > - GHA > > Thanks. This pull request has now been integrated. Changeset: 4a50e875 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/4a50e87592d76cf1ee315f47b4da1e1156cff7cf Stats: 254 lines in 10 files changed: 33 ins; 118 del; 103 mod 8303852: current_stack_region() gets called twice unnecessarily Reviewed-by: stuefe, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/15321 From sgibbons at openjdk.org Wed Aug 23 23:17:00 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Wed, 23 Aug 2023 23:17:00 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v3] In-Reply-To: References: Message-ID: > Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. > > Tested tier1. Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: mxcsr fix; address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15210/files - new: https://git.openjdk.org/jdk/pull/15210/files/5b1d251f..31e6000e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15210&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15210&range=01-02 Stats: 51 lines in 4 files changed: 11 ins; 14 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/15210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15210/head:pull/15210 PR: https://git.openjdk.org/jdk/pull/15210 From mchung at openjdk.org Wed Aug 23 23:29:25 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 23 Aug 2023 23:29:25 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v4] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 20:27:38 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, >>... > > Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: > > - fix whitespace > - move retainClassRef to ClassFrameInfo as a bit set in the flags field > - fixup the factory methods We can create `ResolvedMethodName` object and VM can fill in `Method*` and the java mirror without the object allocation. The question is whether we need to store it in the `ResolvedMethodTable`. One scenario is: if the user caches `StackFrame` objects for later us, when the frame is being accessed, the method is already redefined. Can it find the method information the old Method* vmentry? Maybe we can do something like the backtrace? Another question is: if RMN is not registered in the JVM hashtable, is it possible for the class of the method being unloaded? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1690770829 From amitkumar at openjdk.org Thu Aug 24 05:25:26 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 24 Aug 2023 05:25:26 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 11:21:47 GMT, Amit Kumar wrote: > [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. > > For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. > > fastdebug build tested on **s390** & **apple m1-pro**. Hi @dholmes-ora, Would you please take a look at this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14902#issuecomment-1691021603 From dholmes at openjdk.org Thu Aug 24 06:02:26 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 24 Aug 2023 06:02:26 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() In-Reply-To: References: Message-ID: <6Pnma7rQPeDo5EjtmFeYi8BnsREjj_h8X8TmhsiXCro=.348d26d9-da05-4645-87bc-0b3e2e87e07e@github.com> On Mon, 17 Jul 2023 11:21:47 GMT, Amit Kumar wrote: > [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. > > For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. > > fastdebug build tested on **s390** & **apple m1-pro**. This seems reasonable in principle, but given that this definition inline int frame::interpreter_frame_monitor_size_in_bytes() { return frame::interpreter_frame_monitor_size() * wordSize; } is the same on all platforms then we should define it in ./share/runtime/frame.inline.hpp Thanks. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14902#pullrequestreview-1592831988 From stuefe at openjdk.org Thu Aug 24 06:22:57 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 24 Aug 2023 06:22:57 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v2] In-Reply-To: References: Message-ID: > Small change that reduces the number of loads generated by the C++ compiler for a narrow Klass decoding operation (`CompressedKlassPointers::decode_xxx()`. > > Stock: three loads (with two probably sharing a cache line) - UseCompressedClassPointers, encoding base and shift. > > > 8b7b62: 48 8d 05 7f 1b c3 00 lea 0xc31b7f(%rip),%rax # 14e96e8 > 8b7b69: 0f b6 00 movzbl (%rax),%eax > 8b7b6c: 84 c0 test %al,%al > 8b7b6e: 0f 84 9c 00 00 00 je 8b7c10 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> > 8b7b74: 48 8d 15 05 62 c6 00 lea 0xc66205(%rip),%rdx # 151dd80 <_ZN23CompressedKlassPointers6_shiftE> > 8b7b7b: 8b 7b 08 mov 0x8(%rbx),%edi > 8b7b7e: 8b 0a mov (%rdx),%ecx > 8b7b80: 48 8d 15 01 62 c6 00 lea 0xc66201(%rip),%rdx # 151dd88 <_ZN23CompressedKlassPointers5_baseE> > 8b7b87: 48 d3 e7 shl %cl,%rdi > 8b7b8a: 48 03 3a add (%rdx),%rdi > > > Patched: one load loads all three. Since shift occupies the lowest 8 bits, compiled code uses 8bit register; ditto the UseCompressedOops flag. > > > 8ba302: 48 8d 05 97 9c c2 00 lea 0xc29c97(%rip),%rax # 14e3fa0 <_ZN23CompressedKlassPointers6_comboE> > 8ba309: 48 8b 08 mov (%rax),%rcx > 8ba30c: f6 c5 01 test $0x1,%ch # use compressed klass pointers? > 8ba30f: 0f 84 9b 00 00 00 je 8ba3b0 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> > 8ba315: 8b 7b 08 mov 0x8(%rbx),%edi > 8ba318: 48 d3 e7 shl %cl,%rdi # shift > 8ba31b: 66 31 c9 xor %cx,%cx # zero out lower 16 bits of base > 8ba31e: 48 01 cf add %rcx,%rdi # add base > 8ba321: 8b 4f 08 mov 0x8(%rdi),%ecx > > --- > > Performance measurements: > > G1, doing a full GC over a heap filled with 256 mio life j.l.Object instances. > > I see a reduction of Full Pause times between 1.2% and 5%. I am unsure how reliable these numbers are since, despite my efforts (running tests on isolated CPUs etc.), the standard deviation was quite high at ?4%. Still, in general, numbers seemed to go down rather than up. > > --- > > Future extensions: > > This patch uses the fact that the encoding base is aligned to metaspace reserve alignment (16 Mb). We only use 16 of those 24 bits of alignment shadow and could us... Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: fix -UseCCP case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15389/files - new: https://git.openjdk.org/jdk/pull/15389/files/bc0bd12b..12d19a06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15389&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15389&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15389.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15389/head:pull/15389 PR: https://git.openjdk.org/jdk/pull/15389 From mbaesken at openjdk.org Thu Aug 24 07:29:25 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 24 Aug 2023 07:29:25 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: <3Z3DhL13S8nSO7g4EaiOmCxTAZERbtP-GlDzlHW-d34=.3a8a9c47-b3e6-4b7c-afac-567ab81f47c8@github.com> On Wed, 23 Aug 2023 12:26:36 GMT, Martin Doerr wrote: > Please check windows-aarch64 build error: unresolved external symbol dlopen_ext Hi Martin, thanks ! I did a small adjustment, now the windows aarch64 build works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1691148432 From shade at openjdk.org Thu Aug 24 07:55:01 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 24 Aug 2023 07:55:01 GMT Subject: RFR: 8313202: MutexLocker should disallow null Mutexes [v5] In-Reply-To: References: Message-ID: <5JqYLMqwPshUm2wyR1rQHndI08xNyDDkj1EqrJwIl3k=.11918918-a906-48ca-8053-e8fa8648d8cd@github.com> > As seen in [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081), it is fairly easy to pass nullptr `Mutex` to `MutexLocker` by accident, which would just silently avoid the lock. > > There are a few places in Hotspot where we pass `nullptr` to simulate re-entrancy and/or conditionally take the lock. Those places can be more explicit, and the default `MutexLocker` can disallow nullptrs for extra safety. > > Open for some bikeshedding on the names of the new `MutexLockers`. Particularly `ReentrantMutexLocker` might lull readers into believing it does safepoint checks on re-entrant "lock", which it actually does not do. > > More thorough testing with different GC/JIT combinations is running now, we might find more issues there. Meanwhile, please comment on the approach. > > Additional testing: > - [x] `grep -R "MutexLocker " src/hotspot | grep -i null`, no hits > - [x] `grep -R "MutexLocker " src/hotspot | grep -i ?`, no hits > - [x] Linux AArch64 fastdebug, `tier1 tier2 tier3` (re-run in progress) Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into JDK-8313202-mutexlocker-nulls - Merge branch 'master' into JDK-8313202-mutexlocker-nulls - Accept one more potentially nullptr mutex - Merge branch 'master' into JDK-8313202-mutexlocker-nulls - Replace ReentrantMutexLocker with ConditionalMutexLocker - Workaround for JDK-8313210 - Fixing CodeCache analytics - Initial work ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15043/files - new: https://git.openjdk.org/jdk/pull/15043/files/9eb3e1ff..7a11505f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15043&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15043&range=03-04 Stats: 26775 lines in 1175 files changed: 13900 ins; 5080 del; 7795 mod Patch: https://git.openjdk.org/jdk/pull/15043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15043/head:pull/15043 PR: https://git.openjdk.org/jdk/pull/15043 From amitkumar at openjdk.org Thu Aug 24 08:32:02 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 24 Aug 2023 08:32:02 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v2] In-Reply-To: References: Message-ID: > [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. > > For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. > > fastdebug build tested on **s390** & **apple m1-pro**. Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: address @dholmes-ora suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14902/files - new: https://git.openjdk.org/jdk/pull/14902/files/3aac96cb..50c8b6b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14902&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14902&range=00-01 Stats: 55 lines in 14 files changed: 8 ins; 44 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14902.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14902/head:pull/14902 PR: https://git.openjdk.org/jdk/pull/14902 From shade at openjdk.org Thu Aug 24 09:01:34 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 24 Aug 2023 09:01:34 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v2] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 06:22:57 GMT, Thomas Stuefe wrote: >> Small change that reduces the number of loads generated by the C++ compiler for a narrow Klass decoding operation (`CompressedKlassPointers::decode_xxx()`. >> >> Stock: three loads (with two probably sharing a cache line) - UseCompressedClassPointers, encoding base and shift. >> >> >> 8b7b62: 48 8d 05 7f 1b c3 00 lea 0xc31b7f(%rip),%rax # 14e96e8 >> 8b7b69: 0f b6 00 movzbl (%rax),%eax >> 8b7b6c: 84 c0 test %al,%al >> 8b7b6e: 0f 84 9c 00 00 00 je 8b7c10 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> >> 8b7b74: 48 8d 15 05 62 c6 00 lea 0xc66205(%rip),%rdx # 151dd80 <_ZN23CompressedKlassPointers6_shiftE> >> 8b7b7b: 8b 7b 08 mov 0x8(%rbx),%edi >> 8b7b7e: 8b 0a mov (%rdx),%ecx >> 8b7b80: 48 8d 15 01 62 c6 00 lea 0xc66201(%rip),%rdx # 151dd88 <_ZN23CompressedKlassPointers5_baseE> >> 8b7b87: 48 d3 e7 shl %cl,%rdi >> 8b7b8a: 48 03 3a add (%rdx),%rdi >> >> >> Patched: one load loads all three. Since shift occupies the lowest 8 bits, compiled code uses 8bit register; ditto the UseCompressedOops flag. >> >> >> 8ba302: 48 8d 05 97 9c c2 00 lea 0xc29c97(%rip),%rax # 14e3fa0 <_ZN23CompressedKlassPointers6_comboE> >> 8ba309: 48 8b 08 mov (%rax),%rcx >> 8ba30c: f6 c5 01 test $0x1,%ch # use compressed klass pointers? >> 8ba30f: 0f 84 9b 00 00 00 je 8ba3b0 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> >> 8ba315: 8b 7b 08 mov 0x8(%rbx),%edi >> 8ba318: 48 d3 e7 shl %cl,%rdi # shift >> 8ba31b: 66 31 c9 xor %cx,%cx # zero out lower 16 bits of base >> 8ba31e: 48 01 cf add %rcx,%rdi # add base >> 8ba321: 8b 4f 08 mov 0x8(%rdi),%ecx >> >> --- >> >> Performance measurements: >> >> G1, doing a full GC over a heap filled with 256 mio life j.l.Object instances. >> >> I see a reduction of Full Pause times between 1.2% and 5%. I am unsure how reliable these numbers are since, despite my efforts (running tests on isolated CPUs etc.), the standard deviation was quite high at ?4%. Still, in general, numbers seemed to go down rather than up. >> >> --- >> >> Future extensions: >> >> This patch uses the fact that the encoding base is aligned to metaspace reser... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix -UseCCP case I see a few other places where `UseCompressedClassPointers` is used: `oopDesc::load_klass_raw` and `oopDesc::has_klass_gap`. Both seem to be only used from the diagnostic code, so their performance might not be relevant. Should those keep being omitted? All other uses I see are in either compiler code (where we can afford reading the flag directly) or non-perf-critical parts of runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15389#issuecomment-1691288399 From rcastanedalo at openjdk.org Thu Aug 24 09:13:30 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 24 Aug 2023 09:13:30 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) [v2] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 17:50:44 GMT, Vladimir Kozlov wrote: > Looks good. Thanks for reviewing, Vladimir! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15288#issuecomment-1691308343 From stuefe at openjdk.org Thu Aug 24 09:23:31 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 24 Aug 2023 09:23:31 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v2] In-Reply-To: References: Message-ID: <9FSZaPUjL2POnnaAyoIyv-_QzFpj2N8yApFxraHHV5g=.a6c5a232-6e07-4036-baa6-e41562636949@github.com> On Thu, 24 Aug 2023 08:58:35 GMT, Aleksey Shipilev wrote: > I see a few other places where `UseCompressedClassPointers` is used: `oopDesc::load_klass_raw` and `oopDesc::has_klass_gap`. Both seem to be only used from the diagnostic code, so their performance might not be relevant. Should those keep being omitted? > > All other uses I see are in either compiler code (where we can afford reading the flag directly) or non-perf-critical parts of runtime. It probably won't matter either way. The compiler side I may touch with later patches. For the rest, I'd like to keep the patch small and confined. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15389#issuecomment-1691324239 From rkennke at openjdk.org Thu Aug 24 11:44:12 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 24 Aug 2023 11:44:12 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v54] In-Reply-To: References: Message-ID: <3zjVHg7YYsm5GiPx5Rf3eWv-KEowpgGm807iGexVtfY=.ccb32cc1-dcc3-4a0a-8791-15efac1bd2f2@github.com> > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke has updated the pull request incrementally with three additional commits since the last revision: - Fix comments - Fix inconsistencies in argument naming C1_MacroAssembler::allocate_array() - Fix call to arrayOopDesc::header_size() in arm port ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11044/files - new: https://git.openjdk.org/jdk/pull/11044/files/ee1e921a..f04410f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=52-53 Stats: 10 lines in 8 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From rcastanedalo at openjdk.org Thu Aug 24 11:45:28 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 24 Aug 2023 11:45:28 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) [v2] In-Reply-To: References: Message-ID: On Mon, 21 Aug 2023 10:23:06 GMT, Albert Mingkun Yang wrote: > If I understand it correctly, much of the diff is to ensure that `ArrayCopyNode::make` (in `BarrierSetC2::clone`) gets the correct value for the `length` arg, calculated as `align_up(array-length * elem-size, word-size) / word-size`. > > I wonder if it's possible to pass the actual array length (#slots) as `length` and move the merge-bytes-to-words-copying optimization to a lower level, e.g. inside `conjoint_jbytes`. Ofc, `BarrierSetC2::clone_at_expansion` and its derived siblings need to be adjusted accordingly, e.g. to use the actual elem-type. > > (Preexisting: having `ArrayCopyNode` to cover both array and instance cloning hinders the readability, IMO.) Thanks for looking at this, Albert! I agree that the code could benefit from some clean-up, and postponing the merge-bytes-to-words-copying optimization to at least BarrierSetC2::clone_at_expansion() is worth exploring. However, your suggested refactoring would not be trivial, so I suggest to integrate this fix as-is and address the simplification in a separate RFE. Please let me know if you agree, and, if so, I will create a separate RFE for your suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15288#issuecomment-1691520338 From rkennke at openjdk.org Thu Aug 24 11:56:15 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 24 Aug 2023 11:56:15 GMT Subject: RFR: 8139457: Array bases are aligned at HeapWord granularity [v55] In-Reply-To: References: Message-ID: > See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details. > > Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements. > > Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16. > > Testing: > - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390) > - [x] tier1 (x86_64, x86_32, aarch64, riscv) > - [x] tier2 (x86_64, aarch64, riscv) > - [x] tier3 (x86_64, riscv) Roman Kennke 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 'upstream/master' into JDK-8139457 - Fix comments - Fix inconsistencies in argument naming C1_MacroAssembler::allocate_array() - Fix call to arrayOopDesc::header_size() in arm port - Fix wrong alignment - Move away arrayOopDesc::header_size() - Move alignment-gap-clearing into allocate_array() (aarch64) - Move header_size_in_bytes closer to length_offset_in_bytes - RISCV fixes by @RealYFang - Fix GetObjectSizeIntrinsicsTest.java to work correctly with +/-UseCCP - ... and 73 more: https://git.openjdk.org/jdk/compare/97b94cb1...f48ad53b ------------- Changes: https://git.openjdk.org/jdk/pull/11044/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11044&range=54 Stats: 622 lines in 33 files changed: 474 ins; 83 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/11044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/11044/head:pull/11044 PR: https://git.openjdk.org/jdk/pull/11044 From dchuyko at openjdk.org Thu Aug 24 13:13:49 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 24 Aug 2023 13:13:49 GMT Subject: RFR: 8309271: A way to align already compiled methods with compiler directives [v5] In-Reply-To: References: Message-ID: <6jqOQkeIlYOTnogrCBLns_mSi6RdkhsfY2YFMx6qnSY=.be25b6b3-069e-4341-a36c-4270229f0296@github.com> On Mon, 12 Jun 2023 12:00:48 GMT, Andrei Pangin wrote: >> Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - jcheck >> - Unnecessary import >> - force_update->refresh >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Use only top directive for add/remove; better mutex rank definition; texts >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Safe handling of non-java methods >> - Merge branch 'openjdk:master' into compiler-directives-force-update >> - Renamed -d to -r, clear not compilable flags when directives change, original test restored, new test added >> - ... and 13 more: https://git.openjdk.org/jdk/compare/de0e46c2...e361b4fc > > src/hotspot/share/runtime/mutexLocker.cpp line 274: > >> 272: MUTEX_DEFN(MethodCompileQueue_lock , PaddedMonitor, safepoint); >> 273: MUTEX_DEFN(CompileStatistics_lock , PaddedMutex , safepoint); >> 274: MUTEX_DEFN(DirectivesStack_lock , PaddedMutex , nosafepoint-3); > > A comment explaining the rank change would be helpful. Changed the definition to use another macro and relative ranking. > src/hotspot/share/services/diagnosticCommand.cpp line 890: > >> 888: DCmdWithParser(output, heap), >> 889: _filename("filename", "Name of the directives file", "STRING", true), >> 890: _force_deopt("-d", "Force deoptimization of affected methods.", "BOOLEAN", false, "false") { > > I agree with Paul a generic alternative like `refresh` would be better. Changed the flag, description and names to 'refresh', 'r'. > src/hotspot/share/services/diagnosticCommand.cpp line 946: > >> 944: DeoptimizationScope deopt_scope; >> 945: CodeCache::mark_for_deoptimization_directives_matches(&deopt_scope); >> 946: DirectivesStack::pop(1); > > Why deoptimizing methods from the whole stack if we change only the topmost list? Agree, now only top directive is involved for add/remove. > src/hotspot/share/services/diagnosticCommand.hpp line 734: > >> 732: }; >> 733: >> 734: class CompilerDirectivesReplaceDCmd : public DCmdWithParser { > > Introducing a new command probably isn't worth it, given the same functionality can be achieved with existing commands. Furthermore, it's not obvious whether "replace" should mean remove+add or clear+add. 'replace' is 'clear'+'add' (we don't have indexes and don't mention top element). Additional command is made to avoid double refreshing when '-r' is provided. It is more robust as we don't know when methods affected 'clear' are finally compiled. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1304026590 PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1304088822 PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1304028173 PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1302901891 From dchuyko at openjdk.org Thu Aug 24 13:13:46 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 24 Aug 2023 13:13:46 GMT Subject: RFR: 8309271: A way to align already compiled methods with compiler directives [v5] In-Reply-To: References: Message-ID: > Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack. > > A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers. > > It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods). > > Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter. > > A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them. > > In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ... Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - jcheck - Unnecessary import - force_update->refresh - Merge branch 'openjdk:master' into compiler-directives-force-update - Use only top directive for add/remove; better mutex rank definition; texts - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Safe handling of non-java methods - Merge branch 'openjdk:master' into compiler-directives-force-update - Renamed -d to -r, clear not compilable flags when directives change, original test restored, new test added - ... and 13 more: https://git.openjdk.org/jdk/compare/de0e46c2...e361b4fc ------------- Changes: https://git.openjdk.org/jdk/pull/14111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=04 Stats: 372 lines in 15 files changed: 339 ins; 3 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/14111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111 PR: https://git.openjdk.org/jdk/pull/14111 From shade at openjdk.org Thu Aug 24 14:08:36 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 24 Aug 2023 14:08:36 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v7] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 10:56:52 GMT, Boris Ulasevich wrote: >> This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 >> >> The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. >> >> InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: >> >> >> Cortex-A53 (Pi 3 Model B Rev 1.2) >> >> test1stInt2Types 37.5 37.358 0.38 >> test1stInt3Types 160.166 148.04 8.19 >> test1stInt5Types 158.131 147.955 6.88 >> test2ndInt2Types 52.634 53.291 -1.23 >> test2ndInt3Types 201.39 181.603 10.90 >> test2ndInt5Types 195.722 176.707 10.76 >> testIfaceCall 157.453 140.498 12.07 >> testIfaceExtCall 175.46 154.351 13.68 >> testMonomorphic 32.052 32.039 0.04 >> AVG: 6.85 >> >> Cortex-A72 (Pi 4 Model B Rev 1.2) >> >> test1stInt2Types 27.4796 27.4738 0.02 >> test1stInt3Types 66.0085 64.9374 1.65 >> test1stInt5Types 67.9812 66.2316 2.64 >> test2ndInt2Types 32.0581 32.062 -0.01 >> test2ndInt3Types 68.2715 65.6643 3.97 >> test2ndInt5Types 68.1012 65.8024 3.49 >> testIfaceCall 64.0684 64.1811 -0.18 >> testIfaceExtCall 91.6226 81.5867 12.30 >> testMonomorphic 26.7161 26.7142 0.01 >> AVG: 2.66 >> >> Neoverse N1 (m6g.metal) >> >> test1stInt2Types 2.9104 2.9086 0.06 >> test1stInt3Types 10.9642 10.2909 6.54 >> test1stInt5Types 10.9607 10.2856 6.56 >> test2ndInt2Types 3.3410 3.3478 -0.20 >> test2ndInt3Types 12.3291 11.3089 9.02 >> test2ndInt5Types 12.328 11.2704 9.38 >> testIfaceCall 11.0598 10.3657 6.70 >> testIfaceExtCall 13.0692 11.2826 15.84 >> testMonomorphic 2.2354 2.2341 0.06 >> AVG: 6.00 >> >> Neoverse V1 (c7g.2xlarge) >> >> test1stInt2Types 2.2317 2.2320 -0.01 >> test1stInt3Types 6.6884 6.1911 8.03 >> test1stInt5Types 6.7334 6.2193 8.27 >> test2ndInt2Types 2.4002 2.4013 -0.04 >> test2ndInt3Types 7.9603 7.0372 13.12 >> test2ndInt5Types 7.9532 7.0474 12.85 >> testIfaceCall 6.7028 6.3272 5.94 >> testIfaceExtCall 8.3253 6.941... > > Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - rework loop_scan_resolved_entry cycle as proposed > - 8307352: AARCH64: Improve itable_stub I find this version oddly deviating from [x86_64 improvement](https://github.com/openjdk/jdk/commit/8cdd95e8a2a7814ab7983fb3f41e6fa5793d410f) done before it, which does not simplify the review. Anyway, nits: src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1230: > 1228: // itableOffsetEntry[] itable = recv_klass + Klass::vtable_start_offset() + recv_klass->_vtable_len; > 1229: // temp_itbl_klass = itable[0]._interface; > 1230: ldr(temp_itbl_klass, Address(recv_klass, scan_temp, Address::lsl(3))); What is `Address::lsl(3)` here? From x86_64, it seems to be related to `ioffset`? If so, this magic `3` should derive from it. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1233: > 1231: mov(holder_offset, zr); > 1232: // scan_temp = &(itable[0]._interface) > 1233: lea(scan_temp, Address(recv_klass, scan_temp, Address::lsl(3))); Same here: `Address::lsl(3)`. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1296: > 1294: bind(L_holder_found); > 1295: ldrw(method_result, Address(scan_temp, ooffset - ioffset)); > 1296: add(recv_klass, recv_klass, (itable_index << 3) + in_bytes(itableMethodEntry::method_offset()) - vtable_start_offset - ioffset); Same magic number here: `itable_index << 3`. ------------- PR Review: https://git.openjdk.org/jdk/pull/13792#pullrequestreview-1593666883 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1304372456 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1304374895 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1304376044 From azafari at openjdk.org Thu Aug 24 14:17:40 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 24 Aug 2023 14:17:40 GMT Subject: RFR: 8314502: GrowableArray: Make find with comparator take template Message-ID: The `find` method now is ```C++ template int find(T* token, bool f(T*, E)) const { ... Any other functions which use this are also changed. Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. ------------- Commit messages: - 8314502: GrowableArray: Make find with comparator take template Changes: https://git.openjdk.org/jdk/pull/15418/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15418&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314502 Stats: 10 lines in 4 files changed: 1 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15418.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15418/head:pull/15418 PR: https://git.openjdk.org/jdk/pull/15418 From dfuchs at openjdk.org Thu Aug 24 14:44:33 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 24 Aug 2023 14:44:33 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v4] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 20:27:38 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, >>... > > Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: > > - fix whitespace > - move retainClassRef to ClassFrameInfo as a bit set in the flags field > - fixup the factory methods src/java.base/share/classes/java/lang/ClassFrameInfo.java line 32: > 30: class ClassFrameInfo implements StackFrame { > 31: protected Object classOrMemberName; // Class or ResolvedMemberName initialized by VM > 32: protected int flags; I see only one place where flags is written to and that's at line 35 below. I guess the reason it's not final is that it can be mutated by the VM. Maybe that would deserve a comment here: ```suggestion protected int flags; // flags can be mutated by the VM to indicate hidden frame src/java.base/share/classes/java/lang/StackStreamFactory.java line 1083: > 1081: private static boolean filterStackWalkImpl(Class c) { > 1082: return stackWalkImplClasses.contains(c) || > 1083: c.getPackageName().equals("java.util.stream"); There is a small semantic difference here and in the change below compared to the original code: the original code would have also included sub-packages, where the new code will not. Since neither `java.util.stream` nor `java.lang.invoke` have sub-package I guess it's of no concern for now. src/java.base/share/classes/java/lang/StackStreamFactory.java line 1096: > 1094: c == Constructor.class || > 1095: MethodAccessor.class.isAssignableFrom(c) || > 1096: ConstructorAccessor.class.isAssignableFrom(c); I guess LambdaForm have the hidden flag on, which is why there's no need to include them here now? src/java.base/share/classes/java/lang/StackWalker.java line 333: > 331: * {@linkplain StackFrame#getMethodType() method type}, > 332: * {@linkplain StackFrame#getLineNumber() line number} and > 333: * {@linkplain StackFrame#getByteCodeIndex() bytecode index}. Maybe you should include `getFileName` (and possibly `isNativeMethod`) here? src/java.base/share/classes/java/lang/StackWalker.java line 338: > 336: } > 337: > 338: enum ExtendedOption { Should `ExtendedOption` now be renamed into `ExtendedKind`? test/jdk/java/lang/StackWalker/SanityTest.java line 120: > 118: sw.forEach(StackWalker.StackFrame::isNativeMethod)); > 119: assertThrows(UnsupportedOperationException.class, () -> > 120: sw.forEach(StackWalker.StackFrame::toStackTraceElement)); Should we check that the exception is thrown by each frame? This code will hit the exception at the first frame and not check the others. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304261309 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304358574 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304362430 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304380080 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304424800 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304440971 From mchung at openjdk.org Thu Aug 24 16:39:33 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 24 Aug 2023 16:39:33 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v4] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 13:47:42 GMT, Daniel Fuchs wrote: >> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: >> >> - fix whitespace >> - move retainClassRef to ClassFrameInfo as a bit set in the flags field >> - fixup the factory methods > > src/java.base/share/classes/java/lang/StackStreamFactory.java line 1083: > >> 1081: private static boolean filterStackWalkImpl(Class c) { >> 1082: return stackWalkImplClasses.contains(c) || >> 1083: c.getPackageName().equals("java.util.stream"); > > There is a small semantic difference here and in the change below compared to the original code: the original code would have also included sub-packages, where the new code will not. Since neither `java.util.stream` nor `java.lang.invoke` have sub-package I guess it's of no concern for now. Right, that's the reason for this change. Subpackages if added in the future may not need to be filtered as it may not the implementation of streams and method handles. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304599669 From jsjolen at openjdk.org Thu Aug 24 16:42:29 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 24 Aug 2023 16:42:29 GMT Subject: RFR: 8314502: GrowableArray: Make find with comparator take template In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 14:09:46 GMT, Afshin Zafari wrote: > The `find` method now is > ```C++ > template > int find(T* token, bool f(T*, E)) const { > ... > > Any other functions which use this are also changed. > Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. Looks good to me, thank you. A couple of style issues that needs to be fixed, some pre-existing. src/hotspot/share/prims/jvmtiImpl.cpp line 126: > 124: assert(e2 != nullptr, "e2 != nullptr"); > 125: > 126: return v->equals(e2); Please rename the `v` parameter to `e1` src/hotspot/share/prims/jvmtiImpl.hpp line 91: > 89: void (*_listener_fun)(void *, address*); > 90: > 91: static bool equals(GrowableElement *, GrowableElement *); Remove spacing between `GrowableElement` and `*` ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15418#pullrequestreview-1594030652 PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1304600705 PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1304602700 From jsjolen at openjdk.org Thu Aug 24 16:42:31 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 24 Aug 2023 16:42:31 GMT Subject: RFR: 8314502: GrowableArray: Make find with comparator take template In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 16:37:44 GMT, Johan Sj?len wrote: >> The `find` method now is >> ```C++ >> template >> int find(T* token, bool f(T*, E)) const { >> ... >> >> Any other functions which use this are also changed. >> Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. > > src/hotspot/share/prims/jvmtiImpl.cpp line 126: > >> 124: assert(e2 != nullptr, "e2 != nullptr"); >> 125: >> 126: return v->equals(e2); > > Please rename the `v` parameter to `e1` And since you're here: Could you change the code style so that it's `GrowableElement* e2` and not `GrowableElement *e2`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1304601987 From mchung at openjdk.org Thu Aug 24 16:45:28 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 24 Aug 2023 16:45:28 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v4] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 13:49:29 GMT, Daniel Fuchs wrote: >> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: >> >> - fix whitespace >> - move retainClassRef to ClassFrameInfo as a bit set in the flags field >> - fixup the factory methods > > src/java.base/share/classes/java/lang/StackStreamFactory.java line 1096: > >> 1094: c == Constructor.class || >> 1095: MethodAccessor.class.isAssignableFrom(c) || >> 1096: ConstructorAccessor.class.isAssignableFrom(c); > > I guess LambdaForm have the hidden flag on, which is why there's no need to include them here now? `LambdaForm` are method handle frames which are filtered by `isMethodHandleFrame` > test/jdk/java/lang/StackWalker/SanityTest.java line 120: > >> 118: sw.forEach(StackWalker.StackFrame::isNativeMethod)); >> 119: assertThrows(UnsupportedOperationException.class, () -> >> 120: sw.forEach(StackWalker.StackFrame::toStackTraceElement)); > > Should we check that the exception is thrown by each frame? This code will hit the exception at the first frame and not check the others. I think not necessary since the walker returns the `ClassFrameInfo` for all frames. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304603999 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304606664 From pchilanomate at openjdk.org Thu Aug 24 18:08:29 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 24 Aug 2023 18:08:29 GMT Subject: RFR: 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 15:06:16 GMT, Ron Pressler wrote: >> Thanks for working on this. >> >> I'm not sure if this is useful, but I just did a quick test with the patch and I see some interesting performance changes. Context switches in the test go from ~160k to ~1m, and total time increases from 4 seconds to 4.8 seconds. However I do see lower CPU utilization. >> >> >> import java.util.concurrent.*; >> >> public class Main { >> public static void main(String[] args) throws Exception { >> for (int i = 0; i < 100; i++) { >> ExecutorService = Executors.newVirtualThreadPerTaskExecutor(); >> long start = System.currentTimeMillis(); >> for (int j = 0; j < 100_000; j++) e.submit(Main::task); >> e.shutdown(); e.awaitTermination(100, TimeUnit.MINUTES); >> long dur = System.currentTimeMillis() - start; >> System.out.println(dur + "ms"); >> } >> } >> >> static void task() { } >> } >> >> >> >> perf stat java -XX:+UnlockExperimentalVMOptions -XX:-DoJVMTIVirtualThreadTransitions Main.java >> >> >> Before patch >> >> 45,069.79 msec task-clock # 11.214 CPUs utilized >> 159,503 context-switches # 0.004 M/sec >> 16,250 cpu-migrations # 0.361 K/sec >> 182,820 page-faults # 0.004 M/sec >> >> 4.019077281 seconds time elapsed >> >> 44.004389000 seconds user >> 1.844216000 seconds sys >> >> >> >> After patch >> >> 39,830.77 msec task-clock # 8.217 CPUs utilized <--- reduced >> 1,094,192 context-switches # 0.027 M/sec <--- increased >> 91,803 cpu-migrations # 0.002 M/sec >> 185,841 page-faults # 0.005 M/sec >> >> 4.847430580 seconds time elapsed <--- increased >> >> 34.643548000 seconds user >> 10.396489000 seconds sys >> >> >> I appreciate this test may be total unrealistic and flawed, and I haven't had time to check where the context-switches are coming from, but figured I'd share the early results just in case. > > @olivergillespie That happens because the scheduler is starved. This is a known phenomenon that usually appears in artificial benchmarks with a lot of work but low parallelism. We've considered trying to fix that, but a fix would probably harm real workloads. If you set the parallelism to a lower number you will see a lower latency. Thanks for the reviews @pron and @theRealAph, and @olivergillespie for reporting this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15403#issuecomment-1692181523 From svkamath at openjdk.org Thu Aug 24 18:10:54 2023 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 24 Aug 2023 18:10:54 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions Message-ID: Hi All, I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup |-------------|------------|---------------|------------------|-----------| |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 ? | ? | ? | ? | ? full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 ? | ? | ? | ? | ? full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 ? | ? | ? | ? | ? full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 full.AESGCMBench.decryptMultiPart | 65536 | 42649.816 | 47591.587 |1.11 full.AESGCMBench.encryptMultiPart | 65536 | 86025.621 | 112305.674 | 1.30 small.AESGCMBench.decryptMultiPart | 65536 | 42542.426 | 47899.088 | 1.12 small.AESGCMBench.encryptMultiPart | 65536 | 85522.057 | 111759.309 |1.30 ? | ? | ? | ? | ? full.AESGCMBench.decrypt | 1048576 | 5490.691 | 7335.672 | 1.33 full.AESGCMBench.encrypt | 1048576 | 5611.847 | 7338.246 | 1.30 small.AESGCMBench.decrypt | 1048576 | 5506.263 | 7247.359 | 1.31 small.AESGCMBench.encrypt | 1048576 | 5612.709 | 7331.576 | 1.30 full.AESGCMBench.decryptMultiPart | 1048576 | 2992.516 | 3405.349 | 1.13 full.AESGCMBench.encryptMultiPart | 1048576 | 5585.353 | 7341.056 | 1.31 small.AESGCMBench.decryptMultiPart | 1048576 | 2971.281 | 3390.593 | 1.14 small.AESGCMBench.encryptMultiPart | 1048576 | 5596.038 | 7322.126 | 1.30 Kindly review and provide feedback. Thanks, Smita ------------- Commit messages: - JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions Changes: https://git.openjdk.org/jdk/pull/15410/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15410&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314901 Stats: 1154 lines in 13 files changed: 1133 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/15410.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15410/head:pull/15410 PR: https://git.openjdk.org/jdk/pull/15410 From pchilanomate at openjdk.org Thu Aug 24 18:11:42 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 24 Aug 2023 18:11:42 GMT Subject: Integrated: 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 14:25:12 GMT, Patricio Chilano Mateo wrote: > Please review the following fix. The check in SharedRuntime::reresolve_call_site() "caller.is_compiled_frame() && !caller.is_deoptimized_frame()" fails when caller is Continuation.enterSpecial because it is a native method. This means that if the static callsite to Continuation.enter was patched to point to an nmethod and then the nmethod was marked non-entrant we will always call SharedRuntime::handle_wrong_method() thereafter when resolving Continuation.enter because the callsite will never be reset back to the clean state. Thanks to @kuksenko for all the performance analysis while debugging this. > I tested the patch by running the test included in the original report (loom-dev mailing list) and verifying the issue is fixed. I also run mach5 tiers1-3 for sanity testing and will run all the upper tiers too. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 8e4240c3 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/8e4240c3167ff6c803f3391f70ef9cfa7f408085 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter Reviewed-by: rpressler, aph ------------- PR: https://git.openjdk.org/jdk/pull/15403 From mchung at openjdk.org Thu Aug 24 18:44:14 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 24 Aug 2023 18:44:14 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v5] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker > collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used > instead and such stack walker will save the overhead (1) to extract the method information > and (2) the memory used for the stack walking. In addition, this can also fix > > - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: > > > StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(interestingClasses::contains) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, > it only needs a small change in calling `getInstance` method to request class only info... Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: review feedback and javadoc clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/30984253..a3a44575 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=03-04 Stats: 52 lines in 2 files changed: 11 ins; 7 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From ayang at openjdk.org Thu Aug 24 20:42:11 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 24 Aug 2023 20:42:11 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) [v2] In-Reply-To: References: Message-ID: On Tue, 22 Aug 2023 07:53:03 GMT, Roberto Casta?eda Lozano wrote: >> This changeset ensures that the array copy stub underlying the intrinsic implementation of `Object.clone` only copies its (double-word aligned) payload, excluding the remaining object alignment padding words, when a non-default `ObjectAlignmentInBytes` value is used. This prevents the specialized ZGC stubs for `Object[]` array copy from processing undefined object alignment padding words as valid object pointers. For further details about the specific failure, see [initial analysis](https://bugs.openjdk.org/browse/JDK-8312749?focusedCommentId=14600658&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14600658) by Erik ?sterlund and Stefan Karlsson and comments in the regression test included in this changeset. >> >> As a side-benefit, the changeset simplifies the array size computation logic in `GraphKit::new_array()` by decoupling computation of header size and alignment padding size. >> >> #### Testing >> >> ##### Functionality >> >> - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) >> - tier4-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; ZGC-specific tests only) >> - tier6-9 (linux-x64; ZGC-specific tests only) >> - tier1-3, and a few custom examples, applying [JDK-8139457](https://github.com/openjdk/jdk/pull/11044) (under review) on top of this changeset >> >> ##### Performance >> >> Tested performance on the following set of OpenJDK micro-benchmarks, on linux-x64 (for both G1 and ZGC, using different ObjectAlignmentInBytes values): >> >> - `openjdk.bench.java.lang.ArrayClone.byteClone` >> - `openjdk.bench.java.lang.ArrayClone.intClone` >> - `openjdk.bench.java.lang.ArrayFiddle.simple_clone` >> - `openjdk.bench.java.lang.Clone.cloneLarge` >> - `openjdk.bench.java.lang.Clone.cloneThreeDifferent` >> >> No significant regression was observed. > > Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra whitespace > I suggest to integrate this fix as-is and address the simplification in a separate RFE Sounds reasonable. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15288#pullrequestreview-1594421310 From mchung at openjdk.org Thu Aug 24 22:07:12 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 24 Aug 2023 22:07:12 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v5] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 18:44:14 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, >>... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback and javadoc clean up > StackWalkers would be configured along two different axes (Kind and Options). This is intentional. `Kind` is not the best name but it describes what information a stack walker collects from each stack frame. > It changes the mental model, in that all StackWalkers would now be divided into two Kinds. I feel like this bleeds the implementation into the API a bit. Although this RFE is motivated by an optimized way to walk the stack, each method has a declaring class. In the current implementation, it has an internal way to collect the live locals and operands on the stack (`LOCALS_AND_OPERANDS`). That fits into the third type to be collected from each frame. If that were supported, it would belong to the new enum type. > The existing Option enum already provides a way to configure which frames are walked, and what information to include in those frames. I think adding a new Option value fits better. > > It's true that compatibility dictates that the default behavior be to include method info, so the new option must omit method info. If the NO_METHOD_INFO is disliked, perhaps a better name can be found - SKIP_METHOD_INFO or OMIT_METHOD_INFO? In fact it's not so much constrained by the default behavior. I wasn't completely happy with adding `NO_METHOD_INFO` to the options but could live with it. When I reconsidered, I like separating this from `Option` as it specifies what information to be collected from each frame whereas `Option` controls everything else such as what frames to be filtered for better categorization. I updated the javadoc. Maybe it helps? https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1692474762 From sviswanathan at openjdk.org Thu Aug 24 22:11:10 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 24 Aug 2023 22:11:10 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v3] In-Reply-To: References: Message-ID: <8khU4xdNeQ0OEVh75BXAJa3FADY8BRybm8epd72IN2U=.d2b56713-4d74-472e-9d70-7f44e24ea37a@github.com> On Wed, 23 Aug 2023 23:17:00 GMT, Scott Gibbons wrote: >> Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. >> >> Tested tier1. > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > mxcsr fix; address review comments The changes look good to me now. Could you please also get the performance of DremFrem jmh micro with/without your PR for both UseAVX=2 and UseAVX=3? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15210#issuecomment-1692478989 From bchristi at openjdk.org Thu Aug 24 22:24:13 2023 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 24 Aug 2023 22:24:13 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v5] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 18:44:14 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, >>... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback and javadoc clean up src/java.base/share/classes/java/lang/StackWalker.java line 47: > 45: * from the stack frames by default. If the method information is not needed, > 46: * a {@code StackWalker} collecting {@linkplain Kind#CLASS_INFO class only information} > 47: * can be used instead via the {@link #getInstance(Kind, Option...)} method. The description of `Kind` should come after the basics of what StackWalker does: *

The {@link StackWalker#walk walk} method opens a sequential stream * of {@link StackFrame StackFrame}s for the current thread and then applies * the given function to walk the {@code StackFrame} stream. It should be clarified that `METHOD_INFO` returns method information _as well as_ class information. Overall I would still prefer adding an `Option.OMIT_METHOD_INFO` over a new `Kind` enum. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304929416 From ecki at zusammenkunft.net Thu Aug 24 23:23:46 2023 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 24 Aug 2023 23:23:46 +0000 Subject: Older unused Intel platform check functions Message-ID: Hello, I was checking out to see a hint of what?s the minimum microarchitecture is, which makes sense to require for OpenJDK. I was not very successful and it probably depends on compiler toolchain and distribution. Does somebody have some insights? Having said that I noticed the following: The 20 years old netburst architecture has a test function but it?s not used to make feature decisions in the JDK, it is just used to construct a SSE feature string, where it can be safely removed (the feature flags are reported anyway, worst case use cpu_family_description instead?) VM_Version::is_netburst If you want to keep it, it?s probably more consistent to rename it to is_intel_netburst VM_Version::is_default_intel_cascadelake VM_Version::is_intel_cascadelake Those two seem not to be used anywhere, can probably be removed as well. https://github.com/openjdk/jdk/blob/2624324ac216aadc938a870075f6fad287fedf05/src/hotspot/cpu/x86/vm_version_x86.hpp#L716 Greetings Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchristi at openjdk.org Thu Aug 24 23:26:11 2023 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 24 Aug 2023 23:26:11 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v5] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 22:03:53 GMT, Mandy Chung wrote: > I like separating this from `Option` as it specifies what information to be collected from each frame whereas `Option` controls everything else such as what frames to be filtered In my mind, `Option` _already_ can control what information is to be collected: `RETAIN_CLASS_REFERENCE` as well as what frames to filter: `SHOW_HIDDEN_FRAMES` `SHOW_REFLECT_FRAMES` ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1692537575 From david.holmes at oracle.com Fri Aug 25 01:57:09 2023 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Aug 2023 11:57:09 +1000 Subject: Older unused Intel platform check functions In-Reply-To: References: Message-ID: <608cef6a-352e-44ad-82fe-812073bce2fa@oracle.com> Hi Bernd, On 25/08/2023 9:23 am, Bernd Eckenfels wrote: > Hello, > > I was checking out to see a hint of what?s the minimum microarchitecture > is, which makes sense to require for OpenJDK. I was not very successful > and it probably depends on compiler toolchain and distribution. Does > somebody have some insights? > > Having said that I noticed the following: > > The 20 years old netburst architecture has a test function but it?s not > used to make feature decisions in the JDK, it is just used to construct > a SSE feature string, where it can be safely removed (the feature flags > are reported anyway, worst case use cpu_family_description instead?) > > VM_Version::is_netburst > > If you want to keep it, it?s probably more consistent to rename it to > is_intel_netburst Yes netburst seem unused now. > > VM_Version::is_default_intel_cascadelake > VM_Version::is_intel_cascadelake > > Those two seem not to be used anywhere, can probably be removed as well. Yes they are used: ./cpu/x86/x86.ad ./cpu/x86/x86_64.ad Cheers, David ---- > https://github.com/openjdk/jdk/blob/2624324ac216aadc938a870075f6fad287fedf05/src/hotspot/cpu/x86/vm_version_x86.hpp#L716 > > Greetings > Bernd > > > -- > http://bernd.eckenfels.net From dholmes at openjdk.org Fri Aug 25 02:23:20 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 25 Aug 2023 02:23:20 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v2] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 08:32:02 GMT, Amit Kumar wrote: >> [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. >> >> For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. >> >> fastdebug build tested on **s390** & **apple m1-pro**. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > address @dholmes-ora suggestions A couple of minor nits to fix but otherwise looks good. Thanks. src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp line 317: > 315: } > 316: > 317: Nit: please just restore these files that only have a blank line removed. It will shrink the size of the PR for other reviewers. Thanks. src/hotspot/share/runtime/frame.hpp line 484: > 482: > 483: // Additional interface for interpreter frames: > 484: static int interpreter_frame_monitor_size_in_bytes(); Please move this, without comment, to after `interpreter_frame_monitor_size` (L372) ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14902#pullrequestreview-1594711846 PR Review Comment: https://git.openjdk.org/jdk/pull/14902#discussion_r1305048917 PR Review Comment: https://git.openjdk.org/jdk/pull/14902#discussion_r1305055534 From dholmes at openjdk.org Fri Aug 25 02:44:16 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 25 Aug 2023 02:44:16 GMT Subject: RFR: 8314502: GrowableArray: Make find with comparator take template In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 14:09:46 GMT, Afshin Zafari wrote: > The `find` method now is > ```C++ > template > int find(T* token, bool f(T*, E)) const { > ... > > Any other functions which use this are also changed. > Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. src/hotspot/share/utilities/growableArray.hpp line 213: > 211: > 212: template > 213: int find(T* token, bool f(T*, E)) const { Pardon my ignorance here, but what is the type relationship between T and E? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1305066166 From amitkumar at openjdk.org Fri Aug 25 03:49:35 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 25 Aug 2023 03:49:35 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v3] In-Reply-To: References: Message-ID: > [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. > > For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. > > fastdebug build tested on **s390** & **apple m1-pro**. Amit Kumar has updated the pull request incrementally with two additional commits since the last revision: - remove extra line - addition nits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14902/files - new: https://git.openjdk.org/jdk/pull/14902/files/50c8b6b0..25c41590 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14902&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14902&range=01-02 Stats: 8 lines in 5 files changed: 5 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14902.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14902/head:pull/14902 PR: https://git.openjdk.org/jdk/pull/14902 From amitkumar at openjdk.org Fri Aug 25 03:49:35 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 25 Aug 2023 03:49:35 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v2] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 02:20:47 GMT, David Holmes wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> address @dholmes-ora suggestions > > A couple of minor nits to fix but otherwise looks good. > > Thanks. @dholmes-ora would you please ping someone for 2nd review. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/14902#issuecomment-1692712525 From amitkumar at openjdk.org Fri Aug 25 03:49:35 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 25 Aug 2023 03:49:35 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v3] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 02:10:55 GMT, David Holmes wrote: >> Amit Kumar has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove extra line >> - addition nits > > src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp line 317: > >> 315: } >> 316: >> 317: inline int frame::interpreter_frame_monitor_size_in_bytes() { > > Nit: please just restore these files that only have a blank line removed. It will shrink the size of the PR for other reviewers. Thanks. Fixed, Thanks for review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14902#discussion_r1305096729 From stefank at openjdk.org Fri Aug 25 05:10:12 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 25 Aug 2023 05:10:12 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v3] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 03:49:35 GMT, Amit Kumar wrote: >> [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. >> >> For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. >> >> fastdebug build tested on **s390** & **apple m1-pro**. > > Amit Kumar has updated the pull request incrementally with two additional commits since the last revision: > > - remove extra line > - addition nits Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14902#pullrequestreview-1594860889 From bulasevich at openjdk.org Fri Aug 25 05:35:49 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 25 Aug 2023 05:35:49 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: > This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 > > The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. > > InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: > > > Cortex-A53 (Pi 3 Model B Rev 1.2) > > test1stInt2Types 37.5 37.358 0.38 > test1stInt3Types 160.166 148.04 8.19 > test1stInt5Types 158.131 147.955 6.88 > test2ndInt2Types 52.634 53.291 -1.23 > test2ndInt3Types 201.39 181.603 10.90 > test2ndInt5Types 195.722 176.707 10.76 > testIfaceCall 157.453 140.498 12.07 > testIfaceExtCall 175.46 154.351 13.68 > testMonomorphic 32.052 32.039 0.04 > AVG: 6.85 > > Cortex-A72 (Pi 4 Model B Rev 1.2) > > test1stInt2Types 27.4796 27.4738 0.02 > test1stInt3Types 66.0085 64.9374 1.65 > test1stInt5Types 67.9812 66.2316 2.64 > test2ndInt2Types 32.0581 32.062 -0.01 > test2ndInt3Types 68.2715 65.6643 3.97 > test2ndInt5Types 68.1012 65.8024 3.49 > testIfaceCall 64.0684 64.1811 -0.18 > testIfaceExtCall 91.6226 81.5867 12.30 > testMonomorphic 26.7161 26.7142 0.01 > AVG: 2.66 > > Neoverse N1 (m6g.metal) > > test1stInt2Types 2.9104 2.9086 0.06 > test1stInt3Types 10.9642 10.2909 6.54 > test1stInt5Types 10.9607 10.2856 6.56 > test2ndInt2Types 3.3410 3.3478 -0.20 > test2ndInt3Types 12.3291 11.3089 9.02 > test2ndInt5Types 12.328 11.2704 9.38 > testIfaceCall 11.0598 10.3657 6.70 > testIfaceExtCall 13.0692 11.2826 15.84 > testMonomorphic 2.2354 2.2341 0.06 > AVG: 6.00 > > Neoverse V1 (c7g.2xlarge) > > test1stInt2Types 2.2317 2.2320 -0.01 > test1stInt3Types 6.6884 6.1911 8.03 > test1stInt5Types 6.7334 6.2193 8.27 > test2ndInt2Types 2.4002 2.4013 -0.04 > test2ndInt3Types 7.9603 7.0372 13.12 > test2ndInt5Types 7.9532 7.0474 12.85 > testIfaceCall 6.7028 6.3272 5.94 > testIfaceExtCall 8.3253 6.9416 19.93 > testMonomorphic 1.2446 1.2544 -0.79 > AVG: 7.48 > > > Testing... Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: Comments applied: get rid of temp_reg3; replace the magic constants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13792/files - new: https://git.openjdk.org/jdk/pull/13792/files/54be64eb..dd0051f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=06-07 Stats: 13 lines in 3 files changed: 3 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13792/head:pull/13792 PR: https://git.openjdk.org/jdk/pull/13792 From bulasevich at openjdk.org Fri Aug 25 05:40:12 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 25 Aug 2023 05:40:12 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v2] In-Reply-To: References: <6bcJmpd_g-Qq9sIr6YtdL7DMiXKxHXeeCYXv2Jm_WO8=.703eba8b-1dc7-4340-8405-ecabfefa4754@github.com> Message-ID: On Wed, 23 Aug 2023 19:15:08 GMT, Volker Simonis wrote: > I.e. make resolved_klass_reg different from method_result such that method_result can be reused as holder_offset because the two don't overlap I see now. This is right, thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13792#issuecomment-1692788443 From bulasevich at openjdk.org Fri Aug 25 05:40:16 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Fri, 25 Aug 2023 05:40:16 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v7] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 13:54:16 GMT, Aleksey Shipilev wrote: >> Boris Ulasevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - rework loop_scan_resolved_entry cycle as proposed >> - 8307352: AARCH64: Improve itable_stub > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1230: > >> 1228: // itableOffsetEntry[] itable = recv_klass + Klass::vtable_start_offset() + recv_klass->_vtable_len; >> 1229: // temp_itbl_klass = itable[0]._interface; >> 1230: ldr(temp_itbl_klass, Address(recv_klass, scan_temp, Address::lsl(3))); > > What is `Address::lsl(3)` here? From x86_64, it seems to be related to `ioffset`? If so, this magic `3` should derive from it. This magic actually comes from the original MacroAssembler::lookup_interface_method code. Let me use exact_log2(vtableEntry::size_in_bytes()) value here to show that it is related to vtable entry size: ldrw(scan_temp, Address(recv_klass, Klass::vtable_length_offset())); add(recv_klass, recv_klass, vtable_start_offset + ioffset); // itableOffsetEntry[] itable = recv_klass + Klass::vtable_start_offset() + sizeof(vtableEntry) * recv_klass->_vtable_len; // temp_itbl_klass = itable[0]._interface; ldr(temp_itbl_klass, Address(recv_klass, scan_temp, Address::lsl(exact_log2(vtableEntry::size_in_bytes())))); > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1233: > >> 1231: mov(holder_offset, zr); >> 1232: // scan_temp = &(itable[0]._interface) >> 1233: lea(scan_temp, Address(recv_klass, scan_temp, Address::lsl(3))); > > Same here: `Address::lsl(3)`. OK > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1296: > >> 1294: bind(L_holder_found); >> 1295: ldrw(method_result, Address(scan_temp, ooffset - ioffset)); >> 1296: add(recv_klass, recv_klass, (itable_index << 3) + in_bytes(itableMethodEntry::method_offset()) - vtable_start_offset - ioffset); > > Same magic number here: `itable_index << 3`. Let it be (itable_index << LogBytesPerWord) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1305159994 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1305160070 PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1305160570 From dholmes at openjdk.org Fri Aug 25 06:09:22 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 25 Aug 2023 06:09:22 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v2] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 03:44:50 GMT, Amit Kumar wrote: >> A couple of minor nits to fix but otherwise looks good. >> >> Thanks. > > @dholmes-ora would you please ping someone for 2nd review. > > Thanks @offamitkumar please re-sync your branch with master and push to this PR - hopefully that will fix the GHA failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14902#issuecomment-1692815271 From amitkumar at openjdk.org Fri Aug 25 06:27:24 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 25 Aug 2023 06:27:24 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v4] In-Reply-To: References: Message-ID: > [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. > > For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. > > fastdebug build tested on **s390** & **apple m1-pro**. Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - remove extra line - addition nits - address @dholmes-ora suggestions - updates header year - risc-v - arm - x86 - aarch - ppc - s390 ------------- Changes: https://git.openjdk.org/jdk/pull/14902/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14902&range=03 Stats: 58 lines in 21 files changed: 6 ins; 21 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/14902.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14902/head:pull/14902 PR: https://git.openjdk.org/jdk/pull/14902 From amitkumar at openjdk.org Fri Aug 25 06:27:25 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 25 Aug 2023 06:27:25 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v3] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 03:49:35 GMT, Amit Kumar wrote: >> [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. >> >> For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. >> >> fastdebug build tested on **s390** & **apple m1-pro**. > > Amit Kumar has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. Sure, David. Rebase & force-pushing in favour of GHA testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14902#issuecomment-1692829069 From dholmes at openjdk.org Fri Aug 25 06:32:11 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 25 Aug 2023 06:32:11 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v4] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 06:27:24 GMT, Amit Kumar wrote: >> [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. >> >> For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. >> >> fastdebug build tested on **s390** & **apple m1-pro**. > > Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - remove extra line > - addition nits > - address @dholmes-ora suggestions > - updates header year > - risc-v > - arm > - x86 > - aarch > - ppc > - s390 Ah not a rebase and force push! Just update your master branch, do `git merge master` then `git push` to update the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14902#issuecomment-1692836193 From amitkumar at openjdk.org Fri Aug 25 06:48:14 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 25 Aug 2023 06:48:14 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v4] In-Reply-To: References: Message-ID: <1Bgduk2wDif04TclNn4WlrVxjpsmCrGrx96rQUgK0NI=.cc152024-5c52-4cc6-963b-5c2398f83d63@github.com> On Fri, 25 Aug 2023 06:29:10 GMT, David Holmes wrote: > Ah not a rebase and force push! Just update your master branch, do git merge master then git push to update the PR. Oops, Sorry. I thought you were asking for rebasing it, I pulled the changes from jdk-master branch and rebased it. I guess for now this'll do the job.. But I'll take care next time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14902#issuecomment-1692851873 From rcastanedalo at openjdk.org Fri Aug 25 07:18:11 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Fri, 25 Aug 2023 07:18:11 GMT Subject: RFR: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) [v2] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 20:39:45 GMT, Albert Mingkun Yang wrote: > Sounds reasonable. Thanks, Albert! I created [JDK-8314994](https://bugs.openjdk.org/browse/JDK-8314994) to capture your suggestions, please feel free to edit/extend the description if needed to reflect better your idea. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15288#issuecomment-1692883168 From rcastanedalo at openjdk.org Fri Aug 25 07:21:28 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Fri, 25 Aug 2023 07:21:28 GMT Subject: Integrated: 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) In-Reply-To: References: Message-ID: On Tue, 15 Aug 2023 12:43:56 GMT, Roberto Casta?eda Lozano wrote: > This changeset ensures that the array copy stub underlying the intrinsic implementation of `Object.clone` only copies its (double-word aligned) payload, excluding the remaining object alignment padding words, when a non-default `ObjectAlignmentInBytes` value is used. This prevents the specialized ZGC stubs for `Object[]` array copy from processing undefined object alignment padding words as valid object pointers. For further details about the specific failure, see [initial analysis](https://bugs.openjdk.org/browse/JDK-8312749?focusedCommentId=14600658&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14600658) by Erik ?sterlund and Stefan Karlsson and comments in the regression test included in this changeset. > > As a side-benefit, the changeset simplifies the array size computation logic in `GraphKit::new_array()` by decoupling computation of header size and alignment padding size. > > #### Testing > > ##### Functionality > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - tier4-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64; ZGC-specific tests only) > - tier6-9 (linux-x64; ZGC-specific tests only) > - tier1-3, and a few custom examples, applying [JDK-8139457](https://github.com/openjdk/jdk/pull/11044) (under review) on top of this changeset > > ##### Performance > > Tested performance on the following set of OpenJDK micro-benchmarks, on linux-x64 (for both G1 and ZGC, using different ObjectAlignmentInBytes values): > > - `openjdk.bench.java.lang.ArrayClone.byteClone` > - `openjdk.bench.java.lang.ArrayClone.intClone` > - `openjdk.bench.java.lang.ArrayFiddle.simple_clone` > - `openjdk.bench.java.lang.Clone.cloneLarge` > - `openjdk.bench.java.lang.Clone.cloneThreeDifferent` > > No significant regression was observed. This pull request has now been integrated. Changeset: 002b5948 Author: Roberto Casta?eda Lozano URL: https://git.openjdk.org/jdk/commit/002b59487094f98d9805997b5d1122c1a411b391 Stats: 115 lines in 4 files changed: 89 ins; 9 del; 17 mod 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) Co-authored-by: Stefan Karlsson Co-authored-by: Erik ?sterlund Reviewed-by: thartmann, ayang, kvn ------------- PR: https://git.openjdk.org/jdk/pull/15288 From azafari at openjdk.org Fri Aug 25 08:07:09 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 25 Aug 2023 08:07:09 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 16:38:21 GMT, Johan Sj?len wrote: >> src/hotspot/share/prims/jvmtiImpl.cpp line 126: >> >>> 124: assert(e2 != nullptr, "e2 != nullptr"); >>> 125: >>> 126: return v->equals(e2); >> >> Please rename the `v` parameter to `e1` > > And since you're here: Could you change the code style so that it's `GrowableElement* e2` and not `GrowableElement *e2`? Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1305332006 From azafari at openjdk.org Fri Aug 25 08:07:11 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 25 Aug 2023 08:07:11 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 16:38:55 GMT, Johan Sj?len wrote: >> The `find` method now is >> ```C++ >> template >> int find(T* token, bool f(T*, E)) const { >> ... >> >> Any other functions which use this are also changed. >> Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. > > src/hotspot/share/prims/jvmtiImpl.hpp line 91: > >> 89: void (*_listener_fun)(void *, address*); >> 90: >> 91: static bool equals(GrowableElement *, GrowableElement *); > > Remove spacing between `GrowableElement` and `*` Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1305332211 From jsjolen at openjdk.org Fri Aug 25 08:35:08 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 25 Aug 2023 08:35:08 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 02:41:19 GMT, David Holmes wrote: >> The `find` method now is >> ```C++ >> template >> int find(T* token, bool f(T*, E)) const { >> ... >> >> Any other functions which use this are also changed. >> Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. > > src/hotspot/share/utilities/growableArray.hpp line 213: > >> 211: >> 212: template >> 213: int find(T* token, bool f(T*, E)) const { > > Pardon my ignorance here, but what is the type relationship between T and E? It's arbitrary and chosen by the caller through `f`, so I can't say :-). The best use case we have now is when you only have an `int` which uniquely describes an `LGRPSpace`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1305363537 From stefank at openjdk.org Fri Aug 25 08:58:10 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 25 Aug 2023 08:58:10 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method In-Reply-To: References: Message-ID: <068Gqd9adw6k8nrLAJoEMDmbw2s3RMpV0KPmWDS0OdI=.1d8171a3-012a-425c-bea6-44f538a64106@github.com> On Fri, 25 Aug 2023 08:31:58 GMT, Johan Sj?len wrote: >> src/hotspot/share/utilities/growableArray.hpp line 213: >> >>> 211: >>> 212: template >>> 213: int find(T* token, bool f(T*, E)) const { >> >> Pardon my ignorance here, but what is the type relationship between T and E? > > It's arbitrary and chosen by the caller through `f`, so I can't say :-). The best use case we have now is when you only have an `int` which uniquely describes an `LGRPSpace`. This code looks similar to a capturing lambda. Would an alternative be to use that instead and let the calling code be changed to: int i = lgrp_spaces()->find([](LGRPSpace* space) { return space->lgrp_id() == lgrp_id; }); Alternatively: auto matches_lgrp_id = [](LGRPSpace* space) { return space->lgrp_id() == lgrp_id; }; int i = lgrp_spaces()->find(matches_lgrp_id); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1305389552 From jsjolen at openjdk.org Fri Aug 25 09:48:15 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 25 Aug 2023 09:48:15 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method In-Reply-To: <068Gqd9adw6k8nrLAJoEMDmbw2s3RMpV0KPmWDS0OdI=.1d8171a3-012a-425c-bea6-44f538a64106@github.com> References: <068Gqd9adw6k8nrLAJoEMDmbw2s3RMpV0KPmWDS0OdI=.1d8171a3-012a-425c-bea6-44f538a64106@github.com> Message-ID: On Fri, 25 Aug 2023 08:55:29 GMT, Stefan Karlsson wrote: >> It's arbitrary and chosen by the caller through `f`, so I can't say :-). The best use case we have now is when you only have an `int` which uniquely describes an `LGRPSpace`. > > This code looks similar to a capturing lambda. Would an alternative be to use that instead and let the calling code be changed to: > > > int i = lgrp_spaces()->find([](LGRPSpace* space) { > return space->lgrp_id() == lgrp_id; > }); > > > Alternatively: > > auto matches_lgrp_id = [](LGRPSpace* space) { > return space->lgrp_id() == lgrp_id; > }; > > int i = lgrp_spaces()->find(matches_lgrp_id); We could just as well do a capturing lambda here, yes. Then we'd have: ```c++ template int find(F finder); It'd be a template instead of function pointer since it's a capturing lambda and `std::function` is not permitted in Hotspot AFAIK. As an aside, to clarify for readers: There's a `&` missing in the capture list of your examples. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1305442361 From azafari at openjdk.org Fri Aug 25 10:10:40 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 25 Aug 2023 10:10:40 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v2] In-Reply-To: References: Message-ID: > The `find` method now is > ```C++ > template > int find(T* token, bool f(T*, E)) const { > ... > > Any other functions which use this are also changed. > Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8314502: Change the comparator taking version of GrowableArray::find to be a template method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15418/files - new: https://git.openjdk.org/jdk/pull/15418/files/89f6d38b..f46cba87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15418&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15418&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15418.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15418/head:pull/15418 PR: https://git.openjdk.org/jdk/pull/15418 From stefank at openjdk.org Fri Aug 25 11:05:09 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 25 Aug 2023 11:05:09 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v2] In-Reply-To: References: <068Gqd9adw6k8nrLAJoEMDmbw2s3RMpV0KPmWDS0OdI=.1d8171a3-012a-425c-bea6-44f538a64106@github.com> Message-ID: On Fri, 25 Aug 2023 09:45:09 GMT, Johan Sj?len wrote: >> This code looks similar to a capturing lambda. Would an alternative be to use that instead and let the calling code be changed to: >> >> >> int i = lgrp_spaces()->find([&](LGRPSpace* space) { >> return space->lgrp_id() == lgrp_id; >> }); >> >> >> Alternatively: >> >> auto matches_lgrp_id = [&](LGRPSpace* space) { >> return space->lgrp_id() == lgrp_id; >> }; >> >> int i = lgrp_spaces()->find(matches_lgrp_id); > > We could just as well do a capturing lambda here, yes. Then we'd have: > > ```c++ > template > int find(F finder); > > > It'd be a template instead of function pointer since it's a capturing lambda and `std::function` is not permitted in Hotspot AFAIK. > > As an aside, to clarify for readers: There's a `&` missing in the capture list of your examples. Updated in-place ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1305517877 From heidinga at openjdk.org Fri Aug 25 13:56:13 2023 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 25 Aug 2023 13:56:13 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v5] In-Reply-To: References: Message-ID: <_gf28X1okZyVfbHhRjDSB3ehFyuytHFyxF4f5Z5qb4E=.6f77ccf6-5f84-485b-ad26-4bc79874e6de@github.com> On Thu, 24 Aug 2023 18:44:14 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> Another alternative is to add a new `NO_METHOD_INFO` option. Similar to the proposed API, >>... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback and javadoc clean up src/hotspot/share/classfile/javaClasses.cpp line 2990: > 2988: // direct calls for private and/or final non-static methods. > 2989: flags |= java_lang_invoke_MemberName::MN_IS_METHOD; > 2990: } Both the is_static and the else block set java_lang_invoke_MemberName::MN_IS_METHOD. Do we need to differentiate between the two cases or can they be collapsed? src/java.base/share/classes/java/lang/ClassFrameInfo.java line 48: > 46: } > 47: boolean isHidden() { > 48: return SharedSecrets.getJavaLangInvokeAccess().isHiddenMember(flags & MEMBER_INFO_FLAGS); Is it better to cache the JLIA in a static final similar to what StackFrameInfo does? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1305670313 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1305670016 From rkennke at openjdk.org Fri Aug 25 15:04:15 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 25 Aug 2023 15:04:15 GMT Subject: RFR: 8305898: Alternative self-forwarding mechanism [v19] In-Reply-To: References: <9KKpqN3GBvUxwDZPz68AmuWoTTGglMX9fK7iMZ74fPA=.03ac87b0-b3e2-4b88-9509-8940c4cd21a7@github.com> Message-ID: On Fri, 18 Aug 2023 13:48:00 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: >> >> - Merge branch 'JDK-8305896' into JDK-8305898 >> - Merge branch 'JDK-8305896' into JDK-8305898 >> - Merge branch 'JDK-8305896' into JDK-8305898 >> - Update comment about mark-word layout >> - Merge branch 'JDK-8305896' into JDK-8305898 >> - Fix tests on 32bit builds >> - Merge branch 'JDK-8305896' into JDK-8305898 >> - Merge branch 'JDK-8305896' into JDK-8305898 >> - wqRevert "Rename self-forwarded -> forward-failed" >> >> This reverts commit 4d9713ca239da8e294c63887426bfb97240d3130. >> - Merge branch 'JDK-8305896' into JDK-8305898 >> - ... and 21 more: https://git.openjdk.org/jdk/compare/d2b41e25...cd5f2374 > > src/hotspot/share/oops/oop.inline.hpp line 292: > >> 290: m = m.set_self_forwarded(); >> 291: assert(forwardee(m) == cast_to_oop(this), "encoding must be reversible"); >> 292: set_mark(m); > > Could you explain why we need to restore the displaced mark word here? I wonder why it matters what the old mark word is and why this code can't be changed to something like this: > > markWord m = markWord::prototype().set_self_forwarded(); > set_mark(m); The main reason why we need to implement the self-forwarding is to preserve the upper bits of the mark-word (specifically, the Klass* that we want to place there with JEP 450). If the header is displaced, we would install the self-forwarded bit in the tagged native-pointer that is in the header, meaning we loose the ability to get to the actual header to fetch the Klass*. We do restore the header later, but GC needs access to the Klass* meanwhile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13779#discussion_r1305779757 From rkennke at openjdk.org Fri Aug 25 15:13:42 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 25 Aug 2023 15:13:42 GMT Subject: RFR: 8305898: Alternative self-forwarding mechanism [v20] In-Reply-To: References: Message-ID: > Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers, when compaction fails, to indicate that the object has been looked at, but failed compaction into to-space. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the bit #3 (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored. Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge branch 'JDK-8305896' into JDK-8305898 - Merge branch 'JDK-8305896' into JDK-8305898 - Merge branch 'JDK-8305896' into JDK-8305898 - Merge branch 'JDK-8305896' into JDK-8305898 - Update comment about mark-word layout - Merge branch 'JDK-8305896' into JDK-8305898 - Fix tests on 32bit builds - Merge branch 'JDK-8305896' into JDK-8305898 - Merge branch 'JDK-8305896' into JDK-8305898 - wqRevert "Rename self-forwarded -> forward-failed" This reverts commit 4d9713ca239da8e294c63887426bfb97240d3130. - ... and 22 more: https://git.openjdk.org/jdk/compare/bc155699...2a00d30c ------------- Changes: https://git.openjdk.org/jdk/pull/13779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13779&range=19 Stats: 101 lines in 8 files changed: 85 ins; 2 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/13779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13779/head:pull/13779 PR: https://git.openjdk.org/jdk/pull/13779 From ccheung at openjdk.org Fri Aug 25 16:19:26 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 25 Aug 2023 16:19:26 GMT Subject: RFR: 8308464: Shared array class should not always be loaded in boot loader Message-ID: Please review this fix for using the appropriate class loader when loading a shared array class. The log output from -`Xlog:cds+unshareable=trace` is also updated to include the class loader information. For example: before: `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp` after: `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp with class loader: jdk.internal.loader.ClassLoaders$AppClassLoader` Passed tiers 1- 3 tests. ------------- Commit messages: - add assert regarding bottom_klass - 8308464: Shared array class should not always be loaded in boot loader Changes: https://git.openjdk.org/jdk/pull/15421/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15421&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8308464 Stats: 37 lines in 4 files changed: 22 ins; 5 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/15421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15421/head:pull/15421 PR: https://git.openjdk.org/jdk/pull/15421 From ecki at zusammenkunft.net Fri Aug 25 17:13:03 2023 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 25 Aug 2023 19:13:03 +0200 Subject: Older unused Intel platform check functions In-Reply-To: <608cef6a-352e-44ad-82fe-812073bce2fa@oracle.com> References: , <608cef6a-352e-44ad-82fe-812073bce2fa@oracle.com> Message-ID: <556F3D24-C0E8-D546-9576-8A8D2482D588@hxcore.ol> An HTML attachment was scrubbed... URL: From mchung at openjdk.org Fri Aug 25 17:26:13 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 25 Aug 2023 17:26:13 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v5] In-Reply-To: <_gf28X1okZyVfbHhRjDSB3ehFyuytHFyxF4f5Z5qb4E=.6f77ccf6-5f84-485b-ad26-4bc79874e6de@github.com> References: <_gf28X1okZyVfbHhRjDSB3ehFyuytHFyxF4f5Z5qb4E=.6f77ccf6-5f84-485b-ad26-4bc79874e6de@github.com> Message-ID: On Fri, 25 Aug 2023 13:35:04 GMT, Dan Heidinga wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> review feedback and javadoc clean up > > src/hotspot/share/classfile/javaClasses.cpp line 2990: > >> 2988: // direct calls for private and/or final non-static methods. >> 2989: flags |= java_lang_invoke_MemberName::MN_IS_METHOD; >> 2990: } > > Both the is_static and the else block set java_lang_invoke_MemberName::MN_IS_METHOD. Do we need to differentiate between the two cases or can they be collapsed? yes they can be collapsed. I will update it. > src/java.base/share/classes/java/lang/ClassFrameInfo.java line 48: > >> 46: } >> 47: boolean isHidden() { >> 48: return SharedSecrets.getJavaLangInvokeAccess().isHiddenMember(flags & MEMBER_INFO_FLAGS); > > Is it better to cache the JLIA in a static final similar to what StackFrameInfo does? either way is fine. I can add a static field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1305941281 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1305942726 From stefank at openjdk.org Fri Aug 25 19:16:18 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 25 Aug 2023 19:16:18 GMT Subject: RFR: 8305898: Alternative self-forwarding mechanism [v19] In-Reply-To: References: <9KKpqN3GBvUxwDZPz68AmuWoTTGglMX9fK7iMZ74fPA=.03ac87b0-b3e2-4b88-9509-8940c4cd21a7@github.com> Message-ID: <4-CDH1E1mVKg_Z6R6GSx74mZApTOfkhEHGaJ2RWKpG8=.6c617ad1-7e91-4f2a-a76e-09b87e62f555@github.com> On Fri, 25 Aug 2023 15:01:30 GMT, Roman Kennke wrote: >> src/hotspot/share/oops/oop.inline.hpp line 292: >> >>> 290: m = m.set_self_forwarded(); >>> 291: assert(forwardee(m) == cast_to_oop(this), "encoding must be reversible"); >>> 292: set_mark(m); >> >> Could you explain why we need to restore the displaced mark word here? I wonder why it matters what the old mark word is and why this code can't be changed to something like this: >> >> markWord m = markWord::prototype().set_self_forwarded(); >> set_mark(m); > > The main reason why we need to implement the self-forwarding is to preserve the upper bits of the mark-word (specifically, the Klass* that we want to place there with JEP 450). If the header is displaced, we would install the self-forwarded bit in the tagged native-pointer that is in the header, meaning we loose the ability to get to the actual header to fetch the Klass*. We do restore the header later, but GC needs access to the Klass* meanwhile. Thanks. While reviewing this patch I was thinking about the current JDK code, which as far as I understand doesn't need to restore the displaced header here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13779#discussion_r1306061533 From rkennke at openjdk.org Fri Aug 25 19:35:11 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 25 Aug 2023 19:35:11 GMT Subject: RFR: 8305898: Alternative self-forwarding mechanism [v19] In-Reply-To: <4-CDH1E1mVKg_Z6R6GSx74mZApTOfkhEHGaJ2RWKpG8=.6c617ad1-7e91-4f2a-a76e-09b87e62f555@github.com> References: <9KKpqN3GBvUxwDZPz68AmuWoTTGglMX9fK7iMZ74fPA=.03ac87b0-b3e2-4b88-9509-8940c4cd21a7@github.com> <4-CDH1E1mVKg_Z6R6GSx74mZApTOfkhEHGaJ2RWKpG8=.6c617ad1-7e91-4f2a-a76e-09b87e62f555@github.com> Message-ID: <0bTasRI3XvwGLzWmKw-3NFD3VV_vlEZpTrRJETG1XuY=.58e30713-c835-44d6-a633-5de2de77ca9d@github.com> On Fri, 25 Aug 2023 19:13:22 GMT, Stefan Karlsson wrote: >> The main reason why we need to implement the self-forwarding is to preserve the upper bits of the mark-word (specifically, the Klass* that we want to place there with JEP 450). If the header is displaced, we would install the self-forwarded bit in the tagged native-pointer that is in the header, meaning we loose the ability to get to the actual header to fetch the Klass*. We do restore the header later, but GC needs access to the Klass* meanwhile. > > Thanks. While reviewing this patch I was thinking about the current JDK code, which as far as I understand doesn't need to restore the displaced header here. Right. It might be cleaner to move that part out of here and into #13961, WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13779#discussion_r1306078203 From rriggs at openjdk.org Fri Aug 25 21:05:20 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 25 Aug 2023 21:05:20 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v5] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 18:44:14 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would hav... > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review feedback and javadoc clean up src/java.base/share/classes/java/lang/StackWalker.java line 55: > 53: * available but not the {@link StackFrame#getDeclaringClass() Class reference}. > 54: * The {@code Class} reference can be accessed if {@link Option#RETAIN_CLASS_REFERENCE} > 55: * RETAIN_CLASS_REFERENCE} option is set. Double `}` in the link. src/java.base/share/classes/java/lang/StackWalker.java line 249: > 247: * > 248: * @throws UnsupportedOperationException if the {@code StackWalker} is of > 249: * {@link Kind#CLASS_INFO CLASS_INFO} kind Other CLASS_INFO methods use the javadoc: if the StackWalker collects class only information ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306129921 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306143327 From david.holmes at oracle.com Fri Aug 25 21:13:38 2023 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Aug 2023 07:13:38 +1000 Subject: Older unused Intel platform check functions In-Reply-To: <556F3D24-C0E8-D546-9576-8A8D2482D588@hxcore.ol> References: <608cef6a-352e-44ad-82fe-812073bce2fa@oracle.com> <556F3D24-C0E8-D546-9576-8A8D2482D588@hxcore.ol> Message-ID: On 26/08/2023 3:13 am, Bernd wrote: > Hello David. > > Thanks for the hint (GitHub search seems to swallow that) > > (Is x86_32.ab used in 64Bit builds?) I don't think so, but compiler folk would need to confirm that. > Btw regarding my initial question, the only requirement I have seen so > far are asserts asking for SSE2 ? since those instructions are part of > the x86_64 baseline API it looks like the source at least does not > require x86_64-v2 or newer. (That was probably an entirely different > thing for x86). I can't help with the general query, sorry. David > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* David Holmes > *Gesendet:* Freitag, August 25, 2023 3:57 AM > *An:* Bernd Eckenfels ; hotspot-dev at openjdk.org > > *Betreff:* Re: Older unused Intel platform check functions > Hi Bernd, > > On 25/08/2023 9:23 am, Bernd Eckenfels wrote: > > Hello, > > > > I was checking out to see a hint of what?s the minimum microarchitecture > > is, which makes sense to require for OpenJDK. I was not very successful > > and it probably depends on compiler toolchain and distribution. Does > > somebody have some insights? > > > > Having said that I noticed the following: > > > > The 20 years old netburst architecture has a test function but it?s not > > used to make feature decisions in the JDK, it is just used to construct > > a SSE feature string, where it can be safely removed (the feature flags > > are reported anyway, worst case use cpu_family_description instead?) > > > > VM_Version::is_netburst > > > > If you want to keep it, it?s probably more consistent to rename it to > > is_intel_netburst > > Yes netburst seem unused now. > > > > > VM_Version::is_default_intel_cascadelake > > VM_Version::is_intel_cascadelake > > > > Those two seem not to be used anywhere, can probably be removed as well. > > Yes they are used: ./cpu/x86/x86.ad ./cpu/x86/x86_64.ad > > Cheers, > David > From mchung at openjdk.org Fri Aug 25 22:22:43 2023 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 25 Aug 2023 22:22:43 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker > collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used > instead and such stack walker will save the overhead (1) to extract the method information > and (2) the memory used for the stack walking. In addition, this can also fix > > - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: > > > StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(interestingClasses::contains) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Javadoc & specdiff > > https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html > https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > Another alte... Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: - fixup javadoc - Review feedback: move JLIA to ClassFrameInfo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/a3a44575..4c5c5d79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=04-05 Stats: 19 lines in 4 files changed: 3 ins; 10 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From vladimir.kozlov at oracle.com Fri Aug 25 22:50:35 2023 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Aug 2023 15:50:35 -0700 Subject: Older unused Intel platform check functions In-Reply-To: References: <608cef6a-352e-44ad-82fe-812073bce2fa@oracle.com> <556F3D24-C0E8-D546-9576-8A8D2482D588@hxcore.ol> Message-ID: Hi Bernd, I don't know what you used for search but, please, use `grep -r` instead of search in IDE. There are HotSpot VM files (like .ad files, used by JIT compilation) which IDE may not look into. You may also look on history of code in GitHub to see changes which introduced them. `is_default_intel_cascadelake` is recent addition [1]. > (Is x86_32.ad used in 64Bit builds?) No. Only x86.ad and x86_64.ad (and other cpu specific files without _32 suffix) are used for 64-bit JDK build. Note, Oracle does not support x86 32-bit but OpenJDK Community do support it. `Netburst` check was added as part of Java Flight Recorder implementation [2] and was part of other information passed to JFR. I don't see it its reference in ` src/jdk.jfr/` so I assume it was used as simple CPU version string in JFR output. Based on that I think it can be removed. This indicate again that we need to check other parts of JDK for possible use of HtoSpot fuctions. Thanks, Vladimir K [1] https://github.com/openjdk/jdk/commit/941a7ac7dab243c6033a78880fd31faa803e62ab [2] https://bugs.openjdk.org/browse/JDK-8193393 On 8/25/23 2:13 PM, David Holmes wrote: > On 26/08/2023 3:13 am, Bernd wrote: >> Hello David. >> >> Thanks for the hint (GitHub search seems to swallow that) >> >> (Is x86_32.ab used in 64Bit builds?) > > I don't think so, but compiler folk would need to confirm that. > >> Btw regarding my initial question, the only requirement I have seen so far are asserts asking for SSE2 ? since those >> instructions are part of the x86_64 baseline API it looks like the source at least does not require x86_64-v2 or >> newer. (That was probably an entirely different thing for x86). > > I can't help with the general query, sorry. > > David > >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------ >> *Von:* David Holmes >> *Gesendet:* Freitag, August 25, 2023 3:57 AM >> *An:* Bernd Eckenfels ; hotspot-dev at openjdk.org >> *Betreff:* Re: Older unused Intel platform check functions >> Hi Bernd, >> >> On 25/08/2023 9:23 am, Bernd Eckenfels wrote: >> ?> Hello, >> ?> >> ?> I was checking out to see a hint of what?s the minimum microarchitecture >> ?> is, which makes sense to require for OpenJDK. I was not very successful >> ?> and it probably depends on compiler toolchain and distribution. Does >> ?> somebody have some insights? >> ?> >> ?> Having said that I noticed the following: >> ?> >> ?> The 20 years old netburst architecture has a test function but it?s not >> ?> used to make feature decisions in the JDK, it is just used to construct >> ?> a SSE feature string, where it can be safely removed (the feature flags >> ?> are reported anyway, worst case use cpu_family_description instead?) >> ?> >> ?> VM_Version::is_netburst >> ?> >> ?> If you want to keep it, it?s probably more consistent to rename it to >> ?> is_intel_netburst >> >> Yes netburst seem unused now. >> >> ?> >> ?> VM_Version::is_default_intel_cascadelake >> ?> VM_Version::is_intel_cascadelake >> ?> >> ?> Those two seem not to be used anywhere, can probably be removed as well. >> >> Yes they are used: ./cpu/x86/x86.ad ./cpu/x86/x86_64.ad >> >> Cheers, >> David >> From ascarpino at openjdk.org Sat Aug 26 00:18:07 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Sat, 26 Aug 2023 00:18:07 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 06:12:29 GMT, Smita Kamath wrote: > Hi All, > I would like to submit AES-GCM optimization for x86_64 architectures using AVX2 instructions. This optimization interleaves AES and GHASH operations. > > Below are the performance numbers on my desktop system with -XX:UseAVX=2 option: > > |Benchmark | Data Size | Base version (ops/s) | Patched version (ops/s) | Speedup > |-------------|------------|---------------|------------------|-----------| > |full.AESGCMBench.decrypt | 8192 | 526274.678 | 670014.543 | 1.27 > full.AESGCMBench.encrypt | 8192 | 538293.315 | 680716.207 | 1.26 > small.AESGCMBench.decrypt | 8192 | 527854.353 |663131.48 | 1.25 > small.AESGCMBench.encrypt | 8192 | 548193.804 | 683624.232 |1.24 > full.AESGCMBench.decryptMultiPart | 8192 | 299865.766 | 299815.851 | 0.99 > full.AESGCMBench.encryptMultiPart | 8192 | 534406.564 |539235.462 | 1.00 > small.AESGCMBench.decryptMultiPart | 8192 | 299960.202 |298913.629 | 0.99 > small.AESGCMBench.encryptMultiPart | 8192 | 542669.258 | 540552.293 | 0.99 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 16384 | 307266.364 |390397.778 | 1.27 > full.AESGCMBench.encrypt | 16384 | 311491.901 | 397279.681 | 1.27 > small.AESGCMBench.decrypt | 16384 | 306257.801 | 389531.665 |1.27 > small.AESGCMBench.encrypt | 16384 | 311468.972 | 397804.753 | 1.27 > full.AESGCMBench.decryptMultiPart | 16384 | 159634.341 | 181271.487 | 1.13 > full.AESGCMBench.encryptMultiPart | 16384 | 308980.992 | 385606.113 | 1.24 > small.AESGCMBench.decryptMultiPart | 16384 | 160476.064 |181019.205 | 1.12 > small.AESGCMBench.encryptMultiPart | 16384 | 308382.656 | 391126.417 | 1.26 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 32768 | 162284.703 | 213257.481 |1.31 > full.AESGCMBench.encrypt | 32768 | 164833.104 | 215568.639 | 1.30 > small.AESGCMBench.decrypt | 32768 | 164416.491 | 213422.347 | 1.29 > small.AESGCMBench.encrypt | 32768 | 166619.205 | 214584.208 |1.28 > full.AESGCMBench.decryptMultiPart | 32768 | 83306.239 | 93762.988 |1.12 > full.AESGCMBench.encryptMultiPart | 32768 | 166109.391 |211701.969 | 1.27 > small.AESGCMBench.decryptMultiPart | 32768 | 83792.559 | 94530.786 | 1.12 > small.AESGCMBench.encryptMultiPart | 32768 | 162975.904 |212085.047 | 1.30 > ? | ? | ? | ? | ? > full.AESGCMBench.decrypt | 65536 | 85765.835 | 112244.611 | 1.30 > full.AESGCMBench.encrypt | 65536 | 86471.805 | 113320.536 |1.31 > small.AESGCMBench.decrypt | 65536 | 84490.816 | 112122.358 |1.32 > small.AESGCMBench.encrypt | 65536 | 85403.025 | 112741.811 | 1.32 > full.AESGCMBench.decryptMultiPart | 65536 | 42649.816 | 47591.587 |1.11 > full.AESGCMBe... I'm curious in the Java code, why an encryption boolean was needed for this change but wasn't needed for the AVX512 changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1694061827 From forax at openjdk.org Sat Aug 26 09:28:24 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 26 Aug 2023 09:28:24 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would hav... > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo src/java.base/share/classes/java/lang/ClassFrameInfo.java line 34: > 32: static final JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess(); > 33: > 34: protected Object classOrMemberName; // Class or ResolvedMemberName initialized by VM I believe that the package-private access is enough here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306387977 From forax at openjdk.org Sat Aug 26 09:35:20 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 26 Aug 2023 09:35:20 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would hav... > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo src/java.base/share/classes/java/lang/StackFrameInfo.java line 82: > 80: > 81: { > 82: // Get a snapshot of type which doesn't get changed by racing threads. Also the constructed MethodType is non mutable src/java.base/share/classes/java/lang/StackFrameInfo.java line 94: > 92: type = JLIA.getMethodType(sig, declaringClass().getClassLoader()); > 93: } > 94: assert type instanceof MethodType : "bad method type " + type; Not sure this assert is useful given the next instruction is a cast to MethodType ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306389071 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306389160 From forax at openjdk.org Sat Aug 26 09:45:23 2023 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 26 Aug 2023 09:45:23 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would hav... > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo src/java.base/share/classes/java/lang/StackWalker.java line 81: > 79: * Optional> callerClass = walker.walk(s -> > 80: * s.map(StackFrame::getDeclaringClass) > 81: * .filter(interestingClasses::contains) Usually it's more `.filter(Predicate.not(implClasses::contains))` src/java.base/share/classes/java/lang/StackWalker.java line 88: > 86: * {@snippet lang="java" : > 87: * List stack = StackWalker.getInstance().walk(s -> > 88: * s.limit(10).collect(Collectors.toList())); `s.limit(10).toList()` src/java.base/share/classes/java/lang/StackWalker.java line 505: > 503: */ > 504: public static StackWalker getInstance(Kind kind, Option... options) { > 505: return getInstance(Objects.requireNonNull(kind), Set.of(Objects.requireNonNull(options))); Set.of() already does a NPE check src/java.base/share/classes/java/lang/StackWalker.java line 649: > 647: * s.dropWhile(f -> f.getClassName().startsWith("com.foo.")) > 648: * .limit(10) > 649: * .collect(Collectors.toList())); `.toList())` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306390180 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306390266 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306390553 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306390713 From alanb at openjdk.org Sat Aug 26 13:44:08 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 26 Aug 2023 13:44:08 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote: > yes this is of course AIX specific. However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files. Right now, you've got concerns/objections from two potential reviewers so it would be better to see if there are other options to help the error logs on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1694344116 From kbarrett at openjdk.org Sat Aug 26 18:51:09 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 26 Aug 2023 18:51:09 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v2] In-Reply-To: References: <068Gqd9adw6k8nrLAJoEMDmbw2s3RMpV0KPmWDS0OdI=.1d8171a3-012a-425c-bea6-44f538a64106@github.com> Message-ID: On Fri, 25 Aug 2023 11:02:24 GMT, Stefan Karlsson wrote: >> We could just as well do a capturing lambda here, yes. Then we'd have: >> >> ```c++ >> template >> int find(F finder); >> >> >> It'd be a template instead of function pointer since it's a capturing lambda and `std::function` is not permitted in Hotspot AFAIK. >> >> As an aside, to clarify for readers: There's a `&` missing in the capture list of your examples. > > Updated in-place Not a review, just agreeing with @stefank and @jdksjolen . What they describe is idiomatic C++. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1306553072 From eastigeevich at openjdk.org Sat Aug 26 20:13:14 2023 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Sat, 26 Aug 2023 20:13:14 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 05:35:49 GMT, Boris Ulasevich wrote: >> This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 >> >> The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. >> >> InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: >> >> >> Cortex-A53 (Pi 3 Model B Rev 1.2) >> >> test1stInt2Types 37.5 37.358 0.38 >> test1stInt3Types 160.166 148.04 8.19 >> test1stInt5Types 158.131 147.955 6.88 >> test2ndInt2Types 52.634 53.291 -1.23 >> test2ndInt3Types 201.39 181.603 10.90 >> test2ndInt5Types 195.722 176.707 10.76 >> testIfaceCall 157.453 140.498 12.07 >> testIfaceExtCall 175.46 154.351 13.68 >> testMonomorphic 32.052 32.039 0.04 >> AVG: 6.85 >> >> Cortex-A72 (Pi 4 Model B Rev 1.2) >> >> test1stInt2Types 27.4796 27.4738 0.02 >> test1stInt3Types 66.0085 64.9374 1.65 >> test1stInt5Types 67.9812 66.2316 2.64 >> test2ndInt2Types 32.0581 32.062 -0.01 >> test2ndInt3Types 68.2715 65.6643 3.97 >> test2ndInt5Types 68.1012 65.8024 3.49 >> testIfaceCall 64.0684 64.1811 -0.18 >> testIfaceExtCall 91.6226 81.5867 12.30 >> testMonomorphic 26.7161 26.7142 0.01 >> AVG: 2.66 >> >> Neoverse N1 (m6g.metal) >> >> test1stInt2Types 2.9104 2.9086 0.06 >> test1stInt3Types 10.9642 10.2909 6.54 >> test1stInt5Types 10.9607 10.2856 6.56 >> test2ndInt2Types 3.3410 3.3478 -0.20 >> test2ndInt3Types 12.3291 11.3089 9.02 >> test2ndInt5Types 12.328 11.2704 9.38 >> testIfaceCall 11.0598 10.3657 6.70 >> testIfaceExtCall 13.0692 11.2826 15.84 >> testMonomorphic 2.2354 2.2341 0.06 >> AVG: 6.00 >> >> Neoverse V1 (c7g.2xlarge) >> >> test1stInt2Types 2.2317 2.2320 -0.01 >> test1stInt3Types 6.6884 6.1911 8.03 >> test1stInt5Types 6.7334 6.2193 8.27 >> test2ndInt2Types 2.4002 2.4013 -0.04 >> test2ndInt3Types 7.9603 7.0372 13.12 >> test2ndInt5Types 7.9532 7.0474 12.85 >> testIfaceCall 6.7028 6.3272 5.94 >> testIfaceExtCall 8.3253 6.941... > > Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: > > Comments applied: get rid of temp_reg3; replace the magic constants src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1231: > 1229: // itableOffsetEntry[] itable = recv_klass + Klass::vtable_start_offset() + sizeof(vtableEntry) * recv_klass->_vtable_len; > 1230: // temp_itbl_klass = itable[0]._interface; > 1231: ldr(temp_itbl_klass, Address(recv_klass, scan_temp, Address::lsl(exact_log2(vtableEntry::size_in_bytes())))); The shift in `ldr` must be 3. Can we have a static assert checking that? There is an assert in `Address::encode` which will catch the issue in debug builds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1306560895 From aph at openjdk.org Sat Aug 26 20:42:14 2023 From: aph at openjdk.org (Andrew Haley) Date: Sat, 26 Aug 2023 20:42:14 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: On Sat, 26 Aug 2023 20:10:49 GMT, Evgeny Astigeevich wrote: >> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Comments applied: get rid of temp_reg3; replace the magic constants > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1231: > >> 1229: // itableOffsetEntry[] itable = recv_klass + Klass::vtable_start_offset() + sizeof(vtableEntry) * recv_klass->_vtable_len; >> 1230: // temp_itbl_klass = itable[0]._interface; >> 1231: ldr(temp_itbl_klass, Address(recv_klass, scan_temp, Address::lsl(exact_log2(vtableEntry::size_in_bytes())))); > > The lsl shift in `ldr` must be 3. > Can we have a static assert checking that? There is an assert in `Address::encode` which will catch the issue in debug builds. As `vtableEntry::size_in_bytes()` is statically known we can catch the issue during compilation. I'm very surprised that isn't a guarantee. I had to look to be sure. I'd simply change `assert(ext().shift() <= 0 || ext().shift() == (int)size, "bad shift");` to a `guarantee`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1306563213 From eastigeevich at openjdk.org Sat Aug 26 20:54:22 2023 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Sat, 26 Aug 2023 20:54:22 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 05:35:49 GMT, Boris Ulasevich wrote: >> This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 >> >> The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. >> >> InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: >> >> >> Cortex-A53 (Pi 3 Model B Rev 1.2) >> >> test1stInt2Types 37.5 37.358 0.38 >> test1stInt3Types 160.166 148.04 8.19 >> test1stInt5Types 158.131 147.955 6.88 >> test2ndInt2Types 52.634 53.291 -1.23 >> test2ndInt3Types 201.39 181.603 10.90 >> test2ndInt5Types 195.722 176.707 10.76 >> testIfaceCall 157.453 140.498 12.07 >> testIfaceExtCall 175.46 154.351 13.68 >> testMonomorphic 32.052 32.039 0.04 >> AVG: 6.85 >> >> Cortex-A72 (Pi 4 Model B Rev 1.2) >> >> test1stInt2Types 27.4796 27.4738 0.02 >> test1stInt3Types 66.0085 64.9374 1.65 >> test1stInt5Types 67.9812 66.2316 2.64 >> test2ndInt2Types 32.0581 32.062 -0.01 >> test2ndInt3Types 68.2715 65.6643 3.97 >> test2ndInt5Types 68.1012 65.8024 3.49 >> testIfaceCall 64.0684 64.1811 -0.18 >> testIfaceExtCall 91.6226 81.5867 12.30 >> testMonomorphic 26.7161 26.7142 0.01 >> AVG: 2.66 >> >> Neoverse N1 (m6g.metal) >> >> test1stInt2Types 2.9104 2.9086 0.06 >> test1stInt3Types 10.9642 10.2909 6.54 >> test1stInt5Types 10.9607 10.2856 6.56 >> test2ndInt2Types 3.3410 3.3478 -0.20 >> test2ndInt3Types 12.3291 11.3089 9.02 >> test2ndInt5Types 12.328 11.2704 9.38 >> testIfaceCall 11.0598 10.3657 6.70 >> testIfaceExtCall 13.0692 11.2826 15.84 >> testMonomorphic 2.2354 2.2341 0.06 >> AVG: 6.00 >> >> Neoverse V1 (c7g.2xlarge) >> >> test1stInt2Types 2.2317 2.2320 -0.01 >> test1stInt3Types 6.6884 6.1911 8.03 >> test1stInt5Types 6.7334 6.2193 8.27 >> test2ndInt2Types 2.4002 2.4013 -0.04 >> test2ndInt3Types 7.9603 7.0372 13.12 >> test2ndInt5Types 7.9532 7.0474 12.85 >> testIfaceCall 6.7028 6.3272 5.94 >> testIfaceExtCall 8.3253 6.941... > > Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: > > Comments applied: get rid of temp_reg3; replace the magic constants src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1297: > 1295: bind(L_holder_found); > 1296: ldrw(method_result, Address(scan_temp, ooffset - ioffset)); > 1297: add(recv_klass, recv_klass, (itable_index << LogBytesPerWord) + in_bytes(itableMethodEntry::method_offset()) - vtable_start_offset - ioffset); Maybe use `itable_index * wordSize` instead of `itable_index << LogBytesPerWord` to look the same as in the x86 variant of `lookup_interface_method_stub`. Also a comment that `- vtable_start_offset - ioffset` is used to restore the original value of `recv_klass` would be useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1306564344 From kbarrett at openjdk.org Sun Aug 27 17:06:08 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 27 Aug 2023 17:06:08 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v2] In-Reply-To: References: <068Gqd9adw6k8nrLAJoEMDmbw2s3RMpV0KPmWDS0OdI=.1d8171a3-012a-425c-bea6-44f538a64106@github.com> Message-ID: <2kgLlH__lH2LiM7VdVePqCgW8Uck-AvrO-klTB8yzq4=.66ad8590-4661-47f2-b206-5979c8dba063@github.com> On Sat, 26 Aug 2023 18:48:22 GMT, Kim Barrett wrote: >> Updated in-place > > Not a review, just agreeing with @stefank and @jdksjolen . What they describe is idiomatic C++. Also, why isn't this change also being applied to `find_from_end` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1306694945 From sgibbons at openjdk.org Sun Aug 27 23:08:08 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Sun, 27 Aug 2023 23:08:08 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v3] In-Reply-To: <8khU4xdNeQ0OEVh75BXAJa3FADY8BRybm8epd72IN2U=.d2b56713-4d74-472e-9d70-7f44e24ea37a@github.com> References: <8khU4xdNeQ0OEVh75BXAJa3FADY8BRybm8epd72IN2U=.d2b56713-4d74-472e-9d70-7f44e24ea37a@github.com> Message-ID: On Thu, 24 Aug 2023 22:08:50 GMT, Sandhya Viswanathan wrote: > The changes look good to me now. Could you please also get the performance of DremFrem jmh micro with/without your PR for both UseAVX=2 and UseAVX=3? Results of DremFrem: Before these changes: java -XX:UseAVX=2 -jar ./build/linux-x86_64-server-release/images/test/micro/benchmarks.jar -f 1 DremFrem: Benchmark Mode Cnt Score Error Units DremFrem.calcDoubleJava avgt 5 5.645 ? 0.003 ns/op DremFrem.calcFloatJava avgt 5 6.044 ? 0.005 ns/op DremFrem.cornercaseDoubleJava avgt 5 5.462 ? 0.033 ns/op DremFrem.cornercaseFloatJava avgt 5 5.494 ? 0.045 ns/op java -XX:UseAVX=3 -jar ./build/linux-x86_64-server-release/images/test/micro/benchmarks.jar -f 1 DremFrem: Benchmark Mode Cnt Score Error Units DremFrem.calcDoubleJava avgt 5 2.916 ? 0.006 ns/op DremFrem.calcFloatJava avgt 5 4.016 ? 0.001 ns/op DremFrem.cornercaseDoubleJava avgt 5 5.506 ? 0.009 ns/op DremFrem.cornercaseFloatJava avgt 5 5.506 ? 0.010 ns/op ============================================= WITH these changes: java -XX:UseAVX=2 -jar ./build/linux-x86_64-server-release/images/test/micro/benchmarks.jar -f 1 DremFrem: Benchmark Mode Cnt Score Error Units DremFrem.calcDoubleJava avgt 5 2.838 ? 0.001 ns/op DremFrem.calcFloatJava avgt 5 3.554 ? 0.002 ns/op DremFrem.cornercaseDoubleJava avgt 5 5.511 ? 0.022 ns/op DremFrem.cornercaseFloatJava avgt 5 5.467 ? 0.014 ns/op java -XX:UseAVX=3 -jar ./build/linux-x86_64-server-release/images/test/micro/benchmarks.jar -f 1 DremFrem: Benchmark Mode Cnt Score Error Units DremFrem.calcDoubleJava avgt 5 2.598 ? 0.001 ns/op DremFrem.calcFloatJava avgt 5 3.229 ? 0.001 ns/op DremFrem.cornercaseDoubleJava avgt 5 5.508 ? 0.014 ns/op DremFrem.cornercaseFloatJava avgt 5 5.511 ? 0.005 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/15210#issuecomment-1694785650 From dholmes at openjdk.org Mon Aug 28 01:10:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 28 Aug 2023 01:10:08 GMT Subject: RFR: 8308464: Shared array class should not always be loaded in boot loader In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 19:35:25 GMT, Calvin Cheung wrote: > Please review this fix for using the appropriate class loader when loading a shared array class. The log output from -`Xlog:cds+unshareable=trace` is also updated to include the class loader information. > > For example: > before: > `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp` > > after: > `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp with class loader: jdk.internal.loader.ClassLoaders$AppClassLoader` > > Passed tiers 1- 3 tests. LGTM. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15421#pullrequestreview-1597285989 From dholmes at openjdk.org Mon Aug 28 02:29:18 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 28 Aug 2023 02:29:18 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken wrote: >> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code. >> Some examples : >> Events::log_dll_message for hs-err files reporting >> JFR event NativeLibraryLoad >> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ), >> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information >> >> Offer an interface (e.g. jvm.cpp) to support this. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > windows aarch64 build issues Sorry but looking at the hotspot part of this I do not like the code in jvm.cpp at all - it is far too messy. I expected to see a simple interface to os::dlopen which then handles all the platform specific issues. I'm also somewhat dubious about having all the JDK code use a VM interface for this, The usual coupling to the VM is to just provide native implementations of core library methods, not to have the VM provide a general purpose utility interface like dynamic library loading. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1694907802 From amitkumar at openjdk.org Mon Aug 28 03:37:21 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 28 Aug 2023 03:37:21 GMT Subject: RFR: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() [v4] In-Reply-To: References: Message-ID: <1DSBjk1V1Rax5XvXmTah6WhuF05u_ZjByd1lrje8dQA=.97b2c625-9d0c-4f78-bc8a-68eb3f666ba6@github.com> On Fri, 25 Aug 2023 06:27:24 GMT, Amit Kumar wrote: >> [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. >> >> For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. >> >> fastdebug build tested on **s390** & **apple m1-pro**. > > Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - remove extra line > - addition nits > - address @dholmes-ora suggestions > - updates header year > - risc-v > - arm > - x86 > - aarch > - ppc > - s390 Thanks David, Stefan for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14902#issuecomment-1694951861 From amitkumar at openjdk.org Mon Aug 28 03:37:22 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 28 Aug 2023 03:37:22 GMT Subject: Integrated: 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 11:21:47 GMT, Amit Kumar wrote: > [small cleanup/enhancement] Adds & updates some code to use `interpreter_frame_monitor_size_in_bytes()` method. I wasn't sure whether we should remove it from PPC & S390 implementation or add it to other archs. For now I have added it but will be happy to revert as PR reviews. > > For s390 `interpreter_frame_interpreterstate_size_in_bytes()` was also cleaned up as it is not being used. > > fastdebug build tested on **s390** & **apple m1-pro**. This pull request has now been integrated. Changeset: 7fbad4cd Author: Amit Kumar URL: https://git.openjdk.org/jdk/commit/7fbad4cd5e2b6107410e82ae774aa8b5c05f6054 Stats: 58 lines in 21 files changed: 6 ins; 21 del; 31 mod 8310596: Utilize existing method frame::interpreter_frame_monitor_size_in_bytes() Reviewed-by: dholmes, stefank ------------- PR: https://git.openjdk.org/jdk/pull/14902 From mbaesken at openjdk.org Mon Aug 28 07:05:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 28 Aug 2023 07:05:13 GMT Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase [v2] In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 02:26:30 GMT, David Holmes wrote: > Sorry but looking at the hotspot part of this I do not like the code in jvm.cpp at all - it is far too messy. I expected to see a simple interface to os::dlopen which then handles all the platform specific issues. > > I'm also somewhat dubious about having all the JDK code use a VM interface for this, The usual coupling to the VM is to just provide native implementations of core library methods, not to have the VM provide a general purpose utility interface like dynamic library loading. Hi David, so would you prefer to call into 'os::dll_load' (probably you meant that) instead ? That would indeed make the coding smaller and less 'messy' . However 'os::dll_load' has no flags parameter but uses a default, have to check if this might be a problem ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1695142975 From stefank at openjdk.org Mon Aug 28 08:15:12 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 28 Aug 2023 08:15:12 GMT Subject: RFR: 8305898: Alternative self-forwarding mechanism [v19] In-Reply-To: <0bTasRI3XvwGLzWmKw-3NFD3VV_vlEZpTrRJETG1XuY=.58e30713-c835-44d6-a633-5de2de77ca9d@github.com> References: <9KKpqN3GBvUxwDZPz68AmuWoTTGglMX9fK7iMZ74fPA=.03ac87b0-b3e2-4b88-9509-8940c4cd21a7@github.com> <4-CDH1E1mVKg_Z6R6GSx74mZApTOfkhEHGaJ2RWKpG8=.6c617ad1-7e91-4f2a-a76e-09b87e62f555@github.com> <0bTasRI3XvwGLzWmKw-3NFD3VV_vlEZpTrRJETG1XuY=.58e30713-c835-44d6-a633-5de2de77ca9d@github.com> Message-ID: On Fri, 25 Aug 2023 19:32:35 GMT, Roman Kennke wrote: >> Thanks. While reviewing this patch I was thinking about the current JDK code, which as far as I understand doesn't need to restore the displaced header here. > > Right. It might be cleaner to move that part out of here and into #13961, WDYT? I think that would be good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13779#discussion_r1307092468 From rcastanedalo at openjdk.org Mon Aug 28 09:10:38 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 28 Aug 2023 09:10:38 GMT Subject: RFR: 8315029: [BACKOUT] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) Message-ID: This changeset backs out the changes introduced by [JDK-8312749](https://bugs.openjdk.org/browse/JDK-8312749) and re-enables the problem-listed `test/jdk/java/lang/template/StringTemplateTest.java`. The backed-out issue will be re-addressed in [JDK-8315082](https://bugs.openjdk.org/browse/JDK-8315082). #### Testing - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) - `test/jdk/java/lang/template/StringTemplateTest.java` ------------- Commit messages: - Revert "8315033: Problemlist java/lang/template/StringTemplateTest.java" - Revert "8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index))" Changes: https://git.openjdk.org/jdk/pull/15442/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15442&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315029 Stats: 116 lines in 5 files changed: 9 ins; 90 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/15442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15442/head:pull/15442 PR: https://git.openjdk.org/jdk/pull/15442 From chagedorn at openjdk.org Mon Aug 28 09:10:38 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 28 Aug 2023 09:10:38 GMT Subject: RFR: 8315029: [BACKOUT] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 08:19:08 GMT, Roberto Casta?eda Lozano wrote: > This changeset backs out the changes introduced by [JDK-8312749](https://bugs.openjdk.org/browse/JDK-8312749) and re-enables the problem-listed `test/jdk/java/lang/template/StringTemplateTest.java`. The backed-out issue will be re-addressed in [JDK-8315082](https://bugs.openjdk.org/browse/JDK-8315082). > > #### Testing > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - `test/jdk/java/lang/template/StringTemplateTest.java` Looks good and trivial. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15442#pullrequestreview-1597781166 From vkempik at openjdk.org Mon Aug 28 09:18:15 2023 From: vkempik at openjdk.org (Vladimir Kempik) Date: Mon, 28 Aug 2023 09:18:15 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v2] In-Reply-To: References: Message-ID: On Thu, 17 Aug 2023 07:07:17 GMT, Fei Yang wrote: >> Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: >> >> Change fsgnj_d(dst, src, src) to fmv_d(dst, src) > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4258: > >> 4256: >> 4257: // setting roundig mode to double->long (rm_direct) and long->double (rm_back) conversions >> 4258: RoundingMode rm_direct, rm_back; > > Can we use the same rounding mode for conversions in both direction? Say `rup` for `ceil`, and `rdn` for `floor`. > I see this policy is used for both glibc [1] and V8. > > [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/riscv/rv64/rvd/s_ceil.c;h=6c355cd72691c45c97201fe8947683287982ade9;hb=41d8c3bc33bcae1ebb8077b0442caef4917f763a basically for this case the backward rounding mode doesn't matter at all. it would only matter if intermediate integer contained something not representable in double. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1307167492 From duke at openjdk.org Mon Aug 28 09:49:24 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Mon, 28 Aug 2023 09:49:24 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v3] In-Reply-To: References: Message-ID: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: Fixes in double rounding intrinsic Use similar converting mode instead of different. Change pipe_class to default and remove effecr on cr. Indentation fixes, variables renaming, add more comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/1c43b040..47a7fb2b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=01-02 Stats: 45 lines in 3 files changed: 6 ins; 13 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From mdoerr at openjdk.org Mon Aug 28 09:55:08 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 28 Aug 2023 09:55:08 GMT Subject: RFR: 8315029: [BACKOUT] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 08:19:08 GMT, Roberto Casta?eda Lozano wrote: > This changeset backs out the changes introduced by [JDK-8312749](https://bugs.openjdk.org/browse/JDK-8312749) and re-enables the problem-listed `test/jdk/java/lang/template/StringTemplateTest.java`. The backed-out issue will be re-addressed in [JDK-8315082](https://bugs.openjdk.org/browse/JDK-8315082). > > #### Testing > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - `test/jdk/java/lang/template/StringTemplateTest.java` LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15442#pullrequestreview-1597947947 From duke at openjdk.org Mon Aug 28 09:56:45 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Mon, 28 Aug 2023 09:56:45 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v4] In-Reply-To: References: Message-ID: <0AxOOGlNcodBw74WDB0a9WOE12izVxssdTzJ8NkfGy8=.bb194dad-5a06-4af9-aa71-3972a66d6df3@github.com> > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8312569 - Fixes in double rounding intrinsic Use similar converting mode instead of different. Change pipe_class to default and remove effecr on cr. Indentation fixes, variables renaming, add more comments. - Change fsgnj_d(dst, src, src) to fmv_d(dst, src) - Fix comments style - Add missing intrinsic for double rounding Add intrinsics for rounding with mode like Math.ceil/floor/rint. Improve whitespaces from previous pr. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/47a7fb2b..f4a9dd75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=02-03 Stats: 42765 lines in 1650 files changed: 23201 ins; 8068 del; 11496 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From duke at openjdk.org Mon Aug 28 10:32:55 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Mon, 28 Aug 2023 10:32:55 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v5] In-Reply-To: References: Message-ID: <8vCtVR7KyiI-3e_oaNz5IR7e2_Hzl-lQ7LxWxlD7cPs=.4a4e417b-ea95-400a-8653-db04ed041e28@github.com> > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request incrementally with three additional commits since the last revision: - Remove unused cr flag in node - Merge branch 'JDK-8312569' of github.com:Ilyagavrilin/jdk into JDK-8312569 - Move round intrinsic to c2_MacroAssembler_riscv ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/f4a9dd75..f6dd7b16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=03-04 Stats: 150 lines in 5 files changed: 63 ins; 84 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From duke at openjdk.org Mon Aug 28 11:01:48 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Mon, 28 Aug 2023 11:01:48 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v6] In-Reply-To: References: Message-ID: <4qYfHNw3G57_Mfqo6R5YNR8wwijGYZCke4_VwxNNsOI=.d3a3844a-781b-444f-8de6-4e3109b0d499@github.com> > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: Fix whitespaces in c2_MacroAssembler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/f6dd7b16..492fb25c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From azafari at openjdk.org Mon Aug 28 11:03:51 2023 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 28 Aug 2023 11:03:51 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v3] In-Reply-To: References: Message-ID: > The `find` method now is > ```C++ > template > int find(T* token, bool f(T*, E)) const { > ... > > Any other functions which use this are also changed. > Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: find_from_end and its caller are also updated. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15418/files - new: https://git.openjdk.org/jdk/pull/15418/files/f46cba87..266f6feb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15418&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15418&range=01-02 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15418.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15418/head:pull/15418 PR: https://git.openjdk.org/jdk/pull/15418 From rcastanedalo at openjdk.org Mon Aug 28 11:11:18 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 28 Aug 2023 11:11:18 GMT Subject: RFR: 8315029: [BACKOUT] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) In-Reply-To: References: Message-ID: <9w4H96MohjsxLU5FEk9YK4J1Ruwg-9cbJsGfvHREB3c=.a510cb4b-5372-450b-81fa-58afdd57417d@github.com> On Mon, 28 Aug 2023 08:19:08 GMT, Roberto Casta?eda Lozano wrote: > This changeset backs out the changes introduced by [JDK-8312749](https://bugs.openjdk.org/browse/JDK-8312749) and re-enables the problem-listed `test/jdk/java/lang/template/StringTemplateTest.java`. The backed-out issue will be re-addressed in [JDK-8315082](https://bugs.openjdk.org/browse/JDK-8315082). > > #### Testing > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - `test/jdk/java/lang/template/StringTemplateTest.java` Thanks Christian and Martin! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15442#issuecomment-1695499123 From rcastanedalo at openjdk.org Mon Aug 28 11:11:19 2023 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 28 Aug 2023 11:11:19 GMT Subject: Integrated: 8315029: [BACKOUT] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 08:19:08 GMT, Roberto Casta?eda Lozano wrote: > This changeset backs out the changes introduced by [JDK-8312749](https://bugs.openjdk.org/browse/JDK-8312749) and re-enables the problem-listed `test/jdk/java/lang/template/StringTemplateTest.java`. The backed-out issue will be re-addressed in [JDK-8315082](https://bugs.openjdk.org/browse/JDK-8315082). > > #### Testing > > - tier1-3 (windows-x64, linux-x64, linux-aarch64, macosx-x64, and macosx-aarch64) > - `test/jdk/java/lang/template/StringTemplateTest.java` This pull request has now been integrated. Changeset: 1c3177ee Author: Roberto Casta?eda Lozano URL: https://git.openjdk.org/jdk/commit/1c3177eea74263d8edd7e90ecb962180ea587a9b Stats: 116 lines in 5 files changed: 9 ins; 90 del; 17 mod 8315029: [BACKOUT] Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index)) Reviewed-by: chagedorn, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/15442 From eosterlund at openjdk.org Mon Aug 28 11:19:13 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 28 Aug 2023 11:19:13 GMT Subject: RFR: 8310239: Add missing cross modifying fence in nmethod entry barriers [v2] In-Reply-To: References: Message-ID: On Tue, 8 Aug 2023 22:28:09 GMT, Dean Long wrote: > At first glance, this seems like an optimization to me, and not a correctness issue. At worst, we continue to execute the stale compare and go through the slow path unnecessarily. I don't think we are violating AMD APM, at least for the compare for the entry barrier. However, there may be a problem if what that barrier is protecting, the nmethod code, was patched in a way that is not concurrent-execution-safe. If that is the case, or just to be safe, then executing a serializing instruction seems like a good idea. But we don't do that for all threads. For any thread that sees the patched instruction, we will just take the fast path and not executed the serializing instruction. Does visibility of the patched entry point instruction as code imply all patching to the nmethod is also visible, as both data and instructions? I'm not convinced it does. Unfortunately, it is not just an optimization. For example, ZGC has always patched code oop relocations in the nmethod entry barriers on x86_64, which is guarded by the nmethod entry barrier. The assumption is that if the nmethod immediate oops are patched first, and the guard value (immediate of the cmp instruction) is patched after, then if a thread sees the new cmp instruction, it will also see the new oop immediates. And that is indeed what the "asynchronous" cross modifying code description ensures will work in the AMD APM. So that all checks out. What doesn't check out though unfortunately, is when the opposite happens and we see the old compare value, and we take a slow path. After the slow path has executed, we don't re-execute the guarding cmp instruction. Instead we enter the nmethod, assuming that surely that should be safe after taking the slow path. But as the cmp isn't re-executed, this slow path code only uses *data* to communicate that the guard value has been updated. That is precisely what is described as "synchronous" cross modifying code in the AMD APM. Another thread could have *just* flipped that data to look fine concurrently. We load some the data that signals that the code has been updated, and then need to either fall back and re-execute the cmp to guard the code with the asynchronous behaviour, or issue a cross-modifying code fence, to ensure that the patched oop immediates become visible. In summary, the fast-path is asynchronous cross-modifying code, and it's fine without the fence. But the slow path uses synchronous cross-modifying code, but without correctly using cross modification fence, which is required for correctness. Now, this problem becomes bigger with generational ZGC, because we patch more things than just oop immediates, but the principle and problem is precisely the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14543#issuecomment-1695511290 From eosterlund at openjdk.org Mon Aug 28 11:22:09 2023 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 28 Aug 2023 11:22:09 GMT Subject: RFR: 8310239: Add missing cross modifying fence in nmethod entry barriers [v2] In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 00:15:00 GMT, Andrew Haley wrote: > Do we need an ISB on AArch64-specifc code? There, the guard value is data, not an immediate field. > In other words, what instruction has just been patched that we need to make visible? On AArch64 we only use synchronous cross-modifying code, we just hide the expensive in slow paths using a epoch trick that proves that most executions don't need a fence. So that should all be fine. Sometimes I wonder if we should use that trick on x86_64 as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14543#issuecomment-1695515725 From bulasevich at openjdk.org Mon Aug 28 13:14:42 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 28 Aug 2023 13:14:42 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v9] In-Reply-To: References: Message-ID: > This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 > > The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. > > InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: > > > Cortex-A53 (Pi 3 Model B Rev 1.2) > > test1stInt2Types 37.5 37.358 0.38 > test1stInt3Types 160.166 148.04 8.19 > test1stInt5Types 158.131 147.955 6.88 > test2ndInt2Types 52.634 53.291 -1.23 > test2ndInt3Types 201.39 181.603 10.90 > test2ndInt5Types 195.722 176.707 10.76 > testIfaceCall 157.453 140.498 12.07 > testIfaceExtCall 175.46 154.351 13.68 > testMonomorphic 32.052 32.039 0.04 > AVG: 6.85 > > Cortex-A72 (Pi 4 Model B Rev 1.2) > > test1stInt2Types 27.4796 27.4738 0.02 > test1stInt3Types 66.0085 64.9374 1.65 > test1stInt5Types 67.9812 66.2316 2.64 > test2ndInt2Types 32.0581 32.062 -0.01 > test2ndInt3Types 68.2715 65.6643 3.97 > test2ndInt5Types 68.1012 65.8024 3.49 > testIfaceCall 64.0684 64.1811 -0.18 > testIfaceExtCall 91.6226 81.5867 12.30 > testMonomorphic 26.7161 26.7142 0.01 > AVG: 2.66 > > Neoverse N1 (m6g.metal) > > test1stInt2Types 2.9104 2.9086 0.06 > test1stInt3Types 10.9642 10.2909 6.54 > test1stInt5Types 10.9607 10.2856 6.56 > test2ndInt2Types 3.3410 3.3478 -0.20 > test2ndInt3Types 12.3291 11.3089 9.02 > test2ndInt5Types 12.328 11.2704 9.38 > testIfaceCall 11.0598 10.3657 6.70 > testIfaceExtCall 13.0692 11.2826 15.84 > testMonomorphic 2.2354 2.2341 0.06 > AVG: 6.00 > > Neoverse V1 (c7g.2xlarge) > > test1stInt2Types 2.2317 2.2320 -0.01 > test1stInt3Types 6.6884 6.1911 8.03 > test1stInt5Types 6.7334 6.2193 8.27 > test2ndInt2Types 2.4002 2.4013 -0.04 > test2ndInt3Types 7.9603 7.0372 13.12 > test2ndInt5Types 7.9532 7.0474 12.85 > testIfaceCall 6.7028 6.3272 5.94 > testIfaceExtCall 8.3253 6.9416 19.93 > testMonomorphic 1.2446 1.2544 -0.79 > AVG: 7.48 > > > Testing... Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: adding guarantee and comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13792/files - new: https://git.openjdk.org/jdk/pull/13792/files/dd0051f1..83b79815 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=07-08 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13792/head:pull/13792 PR: https://git.openjdk.org/jdk/pull/13792 From bulasevich at openjdk.org Mon Aug 28 13:14:43 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 28 Aug 2023 13:14:43 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: <6uzMwY-W9EcvC1gi7S9Zchv-dNDa3d001Ilq9wA-rDI=.9c238ea2-e1f7-4b36-a359-b3c048f706af@github.com> On Sat, 26 Aug 2023 20:51:26 GMT, Evgeny Astigeevich wrote: >> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Comments applied: get rid of temp_reg3; replace the magic constants > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1297: > >> 1295: bind(L_holder_found); >> 1296: ldrw(method_result, Address(scan_temp, ooffset - ioffset)); >> 1297: add(recv_klass, recv_klass, (itable_index << LogBytesPerWord) + in_bytes(itableMethodEntry::method_offset()) - vtable_start_offset - ioffset); > > Maybe use `itable_index * wordSize` instead of `itable_index << LogBytesPerWord` to look the same as in the x86 variant of `lookup_interface_method_stub`. > Also a comment that `- vtable_start_offset - ioffset` is used to restore the original value of `recv_klass` would be useful. Ok. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1307404253 From bulasevich at openjdk.org Mon Aug 28 13:44:20 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 28 Aug 2023 13:44:20 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: On Sat, 26 Aug 2023 20:38:58 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1231: >> >>> 1229: // itableOffsetEntry[] itable = recv_klass + Klass::vtable_start_offset() + sizeof(vtableEntry) * recv_klass->_vtable_len; >>> 1230: // temp_itbl_klass = itable[0]._interface; >>> 1231: ldr(temp_itbl_klass, Address(recv_klass, scan_temp, Address::lsl(exact_log2(vtableEntry::size_in_bytes())))); >> >> The lsl shift in `ldr` must be 3. >> Can we have a static assert checking that? There is an assert in `Address::encode` which will catch the issue in debug builds. As `vtableEntry::size_in_bytes()` is statically known we can catch the issue during compilation. > > I'm very surprised that isn't a guarantee. I had to look to be sure. I'd simply change `assert(ext().shift() <= 0 || ext().shift() == (int)size, "bad shift");` to a `guarantee`. I want to avoid modifying the assembler_aarch64.hpp file within this change, so I add guarantee in lookup_interface_method. By the way, [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp) contains 100+ assert calls and 34 guarantee calls. I think more cases can be changed, although I am not sure what the rule is for using this or that call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1307442927 From duke at openjdk.org Mon Aug 28 14:04:10 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Mon, 28 Aug 2023 14:04:10 GMT Subject: RFR: JDK-8314901: AES-GCM interleaved implementation using AVX2 instructions In-Reply-To: References: Message-ID: On Sat, 26 Aug 2023 00:15:44 GMT, Anthony Scarpino wrote: > I'm curious in the Java code, why an encryption boolean was needed for this change but wasn't needed for the AVX512 changes. It is the other way around, the java code accesses the class' "encrypt" variable easily, but it was easier to add it as an argument for the intrinsic. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15410#issuecomment-1695755375 From duke at openjdk.org Mon Aug 28 14:29:47 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Mon, 28 Aug 2023 14:29:47 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v7] In-Reply-To: References: Message-ID: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: Fix intrinsic round_node parameter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/492fb25c..82b5e593 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=05-06 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From simonis at openjdk.org Mon Aug 28 14:50:14 2023 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 28 Aug 2023 14:50:14 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would hav... > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo Hi Mandy, thanks for doing this experiment. I've looked at your proposal, but I can't see how it can help to fix [JDK-8311500](https://bugs.openjdk.org/browse/JDK-8311500). Your change proposes to add a bunch of new Java SE specific changes which can't be downported to any previous JDK version but [JDK-8311500](https://bugs.openjdk.org/browse/JDK-8311500) affects JDK 11, 17 and 21. I'd therefore still appreciate if we could fix [JDK-8311500](https://bugs.openjdk.org/browse/JDK-8311500) first before we start to redesign the public StackWalker API. In case you do redesign the `StackWalker` API, I fully agree with @bchristi-git that the current version is overkill. As your [specdiff](https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html) shows, it introduces 34 API changes (9 additions and 18 changes) with no clear benefit. I second @bchristi-git that an addtional `StackWalker.Option` would be simpler and much cleaner (I'd vote for `SKIP_METHOD_INFO`) if we decide to change the API at all.. Another point that should be taken into account when we start to redesign the StackWalker API is its interaction with the `-XX:+ShowHiddenFrames` command line parameter. This is currently not specified and can lead to surprising results (see e.g. [this remark about failing JTreg tests with `-XX:+ShowHiddenFrames`](https://github.com/openjdk/jdk/pull/14773#issuecomment-1631065562)). I'm also not convinced that doing frame filtering in Java is the right thing to do. If we have to call into the JVM anyway, I think it would be more natural to let the JVM do as much of the work as possible. To me it seems as if your change is mostly about improving the performance of stack walks and I think this could be achieved to an even greater extent without the need to change the public API, simply by improving the implementation. Such improvements could than also be downported to JDK 17 & 21 which isn't possible with your approach. If it turns out that API changes are required in order to achieve superior performance, we should try to keep them to a minimum and weight them against the performance benefits. E.g. we could add a single `getCallerClass(int depth)` method which would provide all the benefits of `Kind.CLASS_INFO` but with considerably less API changes. ------------- PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1598457114 From dfuchs at openjdk.org Mon Aug 28 15:30:23 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 28 Aug 2023 15:30:23 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would hav... > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo As far as I understand the point of this change is to provide a new API that will allow a caller to request class information only, thus improving performance when only class information is required. Whether we use a new enum or a new option constant, we will need changes to the API documentation. If we use a new option constant we won't need any new static factory methods though. Whether filtering is performed in java or in native is orthogonal to that. The trend these days is to do as much as possible in java, and the patch goes in that direction. There is a small price to pay if the frame to be filtered is a continuation, as this will cause the member name to be resolved. Is that significant enough to push back towards doing the filtering in native: I don't know. It may be worth investigating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1695899325 From lkorinth at openjdk.org Mon Aug 28 16:01:53 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 28 Aug 2023 16:01:53 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder Message-ID: Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: /** * Create ProcessBuilder using the java launcher from the jdk to * be tested. * *

Please observe that you likely should use * createTestJvm() instead of this method because createTestJvm() * will add JVM options from "test.vm.opts" and "test.java.opts" * and this method will not do that. * * @param command Arguments to pass to the java command. * @return The ProcessBuilder instance representing the java command. */ I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... I have run tier 1 testing, and I have started more exhaustive testing. ------------- Commit messages: - 8315097: Rename createJavaProcessBuilder Changes: https://git.openjdk.org/jdk/pull/15452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315097 Stats: 756 lines in 462 files changed: 22 ins; 10 del; 724 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From sviswanathan at openjdk.org Mon Aug 28 17:29:11 2023 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 28 Aug 2023 17:29:11 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v3] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 23:17:00 GMT, Scott Gibbons wrote: >> Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. >> >> UPDATE: Subsequent commits increase performance gain to ~2x for AVX2, with no significant change to AVX512. >> >> Tested tier1. > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > mxcsr fix; address review comments The PR looks good to me. Thanks for considering all the review comments. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15210#pullrequestreview-1598735303 From mchung at openjdk.org Mon Aug 28 18:19:12 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 28 Aug 2023 18:19:12 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6] In-Reply-To: References: Message-ID: <8oljuTbN4vzVwFxUy0fqWeYOiLRK6A3klSx-UAvQ-is=.04a40a0f-1178-4348-a4b7-9f1e173197e1@github.com> On Mon, 28 Aug 2023 14:47:20 GMT, Volker Simonis wrote: > thanks for doing this experiment. I've looked at your proposal, but I can't see how it can help to fix [JDK-8311500](https://bugs.openjdk.org/browse/JDK-8311500)..... I think you may be confused. This PR can be viewed as follows: 1. introduce a new API to allow walking the stack with no method information and the implementation will use `ClassFrameInfo` buffer 2. reduce the memory footprint of `StackFrameInfo` buffer 3. change `getCallerClass` to use the `ClassFrameInfo` buffer 4. fix JDK-8311500 by checking if a method is caller-sensitive in Java. Note that the filtering of reflection frames has been done in Java. #2-4 can be backport to older releases. #2 improve the StackWalker performance. Backporting the PR should be straight-forward by excluding the API and javadoc change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1696134958 From mchung at openjdk.org Mon Aug 28 18:33:12 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 28 Aug 2023 18:33:12 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v6] In-Reply-To: References: Message-ID: On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker >> collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used >> instead and such stack walker will save the overhead (1) to extract the method information >> and (2) the memory used for the stack walking. In addition, this can also fix >> >> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: >> >> >> StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(interestingClasses::contains) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would hav... > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - fixup javadoc > - Review feedback: move JLIA to ClassFrameInfo Thank you all for the feedback on the API. I discussed with @AlanBateman and @RogerRiggs offline. Alan suggests an option to drop that would work well (`Lookup::dropLookupMode` is a precedent). I like the suggested name `DROP_METHOD_INFO`. | Option | getDeclaringClass | class name | method info | | ------- | ------------------ | ----------- | ------------ | | | N | Y | Y | | `RETAIN_CLASS_REFERENCE` | Y | Y | Y | | `DROP_METHOD_INFO` | N | Y | N | | `RETAIN_CLASS_REFERENCE, DROP_METHOD_INFO` | Y | Y | N | ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1696152180 From lmesnik at openjdk.org Mon Aug 28 19:06:11 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 28 Aug 2023 19:06:11 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth wrote: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. The. changes looks good. Please update copyrights for changed filed. I expect that you completed execution of all tests to ensure that nothing is broken. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1598884378 From iklam at openjdk.org Mon Aug 28 21:19:17 2023 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 28 Aug 2023 21:19:17 GMT Subject: RFR: 8308464: Shared array class should not always be loaded in boot loader In-Reply-To: References: Message-ID: <6SIyiLmsiR2GlFhb5SpUa8Zem5Lkh-SKn3-G_pjpBQo=.f149f9bd-90bf-4aeb-90de-1a0215785e84@github.com> On Thu, 24 Aug 2023 19:35:25 GMT, Calvin Cheung wrote: > Please review this fix for using the appropriate class loader when loading a shared array class. The log output from -`Xlog:cds+unshareable=trace` is also updated to include the class loader information. > > For example: > before: > `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp` > > after: > `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp with class loader: jdk.internal.loader.ClassLoaders$AppClassLoader` > > Passed tiers 1- 3 tests. LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15421#pullrequestreview-1599139991 From ccheung at openjdk.org Mon Aug 28 22:08:15 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 28 Aug 2023 22:08:15 GMT Subject: RFR: 8308464: Shared array class should not always be loaded in boot loader In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 01:07:40 GMT, David Holmes wrote: >> Please review this fix for using the appropriate class loader when loading a shared array class. The log output from -`Xlog:cds+unshareable=trace` is also updated to include the class loader information. >> >> For example: >> before: >> `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp` >> >> after: >> `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp with class loader: jdk.internal.loader.ClassLoaders$AppClassLoader` >> >> Passed tiers 1- 3 tests. > > LGTM. Thanks. Thanks @dholmes-ora, @iklam for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/15421#issuecomment-1696489739 From ccheung at openjdk.org Mon Aug 28 22:08:17 2023 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 28 Aug 2023 22:08:17 GMT Subject: Integrated: 8308464: Shared array class should not always be loaded in boot loader In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 19:35:25 GMT, Calvin Cheung wrote: > Please review this fix for using the appropriate class loader when loading a shared array class. The log output from -`Xlog:cds+unshareable=trace` is also updated to include the class loader information. > > For example: > before: > `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp` > > after: > `[0.203s][trace][cds,unshareable ] restore: ArrayKlassesApp with class loader: jdk.internal.loader.ClassLoaders$AppClassLoader` > > Passed tiers 1- 3 tests. This pull request has now been integrated. Changeset: 1cb2cc65 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/1cb2cc65873ab25f5bafeae042e3fd99be94ea7e Stats: 37 lines in 4 files changed: 22 ins; 5 del; 10 mod 8308464: Shared array class should not always be loaded in boot loader Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.org/jdk/pull/15421 From mchung at openjdk.org Tue Aug 29 00:16:40 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 29 Aug 2023 00:16:40 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker > collects. If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used > instead and such stack walker will save the overhead (1) to extract the method information > and (2) the memory used for the stack walking. In addition, this can also fix > > - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance: > > > StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(interestingClasses::contains) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Javadoc & specdiff > > https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html > https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > Another alte... Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: - Revised the API change. Add Option::DROP_METHOD_INFO - Review feedback from Remi ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/4c5c5d79..3ca53c74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=05-06 Stats: 277 lines in 10 files changed: 28 ins; 168 del; 81 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From lmesnik at openjdk.org Tue Aug 29 00:45:58 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 29 Aug 2023 00:45:58 GMT Subject: RFR: 8314835: gtest wrappers should be marked as flagless Message-ID: The gtest wrappers don't accept external vm flags and no need to run with them. ------------- Commit messages: - 8314835 Changes: https://git.openjdk.org/jdk/pull/15462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314835 Stats: 7 lines in 3 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15462/head:pull/15462 PR: https://git.openjdk.org/jdk/pull/15462 From fjiang at openjdk.org Tue Aug 29 02:56:23 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 29 Aug 2023 02:56:23 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v7] In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 14:29:47 GMT, Ilya Gavrilin wrote: >> Please review this changes into risc-v double rounding intrinsic. >> >> On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). >> >> Also, we should provide some rounding mode to fcvt.x.x instruction. >> >> Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: >> >>> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). >> >> For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. >> For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. >> >> For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). >> As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). >> >> We have observed significant improvement on hifive and thead boards. >> >> testing: tier1, tier2 and hotspot:tier3 on hifive >> >> Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): >> >> Without intrinsic: >> >> Benchmark (TESTSIZE) Mode Cnt Score Error Units >> FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms >> FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms >> FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms >> >> With intrinsic: >> >> Benchmark (TESTSIZE) Mode Cnt Score Error Units >> FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms >> FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms >> FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms > > Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: > > Fix intrinsic round_node parameter Changes requested by fjiang (Committer). src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 1381: > 1379: // handling is needed by NaN, +/-Infinity, +/-0. > 1380: void C2_MacroAssembler::round_double_mode(FloatRegister dst, FloatRegister src, int round_mode, Register tmp1, Register tmp2, Register tmp3) > 1381: { Suggestion: void C2_MacroAssembler::round_double_mode(FloatRegister dst, FloatRegister src, int round_mode, Register tmp1, Register tmp2, Register tmp3) { ------------- PR Review: https://git.openjdk.org/jdk/pull/14991#pullrequestreview-1599388699 PR Review Comment: https://git.openjdk.org/jdk/pull/14991#discussion_r1308136130 From qamai at openjdk.org Tue Aug 29 03:01:11 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 29 Aug 2023 03:01:11 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v3] In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 11:03:51 GMT, Afshin Zafari wrote: >> The `find` method now is >> ```C++ >> template >> int find(T* token, bool f(T*, E)) const { >> ... >> >> Any other functions which use this are also changed. >> Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > find_from_end and its caller are also updated. This is similar to `std::find_if` and should be just: template int find(UnaryPredicate p) const { for (int i = 0; i < _len; i++) { if (p(_data[i])) { return i; } } return -1; } Regarding the current approach, the comparator should take a `const E&` instead of an `E`, and the token passed in should be `const` also. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15418#issuecomment-1696695109 From dholmes at openjdk.org Tue Aug 29 04:07:13 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 29 Aug 2023 04:07:13 GMT Subject: RFR: 8314835: gtest wrappers should be marked as flagless In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 00:31:34 GMT, Leonid Mesnik wrote: > The gtest wrappers don't accept external vm flags and no need to run with them. Seems reasonable to avoid duplicated executions that act exactly the same. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15462#pullrequestreview-1599435712 From dholmes at openjdk.org Tue Aug 29 05:06:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 29 Aug 2023 05:06:08 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth wrote: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. I think the admonition about using this method is a bit strong in that it is natural to use this plain process builder method when a test is going to set its own specific flags for the exec'd process. But I'm okay with renaming to avoid copy'n'paste errors that accidentally use the wrong version. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1599483514 From stuefe at openjdk.org Tue Aug 29 05:25:15 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 29 Aug 2023 05:25:15 GMT Subject: RFR: 8314835: gtest wrappers should be marked as flagless In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 00:31:34 GMT, Leonid Mesnik wrote: > The gtest wrappers don't accept external vm flags and no need to run with them. Ok ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15462#pullrequestreview-1599498889 From sspitsyn at openjdk.org Tue Aug 29 07:07:11 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 29 Aug 2023 07:07:11 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v3] In-Reply-To: <2kgLlH__lH2LiM7VdVePqCgW8Uck-AvrO-klTB8yzq4=.66ad8590-4661-47f2-b206-5979c8dba063@github.com> References: <068Gqd9adw6k8nrLAJoEMDmbw2s3RMpV0KPmWDS0OdI=.1d8171a3-012a-425c-bea6-44f538a64106@github.com> <2kgLlH__lH2LiM7VdVePqCgW8Uck-AvrO-klTB8yzq4=.66ad8590-4661-47f2-b206-5979c8dba063@github.com> Message-ID: On Sun, 27 Aug 2023 17:03:00 GMT, Kim Barrett wrote: >> Not a review, just agreeing with @stefank and @jdksjolen . What they describe is idiomatic C++. > > Also, why isn't this change also being applied to `find_from_end` There can be a confusion related to selection of type names T and E: T is intuitively treated as a table and E as an element. No pressure but I wonder if using D instead of T would be better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15418#discussion_r1308303916 From eastigeevich at openjdk.org Tue Aug 29 07:12:14 2023 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 29 Aug 2023 07:12:14 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 13:41:35 GMT, Boris Ulasevich wrote: > By the way, [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp) contains 100+ assert calls and 34 guarantee calls. I think more cases can be changed, although I am not sure what the rule is for using this or that call. A JBS issue? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1308308257 From duke at openjdk.org Tue Aug 29 07:58:48 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Tue, 29 Aug 2023 07:58:48 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v8] In-Reply-To: References: Message-ID: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp Co-authored-by: Feilong Jiang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/82b5e593..6216e38f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From duke at openjdk.org Tue Aug 29 08:09:50 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Tue, 29 Aug 2023 08:09:50 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v9] In-Reply-To: References: Message-ID: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: Fix typo in c2_MacroAssembler_riscv.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/6216e38f..16900449 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From stuefe at openjdk.org Tue Aug 29 08:10:25 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 29 Aug 2023 08:10:25 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v2] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 06:22:57 GMT, Thomas Stuefe wrote: >> Small change that reduces the number of loads generated by the C++ compiler for a narrow Klass decoding operation (`CompressedKlassPointers::decode_xxx()`. >> >> Stock: three loads (with two probably sharing a cache line) - UseCompressedClassPointers, encoding base and shift. >> >> >> 8b7b62: 48 8d 05 7f 1b c3 00 lea 0xc31b7f(%rip),%rax # 14e96e8 >> 8b7b69: 0f b6 00 movzbl (%rax),%eax >> 8b7b6c: 84 c0 test %al,%al >> 8b7b6e: 0f 84 9c 00 00 00 je 8b7c10 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> >> 8b7b74: 48 8d 15 05 62 c6 00 lea 0xc66205(%rip),%rdx # 151dd80 <_ZN23CompressedKlassPointers6_shiftE> >> 8b7b7b: 8b 7b 08 mov 0x8(%rbx),%edi >> 8b7b7e: 8b 0a mov (%rdx),%ecx >> 8b7b80: 48 8d 15 01 62 c6 00 lea 0xc66201(%rip),%rdx # 151dd88 <_ZN23CompressedKlassPointers5_baseE> >> 8b7b87: 48 d3 e7 shl %cl,%rdi >> 8b7b8a: 48 03 3a add (%rdx),%rdi >> >> >> Patched: one load loads all three. Since shift occupies the lowest 8 bits, compiled code uses 8bit register; ditto the UseCompressedOops flag. >> >> >> 8ba302: 48 8d 05 97 9c c2 00 lea 0xc29c97(%rip),%rax # 14e3fa0 <_ZN23CompressedKlassPointers6_comboE> >> 8ba309: 48 8b 08 mov (%rax),%rcx >> 8ba30c: f6 c5 01 test $0x1,%ch # use compressed klass pointers? >> 8ba30f: 0f 84 9b 00 00 00 je 8ba3b0 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> >> 8ba315: 8b 7b 08 mov 0x8(%rbx),%edi >> 8ba318: 48 d3 e7 shl %cl,%rdi # shift >> 8ba31b: 66 31 c9 xor %cx,%cx # zero out lower 16 bits of base >> 8ba31e: 48 01 cf add %rcx,%rdi # add base >> 8ba321: 8b 4f 08 mov 0x8(%rdi),%ecx >> >> --- >> >> Performance measurements: >> >> G1, doing a full GC over a heap filled with 256 mio life j.l.Object instances. >> >> I see a reduction of Full Pause times between 1.2% and 5%. I am unsure how reliable these numbers are since, despite my efforts (running tests on isolated CPUs etc.), the standard deviation was quite high at ?4%. Still, in general, numbers seemed to go down rather than up. >> >> --- >> >> Future extensions: >> >> This patch uses the fact that the encoding base is aligned to metaspace reser... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix -UseCCP case Friendly ping. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15389#issuecomment-1696967190 From duke at openjdk.org Tue Aug 29 08:28:42 2023 From: duke at openjdk.org (Ilya Gavrilin) Date: Tue, 29 Aug 2023 08:28:42 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v10] In-Reply-To: References: Message-ID: > Please review this changes into risc-v double rounding intrinsic. > > On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). > > Also, we should provide some rounding mode to fcvt.x.x instruction. > > Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: > >> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). > > For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. > For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. > > For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). > As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). > > We have observed significant improvement on hifive and thead boards. > > testing: tier1, tier2 and hotspot:tier3 on hifive > > Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): > > Without intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms > > With intrinsic: > > Benchmark (TESTSIZE) Mode Cnt Score Error Units > FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms > FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms > FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: Fix typo in c2_MacroAssembler_riscv.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14991/files - new: https://git.openjdk.org/jdk/pull/14991/files/16900449..09ad14aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14991&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14991.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14991/head:pull/14991 PR: https://git.openjdk.org/jdk/pull/14991 From aph at openjdk.org Tue Aug 29 08:47:16 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 29 Aug 2023 08:47:16 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 07:08:45 GMT, Evgeny Astigeevich wrote: >> I want to avoid modifying the assembler_aarch64.hpp file within this change, so I add guarantee in lookup_interface_method. >> By the way, [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp) contains 100+ assert calls and 34 guarantee calls. I think more cases can be changed, although I am not sure what the rule is for using this or that call. > >> By the way, [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp) contains 100+ assert calls and 34 guarantee calls. I think more cases can be changed, although I am not sure what the rule is for using this or that call. > > A JBS issue? No, I don't think so. The balance between `assert()` and `guarantee()` is a matter of judgement, not hard rules. We don't want to do consistency checking at runtime if we can avoid it, because it adds to startup time. The `guarantee()` that an operand fits into its field in an instruction has proved its worth, many times. This is because AArch64 has a variety of offset fields, and these are of varying lengths. It's very easy to be caught out, and sometimes this has happened even after release. In most other places, an `assert()` is all we need. This is because the thing being asserted doesn't vary much, and we only need to check it once, when we run a debug build. In the case of checking that the shift in a memory-access instruction matches the operand size, the check will be inlined. I haven't looked, but I expect it will be eliminated by the C++ optimizer at compile time. In the case of the ldr instruction here, the operand size is determined already by the `ldr` instruction: it's `wordSize`. It cannot be anything else. The AArch64 back end asserts that elsewhere: int vte_size = vtableEntry::size_in_bytes(); assert(vte_size == wordSize, "else adjust times_vte_scale"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1308430553 From aph at openjdk.org Tue Aug 29 09:01:12 2023 From: aph at openjdk.org (Andrew Haley) Date: Tue, 29 Aug 2023 09:01:12 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v2] In-Reply-To: References: Message-ID: <93z71DGGirsYas6wK1AONieodxH3f72N9Os1juZLo3I=.a2313074-c2b3-4f22-acf4-8cd6966a38fb@github.com> On Thu, 24 Aug 2023 06:22:57 GMT, Thomas Stuefe wrote: >> Small change that reduces the number of loads generated by the C++ compiler for a narrow Klass decoding operation (`CompressedKlassPointers::decode_xxx()`. >> >> Stock: three loads (with two probably sharing a cache line) - UseCompressedClassPointers, encoding base and shift. >> >> >> 8b7b62: 48 8d 05 7f 1b c3 00 lea 0xc31b7f(%rip),%rax # 14e96e8 >> 8b7b69: 0f b6 00 movzbl (%rax),%eax >> 8b7b6c: 84 c0 test %al,%al >> 8b7b6e: 0f 84 9c 00 00 00 je 8b7c10 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> >> 8b7b74: 48 8d 15 05 62 c6 00 lea 0xc66205(%rip),%rdx # 151dd80 <_ZN23CompressedKlassPointers6_shiftE> >> 8b7b7b: 8b 7b 08 mov 0x8(%rbx),%edi >> 8b7b7e: 8b 0a mov (%rdx),%ecx >> 8b7b80: 48 8d 15 01 62 c6 00 lea 0xc66201(%rip),%rdx # 151dd88 <_ZN23CompressedKlassPointers5_baseE> >> 8b7b87: 48 d3 e7 shl %cl,%rdi >> 8b7b8a: 48 03 3a add (%rdx),%rdi >> >> >> Patched: one load loads all three. Since shift occupies the lowest 8 bits, compiled code uses 8bit register; ditto the UseCompressedOops flag. >> >> >> 8ba302: 48 8d 05 97 9c c2 00 lea 0xc29c97(%rip),%rax # 14e3fa0 <_ZN23CompressedKlassPointers6_comboE> >> 8ba309: 48 8b 08 mov (%rax),%rcx >> 8ba30c: f6 c5 01 test $0x1,%ch # use compressed klass pointers? >> 8ba30f: 0f 84 9b 00 00 00 je 8ba3b0 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> >> 8ba315: 8b 7b 08 mov 0x8(%rbx),%edi >> 8ba318: 48 d3 e7 shl %cl,%rdi # shift >> 8ba31b: 66 31 c9 xor %cx,%cx # zero out lower 16 bits of base >> 8ba31e: 48 01 cf add %rcx,%rdi # add base >> 8ba321: 8b 4f 08 mov 0x8(%rdi),%ecx >> >> --- >> >> Performance measurements: >> >> G1, doing a full GC over a heap filled with 256 mio life j.l.Object instances. >> >> I see a reduction of Full Pause times between 1.2% and 5%. I am unsure how reliable these numbers are since, despite my efforts (running tests on isolated CPUs etc.), the standard deviation was quite high at ?4%. Still, in general, numbers seemed to go down rather than up. >> >> --- >> >> Future extensions: >> >> This patch uses the fact that the encoding base is aligned to metaspace reser... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix -UseCCP case src/hotspot/share/oops/compressedKlass.hpp line 74: > 72: static constexpr int bitpos_useccp = shift_bitlen; > 73: static address base_from_combo() { return (address)(_combo & mask_base); } > 74: static int shift_from_combo() { return (int)(_combo & right_n_bits(shift_bitlen)); } Suggestion: static int shift() { return (int)(_combo & right_n_bits(shift_bitlen)); } What's the point of the `_from_combo` functions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15389#discussion_r1308447308 From tschatzl at openjdk.org Tue Aug 29 09:10:18 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 29 Aug 2023 09:10:18 GMT Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion In-Reply-To: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Message-ID: On Mon, 21 Aug 2023 12:25:12 GMT, Albert Mingkun Yang wrote: > Use unsigned type for heap-region-size related shifts in HeapRegion. > > Test: tier1-3 Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp line 161: > 159: __ move(xor_res, xor_shift_res); > 160: __ unsigned_shift_right(xor_shift_res, > 161: LIR_OprFact::intConst(static_cast(HeapRegion::LogOfHRGrainBytes)), One could maybe argue that this should be a `checked_cast`, but given that the value bounds are known there is no point... src/hotspot/share/gc/g1/g1Arguments.cpp line 137: > 135: uint region_size_log_mb = HeapRegion::LogOfHRGrainBytes > LOG_M > 136: ? HeapRegion::LogOfHRGrainBytes - LOG_M > 137: : 0; I would just assert that `HeapRegion::LogOfHRGrainBytes >= LOG_M` here. People messing with with minimum region size would need to check this code anyway. Further, `LOG_M` should probably be calculated as `log2_exact(HeapRegion::min_size())` instead of using the constant directly (and renamed appropriately, something like `Log[Of]MinHeapRegionSize/GrainBytes`). Then there would be no need to do the maximum calculation (my original suggestion would have been `MAX2(HeapRegion::LogOfHRGrainBytes - LOG_M, 0u)` btw) src/hotspot/share/gc/g1/g1Arguments.cpp line 140: > 138: > 139: if (FLAG_IS_DEFAULT(G1RemSetArrayOfCardsEntries)) { > 140: uint max_cards_in_inline_ptr = G1CardSetConfiguration::max_cards_in_inline_ptr(HeapRegion::LogCardsPerRegion); Not sure how this change has anything to do with -Wconversion, but okay :) src/hotspot/share/gc/g1/g1CardTable.inline.hpp line 34: > 32: inline uint G1CardTable::region_idx_for(CardValue* p) { > 33: size_t const card_idx = pointer_delta(p, _byte_map, sizeof(CardValue)); > 34: return (uint)(card_idx >> HeapRegion::LogCardsPerRegion); Not sure how this change has anything to do with -Wconversion but okay :) src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 820: > 818: > 819: #define VM_STRUCTS_JVMCI_G1GC(nonstatic_field, static_field) \ > 820: static_field(HeapRegion, LogOfHRGrainBytes, uint32_t) Suggestion: static_field(HeapRegion, LogOfHRGrainBytes, uint) Seems to compile just fine here. ------------- PR Review: https://git.openjdk.org/jdk/pull/15360#pullrequestreview-1599784043 PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308457638 PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308395646 PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308396907 PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308396990 PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308423061 From lkorinth at openjdk.org Tue Aug 29 09:12:51 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 29 Aug 2023 09:12:51 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15452/files - new: https://git.openjdk.org/jdk/pull/15452/files/4b2d1711..f3418c80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=00-01 Stats: 344 lines in 344 files changed: 0 ins; 0 del; 344 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From ayang at openjdk.org Tue Aug 29 09:23:10 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 29 Aug 2023 09:23:10 GMT Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion In-Reply-To: References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Message-ID: On Tue, 29 Aug 2023 08:38:36 GMT, Thomas Schatzl wrote: >> Use unsigned type for heap-region-size related shifts in HeapRegion. >> >> Test: tier1-3 > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 820: > >> 818: >> 819: #define VM_STRUCTS_JVMCI_G1GC(nonstatic_field, static_field) \ >> 820: static_field(HeapRegion, LogOfHRGrainBytes, uint32_t) > > Suggestion: > > static_field(HeapRegion, LogOfHRGrainBytes, uint) > > > Seems to compile just fine here. That was my original attempt, but JVMCI related tests failed with `uint`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308475030 From jsjolen at openjdk.org Tue Aug 29 09:33:11 2023 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 29 Aug 2023 09:33:11 GMT Subject: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v3] In-Reply-To: References: Message-ID: On Mon, 28 Aug 2023 11:03:51 GMT, Afshin Zafari wrote: >> The `find` method now is >> ```C++ >> template >> int find(T* token, bool f(T*, E)) const { >> ... >> >> Any other functions which use this are also changed. >> Local linux-x64-debug hotspot:tier1 passed. Mach5 tier1 build on linux and Windows passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > find_from_end and its caller are also updated. I still approve of this patch as it's better than what we had before. There are a lot of suggested improvements that can be done either in this PR or in a future RFE. `git blame` shows that this hasn't been touched since 2008, so I don't think applying all suggestions now is in any sense critical :-). ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15418#pullrequestreview-1599922400 From stuefe at openjdk.org Tue Aug 29 09:47:10 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 29 Aug 2023 09:47:10 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v2] In-Reply-To: <93z71DGGirsYas6wK1AONieodxH3f72N9Os1juZLo3I=.a2313074-c2b3-4f22-acf4-8cd6966a38fb@github.com> References: <93z71DGGirsYas6wK1AONieodxH3f72N9Os1juZLo3I=.a2313074-c2b3-4f22-acf4-8cd6966a38fb@github.com> Message-ID: On Tue, 29 Aug 2023 08:57:56 GMT, Andrew Haley wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> fix -UseCCP case > > src/hotspot/share/oops/compressedKlass.hpp line 74: > >> 72: static constexpr int bitpos_useccp = shift_bitlen; >> 73: static address base_from_combo() { return (address)(_combo & mask_base); } >> 74: static int shift_from_combo() { return (int)(_combo & right_n_bits(shift_bitlen)); } > > Suggestion: > > static int shift() { return (int)(_combo & right_n_bits(shift_bitlen)); } > > > What's the point of the `_from_combo` functions? They are only used when asserting correctness after initialization. But you are right, I could use `base()` directly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15389#discussion_r1308506525 From stuefe at openjdk.org Tue Aug 29 10:14:26 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 29 Aug 2023 10:14:26 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v3] In-Reply-To: References: Message-ID: > Small change that reduces the number of loads generated by the C++ compiler for a narrow Klass decoding operation (`CompressedKlassPointers::decode_xxx()`. > > Stock: three loads (with two probably sharing a cache line) - UseCompressedClassPointers, encoding base and shift. > > > 8b7b62: 48 8d 05 7f 1b c3 00 lea 0xc31b7f(%rip),%rax # 14e96e8 > 8b7b69: 0f b6 00 movzbl (%rax),%eax > 8b7b6c: 84 c0 test %al,%al > 8b7b6e: 0f 84 9c 00 00 00 je 8b7c10 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> > 8b7b74: 48 8d 15 05 62 c6 00 lea 0xc66205(%rip),%rdx # 151dd80 <_ZN23CompressedKlassPointers6_shiftE> > 8b7b7b: 8b 7b 08 mov 0x8(%rbx),%edi > 8b7b7e: 8b 0a mov (%rdx),%ecx > 8b7b80: 48 8d 15 01 62 c6 00 lea 0xc66201(%rip),%rdx # 151dd88 <_ZN23CompressedKlassPointers5_baseE> > 8b7b87: 48 d3 e7 shl %cl,%rdi > 8b7b8a: 48 03 3a add (%rdx),%rdi > > > Patched: one load loads all three. Since shift occupies the lowest 8 bits, compiled code uses 8bit register; ditto the UseCompressedOops flag. > > > 8ba302: 48 8d 05 97 9c c2 00 lea 0xc29c97(%rip),%rax # 14e3fa0 <_ZN23CompressedKlassPointers6_comboE> > 8ba309: 48 8b 08 mov (%rax),%rcx > 8ba30c: f6 c5 01 test $0x1,%ch # use compressed klass pointers? > 8ba30f: 0f 84 9b 00 00 00 je 8ba3b0 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> > 8ba315: 8b 7b 08 mov 0x8(%rbx),%edi > 8ba318: 48 d3 e7 shl %cl,%rdi # shift > 8ba31b: 66 31 c9 xor %cx,%cx # zero out lower 16 bits of base > 8ba31e: 48 01 cf add %rcx,%rdi # add base > 8ba321: 8b 4f 08 mov 0x8(%rdi),%ecx > > --- > > Performance measurements: > > G1, doing a full GC over a heap filled with 256 mio life j.l.Object instances. > > I see a reduction of Full Pause times between 1.2% and 5%. I am unsure how reliable these numbers are since, despite my efforts (running tests on isolated CPUs etc.), the standard deviation was quite high at ?4%. Still, in general, numbers seemed to go down rather than up. > > --- > > Future extensions: > > This patch uses the fact that the encoding base is aligned to metaspace reserve alignment (16 Mb). We only use 16 of those 24 bits of alignment shadow and could us... 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: - APH feedback - Merge branch 'master' into optimize-narrow-klass-decoding-in-c++ - fix -UseCCP case - use 16 bit alignment - with raw bit ops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15389/files - new: https://git.openjdk.org/jdk/pull/15389/files/12d19a06..09a7971e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15389&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15389&range=01-02 Stats: 6820 lines in 258 files changed: 4661 ins; 797 del; 1362 mod Patch: https://git.openjdk.org/jdk/pull/15389.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15389/head:pull/15389 PR: https://git.openjdk.org/jdk/pull/15389 From stuefe at openjdk.org Tue Aug 29 10:16:12 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 29 Aug 2023 10:16:12 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v2] In-Reply-To: References: Message-ID: On Thu, 24 Aug 2023 06:22:57 GMT, Thomas Stuefe wrote: >> Small change that reduces the number of loads generated by the C++ compiler for a narrow Klass decoding operation (`CompressedKlassPointers::decode_xxx()`. >> >> Stock: three loads (with two probably sharing a cache line) - UseCompressedClassPointers, encoding base and shift. >> >> >> 8b7b62: 48 8d 05 7f 1b c3 00 lea 0xc31b7f(%rip),%rax # 14e96e8 >> 8b7b69: 0f b6 00 movzbl (%rax),%eax >> 8b7b6c: 84 c0 test %al,%al >> 8b7b6e: 0f 84 9c 00 00 00 je 8b7c10 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> >> 8b7b74: 48 8d 15 05 62 c6 00 lea 0xc66205(%rip),%rdx # 151dd80 <_ZN23CompressedKlassPointers6_shiftE> >> 8b7b7b: 8b 7b 08 mov 0x8(%rbx),%edi >> 8b7b7e: 8b 0a mov (%rdx),%ecx >> 8b7b80: 48 8d 15 01 62 c6 00 lea 0xc66201(%rip),%rdx # 151dd88 <_ZN23CompressedKlassPointers5_baseE> >> 8b7b87: 48 d3 e7 shl %cl,%rdi >> 8b7b8a: 48 03 3a add (%rdx),%rdi >> >> >> Patched: one load loads all three. Since shift occupies the lowest 8 bits, compiled code uses 8bit register; ditto the UseCompressedOops flag. >> >> >> 8ba302: 48 8d 05 97 9c c2 00 lea 0xc29c97(%rip),%rax # 14e3fa0 <_ZN23CompressedKlassPointers6_comboE> >> 8ba309: 48 8b 08 mov (%rax),%rcx >> 8ba30c: f6 c5 01 test $0x1,%ch # use compressed klass pointers? >> 8ba30f: 0f 84 9b 00 00 00 je 8ba3b0 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> >> 8ba315: 8b 7b 08 mov 0x8(%rbx),%edi >> 8ba318: 48 d3 e7 shl %cl,%rdi # shift >> 8ba31b: 66 31 c9 xor %cx,%cx # zero out lower 16 bits of base >> 8ba31e: 48 01 cf add %rcx,%rdi # add base >> 8ba321: 8b 4f 08 mov 0x8(%rdi),%ecx >> >> --- >> >> Performance measurements: >> >> G1, doing a full GC over a heap filled with 256 mio life j.l.Object instances. >> >> I see a reduction of Full Pause times between 1.2% and 5%. I am unsure how reliable these numbers are since, despite my efforts (running tests on isolated CPUs etc.), the standard deviation was quite high at ?4%. Still, in general, numbers seemed to go down rather than up. >> >> --- >> >> Future extensions: >> >> This patch uses the fact that the encoding base is aligned to metaspace reser... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix -UseCCP case Thanks for looking at this, @theRealAph . I removed the `_from_combo` variants and streamlined setup a bit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15389#issuecomment-1697154247 From sspitsyn at openjdk.org Tue Aug 29 10:16:40 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 29 Aug 2023 10:16:40 GMT Subject: RFR: 8312174: missing JVMTI events from vthreads parked during JVMTI attach Message-ID: <5UkbsOBV6ixFV5IhduISKS7NpvPjU8s1r54KOwpBTC4=.510974ad-dfec-4ef8-8b41-1cd8d867d905@github.com> This update fixes two important issues: - Issue reported by a bug submitter about missing JVMTI events on virtual threads after an a JVMTI agent dynamic attach - Known scalability/performance issue: a need to lazily create `JvmtiThreadState's` for virtual threads The issue is tricky to fix because the existing mechanism of the JVMTI event management does not support unmounted virtual threads. The JVMTI `SetEventNotificationMode()` calls the function `JvmtiEventControllerPrivate::recompute_enabled()` which inspects a `JavaThread's` list and for each thread in the list recomputes enabled event bits with the function `JvmtiEventControllerPrivate::recompute_thread_enabled()`. The `JvmtiThreadState` of each thread is created but only when it is really needed, eg, if any of the thread filtered events is enabled. There was an initial adjustment of this mechanism for virtual threads which accounted for both carrier and virtual threads when a virtual thread is mounted. However, it does not work for unmounted virtual threads. A temporary work around was to always create `JvmtiThreadState` for each virtual thread eagerly at a thread starting point. This fix introduces new function `JvmtiExport::get_jvmti_thread_state()` which checks if thread is virtual and there is a thread filtered event enabled globally, and if so, forces a creation of the `JvmtiThreadState`. Another adjustment was needed because the function `state_for_while_locked()` can be called directly in some contexts. New function `JvmtiEventController::recompute_thread_filtered()` was introduced to make necessary corrections. Testing: - new test from the bug report was adopted: `test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest` - ran mach5 tiers 1-6: all are passed ------------- Commit messages: - 8312174: missing JVMTI events from vthreads parked during JVMTI attach Changes: https://git.openjdk.org/jdk/pull/15467/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15467&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312174 Stats: 414 lines in 9 files changed: 366 ins; 20 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/15467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15467/head:pull/15467 PR: https://git.openjdk.org/jdk/pull/15467 From jbhateja at openjdk.org Tue Aug 29 12:55:12 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 29 Aug 2023 12:55:12 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v3] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 23:17:00 GMT, Scott Gibbons wrote: >> Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. >> >> UPDATE: Subsequent commits increase performance gain to ~2x for AVX2, with no significant change to AVX512. >> >> Tested tier1. > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > mxcsr fix; address review comments Changes looks good to me, you may also include the results of following benchmark. ./test/micro/org/openjdk/bench/vm/compiler/pea/Blender.java src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp line 473: > 471: __ ucomisd(xmm0, xmm1); > 472: __ movapd(xmm4, xmm0); > 473: __ jccb(Assembler::aboveEqual, L_117f); This is a bounded label jump, Assembler::jcc should automatically optimize it with short jump encoding, but its not a blocker. ------------- PR Review: https://git.openjdk.org/jdk/pull/15210#pullrequestreview-1600272296 PR Review Comment: https://git.openjdk.org/jdk/pull/15210#discussion_r1308729157 From ayang at openjdk.org Tue Aug 29 13:21:35 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 29 Aug 2023 13:21:35 GMT Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion [v2] In-Reply-To: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Message-ID: > Use unsigned type for heap-region-size related shifts in HeapRegion. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - review - Merge branch 'master' into g1-heap-region-log-uint - g1-heap-region-log-uint ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15360/files - new: https://git.openjdk.org/jdk/pull/15360/files/26e1e298..49866dac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15360&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15360&range=00-01 Stats: 7641 lines in 350 files changed: 4996 ins; 1034 del; 1611 mod Patch: https://git.openjdk.org/jdk/pull/15360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15360/head:pull/15360 PR: https://git.openjdk.org/jdk/pull/15360 From ayang at openjdk.org Tue Aug 29 13:21:36 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 29 Aug 2023 13:21:36 GMT Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion [v2] In-Reply-To: References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Message-ID: On Tue, 29 Aug 2023 08:16:33 GMT, Thomas Schatzl wrote: >> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - review >> - Merge branch 'master' into g1-heap-region-log-uint >> - g1-heap-region-log-uint > > src/hotspot/share/gc/g1/g1Arguments.cpp line 137: > >> 135: uint region_size_log_mb = HeapRegion::LogOfHRGrainBytes > LOG_M >> 136: ? HeapRegion::LogOfHRGrainBytes - LOG_M >> 137: : 0; > > I would just assert that `HeapRegion::LogOfHRGrainBytes >= LOG_M` here. People messing with with minimum region size would need to check this code anyway. > > Further, `LOG_M` should probably be calculated as `log2_exact(HeapRegion::min_size())` instead of using the constant directly (and renamed appropriately, something like `Log[Of]MinHeapRegionSize/GrainBytes`). > > Then there would be no need to do the maximum calculation (my original suggestion would have been `MAX2(HeapRegion::LogOfHRGrainBytes - LOG_M, 0u)` btw) Checking how it's used around `G1RemSetArrayOfCardsEntriesBase`, `log_m` is more about 1MB. The very fact that min-heap-region is 1M seems an accident. Kept the original name and added assertion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15360#discussion_r1308804146 From dfuchs at openjdk.org Tue Aug 29 13:31:15 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 29 Aug 2023 13:31:15 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 00:16:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - Revised the API change. Add Option::DROP_METHOD_INFO > - Review feedback from Remi Hi Mandy, I like the new DROP_METHOD_INFO constant. Just a couple of minor suggestions on the wording (which you may chose to ignore as English is not my primary language). src/java.base/share/classes/java/lang/StackWalker.java line 73: > 71: *

1. To find the first caller filtering a known list of implementation class: > 72: * {@snippet lang="java" : > 73: * StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); Would this read better as "filtering **out** a known list of implementation **classes**" ? src/java.base/share/classes/java/lang/StackWalker.java line 98: > 96: * > 97: *

The information of a {@code StackFrame} available is determined by the > 98: * {@linkplain Option stack walking options} of a stack walker. Would this read better as "The information available from a {@code StackFrame} is determined ... "? ------------- PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1600394012 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1308804787 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1308807710 From fbredberg at openjdk.org Tue Aug 29 13:55:26 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 29 Aug 2023 13:55:26 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames Message-ID: Implementation of relativized extended_sp in interpreter frames for AArch64 and RISC-V. By changing the "extended_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. This subtask only handles "extended_sp". The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. Tested tier1-tier7 on aarch64. RISC-V was sanity tested using Qemu. ------------- Commit messages: - 8315069: Relativize extended_sp in interpreter frames Changes: https://git.openjdk.org/jdk/pull/15468/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15468&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315069 Stats: 46 lines in 10 files changed: 32 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/15468.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15468/head:pull/15468 PR: https://git.openjdk.org/jdk/pull/15468 From rriggs at openjdk.org Tue Aug 29 14:09:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 29 Aug 2023 14:09:12 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 09:12:51 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > copyright I don't think this is the best change across so many files. It gives a very ugly name to a common test function and affects a very large number of tests. ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1600512718 From tschatzl at openjdk.org Tue Aug 29 14:38:12 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 29 Aug 2023 14:38:12 GMT Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion [v2] In-Reply-To: References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Message-ID: On Tue, 29 Aug 2023 13:21:35 GMT, Albert Mingkun Yang wrote: >> Use unsigned type for heap-region-size related shifts in HeapRegion. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into g1-heap-region-log-uint > - g1-heap-region-log-uint Lgtm. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15360#pullrequestreview-1600600828 PR Review: https://git.openjdk.org/jdk/pull/15360#pullrequestreview-1600601295 From fjiang at openjdk.org Tue Aug 29 14:43:11 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 29 Aug 2023 14:43:11 GMT Subject: RFR: 8312569: RISC-V: Missing intrinsics for Math.ceil, floor, rint [v10] In-Reply-To: References: Message-ID: <3PcE05aE3Ti8SkcG6PZmPgq8SZcPHThe6iP2MsiY4Oo=.b27d01fd-cb37-404c-80af-c5cc9cfd03b2@github.com> On Tue, 29 Aug 2023 08:28:42 GMT, Ilya Gavrilin wrote: >> Please review this changes into risc-v double rounding intrinsic. >> >> On risc-v intrinsics for rounding doubles with mode (like Math.ceil/floor/rint) were missing. On risc-v we don`t have special instruction for such conversion, so two times conversion was used: double -> long int -> double (using fcvt.l.d, fcvt.d.l). >> >> Also, we should provide some rounding mode to fcvt.x.x instruction. >> >> Rounding mode selection on ceil (similar for floor and rint): according to Math.ceil requirements: >> >>> Returns the smallest (closest to negative infinity) value that is greater than or equal to the argument and is equal to a mathematical integer (Math.java:475). >> >> For double -> long int we choose rup (round towards +inf) mode to get the integer that more than or equal to the input value. >> For long int -> double we choose rdn (rounds towards -inf) mode to get the smallest (closest to -inf) representation of integer that we got after conversion. >> >> For cases when we got inf, nan, or value more than 2^63 return input value (double value which more than 2^63 is guaranteed integer). >> As well when we store result we copy sign from input value (need for cases when for (-1.0, 0.0) ceil need to return -0.0). >> >> We have observed significant improvement on hifive and thead boards. >> >> testing: tier1, tier2 and hotspot:tier3 on hifive >> >> Performance results on hifive (FpRoundingBenchmark.testceil/floor/rint): >> >> Without intrinsic: >> >> Benchmark (TESTSIZE) Mode Cnt Score Error Units >> FpRoundingBenchmark.testceil 1024 thrpt 25 39.297 ? 0.037 ops/ms >> FpRoundingBenchmark.testfloor 1024 thrpt 25 39.398 ? 0.018 ops/ms >> FpRoundingBenchmark.testrint 1024 thrpt 25 36.388 ? 0.844 ops/ms >> >> With intrinsic: >> >> Benchmark (TESTSIZE) Mode Cnt Score Error Units >> FpRoundingBenchmark.testceil 1024 thrpt 25 80.560 ? 0.053 ops/ms >> FpRoundingBenchmark.testfloor 1024 thrpt 25 80.541 ? 0.081 ops/ms >> FpRoundingBenchmark.testrint 1024 thrpt 25 80.603 ? 0.071 ops/ms > > Ilya Gavrilin has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in c2_MacroAssembler_riscv.cpp Marked as reviewed by fjiang (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14991#pullrequestreview-1600611526 From lkorinth at openjdk.org Tue Aug 29 15:13:11 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 29 Aug 2023 15:13:11 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 14:06:01 GMT, Roger Riggs wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright > > I don't think this is the best change across so many files. > It gives a very ugly name to a common test function and affects a very large number of tests. @RogerRiggs If it is only the name you want changed, maybe you can offer a better name? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1697634872 From bulasevich at openjdk.org Tue Aug 29 15:56:50 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Tue, 29 Aug 2023 15:56:50 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v10] In-Reply-To: References: Message-ID: > This is a change for AARCH similar to https://github.com/openjdk/jdk/pull/13460 > > The change replaces two separate iterations over the itable with a new algorithm consisting of two loops. First, we look for a match with resolved_klass, checking for a match with holder_klass along the way. Then we continue iterating (not starting over) the itable using the second loop, checking only for a match with holder_klass. > > InterfaceCalls openjdk benchmark performance results on A53, A72, Neoverse N1 and V1 micro-architectures: > > > Cortex-A53 (Pi 3 Model B Rev 1.2) > > test1stInt2Types 37.5 37.358 0.38 > test1stInt3Types 160.166 148.04 8.19 > test1stInt5Types 158.131 147.955 6.88 > test2ndInt2Types 52.634 53.291 -1.23 > test2ndInt3Types 201.39 181.603 10.90 > test2ndInt5Types 195.722 176.707 10.76 > testIfaceCall 157.453 140.498 12.07 > testIfaceExtCall 175.46 154.351 13.68 > testMonomorphic 32.052 32.039 0.04 > AVG: 6.85 > > Cortex-A72 (Pi 4 Model B Rev 1.2) > > test1stInt2Types 27.4796 27.4738 0.02 > test1stInt3Types 66.0085 64.9374 1.65 > test1stInt5Types 67.9812 66.2316 2.64 > test2ndInt2Types 32.0581 32.062 -0.01 > test2ndInt3Types 68.2715 65.6643 3.97 > test2ndInt5Types 68.1012 65.8024 3.49 > testIfaceCall 64.0684 64.1811 -0.18 > testIfaceExtCall 91.6226 81.5867 12.30 > testMonomorphic 26.7161 26.7142 0.01 > AVG: 2.66 > > Neoverse N1 (m6g.metal) > > test1stInt2Types 2.9104 2.9086 0.06 > test1stInt3Types 10.9642 10.2909 6.54 > test1stInt5Types 10.9607 10.2856 6.56 > test2ndInt2Types 3.3410 3.3478 -0.20 > test2ndInt3Types 12.3291 11.3089 9.02 > test2ndInt5Types 12.328 11.2704 9.38 > testIfaceCall 11.0598 10.3657 6.70 > testIfaceExtCall 13.0692 11.2826 15.84 > testMonomorphic 2.2354 2.2341 0.06 > AVG: 6.00 > > Neoverse V1 (c7g.2xlarge) > > test1stInt2Types 2.2317 2.2320 -0.01 > test1stInt3Types 6.6884 6.1911 8.03 > test1stInt5Types 6.7334 6.2193 8.27 > test2ndInt2Types 2.4002 2.4013 -0.04 > test2ndInt3Types 7.9603 7.0372 13.12 > test2ndInt5Types 7.9532 7.0474 12.85 > testIfaceCall 6.7028 6.3272 5.94 > testIfaceExtCall 8.3253 6.9416 19.93 > testMonomorphic 1.2446 1.2544 -0.79 > AVG: 7.48 > > > Testing... Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: Address base_plus_offset_reg encoding: assert->guarantee for shift() == size check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13792/files - new: https://git.openjdk.org/jdk/pull/13792/files/83b79815..1687c4bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13792&range=08-09 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13792/head:pull/13792 PR: https://git.openjdk.org/jdk/pull/13792 From iwalulya at openjdk.org Tue Aug 29 16:09:12 2023 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 29 Aug 2023 16:09:12 GMT Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion [v2] In-Reply-To: References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Message-ID: On Tue, 29 Aug 2023 13:21:35 GMT, Albert Mingkun Yang wrote: >> Use unsigned type for heap-region-size related shifts in HeapRegion. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into g1-heap-region-log-uint > - g1-heap-region-log-uint Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15360#pullrequestreview-1600803752 From bulasevich at openjdk.org Tue Aug 29 16:19:16 2023 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Tue, 29 Aug 2023 16:19:16 GMT Subject: RFR: 8307352: AARCH64: Improve itable_stub [v8] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 08:44:40 GMT, Andrew Haley wrote: >>> By the way, [assembler_aarch64.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/assembler_aarch64.hpp) contains 100+ assert calls and 34 guarantee calls. I think more cases can be changed, although I am not sure what the rule is for using this or that call. >> >> A JBS issue? > > No, I don't think so. > > The balance between `assert()` and `guarantee()` is a matter of judgement, not hard rules. > > We don't want to do consistency checking at runtime if we can avoid it, because it adds to startup time. > > The `guarantee()` that an operand fits into its field in an instruction has proved its worth, many times. This is because AArch64 has a variety of offset fields, and these are of varying lengths. It's very easy to be caught out, and sometimes this has happened even after release. > > In most other places, an `assert()` is all we need. This is because the thing being asserted doesn't vary much, and we only need to check it once, when we run a debug build. > > In the case of checking that the shift in a memory-access instruction matches the operand size, the check will be inlined. I haven't looked, but I expect it will be eliminated by the C++ optimizer at compile time. > > In the case of the ldr instruction here, the operand size is determined already by the `ldr` instruction: it's `wordSize`. It cannot be anything else. The AArch64 back end asserts that elsewhere: > > > int vte_size = vtableEntry::size_in_bytes(); > assert(vte_size == wordSize, "else adjust times_vte_scale"); I agree. I keep assert in MacroAssembler::lookup_interface_method_stub and change assert to guarantee in Address::encode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13792#discussion_r1309070418 From alanb at openjdk.org Tue Aug 29 16:20:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Aug 2023 16:20:15 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 00:16:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: > > - Revised the API change. Add Option::DROP_METHOD_INFO > - Review feedback from Remi src/java.base/share/classes/java/lang/StackWalker.java line 53: > 51: * > 52: *

The {@linkplain Option stack walking option} specifies > 53: * what the information a stack walker collects from the stack frames. I think this needs to use "Stack walking options" or "A stack walking option". Alternatively, just copy the first sentence from the Option javadoc so it changes to "Stack walker options configure the stack frame information obtained by a StackWalker". src/java.base/share/classes/java/lang/StackWalker.java line 54: > 52: *

The {@linkplain Option stack walking option} specifies > 53: * what the information a stack walker collects from the stack frames. > 54: * By default, the class name and method information are available but What would you think about changing "available" to "collected"? src/java.base/share/classes/java/lang/StackWalker.java line 58: > 56: * The method information can be dropped via {@link Option#DROP_METHOD_INFO > 57: * DROP_METHOD_INFO} option. The {@code Class} object can be retained for > 58: * access via {@link Option#RETAIN_CLASS_REFERENCE RETAIN_CLASS_REFERENCE} option. Probably should be "via the" rather than "via" in all cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309066013 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309066916 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309067884 From ayang at openjdk.org Tue Aug 29 16:23:23 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 29 Aug 2023 16:23:23 GMT Subject: RFR: 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize Message-ID: Use more precise type and range for `GCDrainStackTargetSize`. The change to `TASKQUEUE_SIZE` is there, because they are used in the same `MIN2`. (All uses expect `TASKQUEUE_SIZE` to be `uint` as well.) ------------- Commit messages: - g1-uint Changes: https://git.openjdk.org/jdk/pull/15472/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15472&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315242 Stats: 9 lines in 4 files changed: 0 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/15472.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15472/head:pull/15472 PR: https://git.openjdk.org/jdk/pull/15472 From mchung at openjdk.org Tue Aug 29 16:30:17 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 29 Aug 2023 16:30:17 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 16:12:27 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revised the API change. Add Option::DROP_METHOD_INFO >> - Review feedback from Remi > > src/java.base/share/classes/java/lang/StackWalker.java line 53: > >> 51: * >> 52: *

The {@linkplain Option stack walking option} specifies >> 53: * what the information a stack walker collects from the stack frames. > > I think this needs to use "Stack walking options" or "A stack walking option". Alternatively, just copy the first sentence from the Option javadoc so it changes to "Stack walker options configure the stack frame information obtained by a StackWalker". Updated to use the first sentence from the Option javadoc. Use it in the class spec of StackWalker and StackFrame consistently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309082363 From mchung at openjdk.org Tue Aug 29 16:30:18 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 29 Aug 2023 16:30:18 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 13:19:11 GMT, Daniel Fuchs wrote: >> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revised the API change. Add Option::DROP_METHOD_INFO >> - Review feedback from Remi > > src/java.base/share/classes/java/lang/StackWalker.java line 98: > >> 96: * >> 97: *

The information of a {@code StackFrame} available is determined by the >> 98: * {@linkplain Option stack walking options} of a stack walker. > > Would this read better as "The information available from a {@code StackFrame} is determined ... "? What about "Stack walker options configure the stack frame information obtained by a StackWalker." - the first sentence from the Option javadoc and use it in the class spec of StackWalker and StackFrame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309081786 From mchung at openjdk.org Tue Aug 29 16:36:16 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 29 Aug 2023 16:36:16 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 16:13:11 GMT, Alan Bateman wrote: >> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revised the API change. Add Option::DROP_METHOD_INFO >> - Review feedback from Remi > > src/java.base/share/classes/java/lang/StackWalker.java line 54: > >> 52: *

The {@linkplain Option stack walking option} specifies >> 53: * what the information a stack walker collects from the stack frames. >> 54: * By default, the class name and method information are available but > > What would you think about changing "available" to "collected"? "collected" is better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309089304 From mchung at openjdk.org Tue Aug 29 16:43:16 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 29 Aug 2023 16:43:16 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 13:16:56 GMT, Daniel Fuchs wrote: >> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revised the API change. Add Option::DROP_METHOD_INFO >> - Review feedback from Remi > > src/java.base/share/classes/java/lang/StackWalker.java line 73: > >> 71: *

1. To find the first caller filtering a known list of implementation class: >> 72: * {@snippet lang="java" : >> 73: * StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); > > Would this read better as "filtering **out** a known list of implementation **classes**" ? how about "s/filtering/excluding"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309095990 From rriggs at openjdk.org Tue Aug 29 16:48:15 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 29 Aug 2023 16:48:15 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com> On Tue, 29 Aug 2023 14:06:01 GMT, Roger Riggs wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright > > I don't think this is the best change across so many files. > It gives a very ugly name to a common test function and affects a very large number of tests. > @RogerRiggs If it is only the name you want changed, maybe you can offer a better name? @lkorinth Sorry for the too short comment; I wanted to make sure it wasn't integrated before I could look at it more closely. Neither the bug report or the PR describe the problem and its ramifications, only the solution. Can you elaborate on the conditions that lead to this. (and include them in the bug report). ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1697803842 From dfuchs at openjdk.org Tue Aug 29 17:02:17 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 29 Aug 2023 17:02:17 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 16:39:56 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/StackWalker.java line 73: >> >>> 71: *

1. To find the first caller filtering a known list of implementation class: >>> 72: * {@snippet lang="java" : >>> 73: * StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> >> Would this read better as "filtering **out** a known list of implementation **classes**" ? > > how about "s/filtering/excluding"? Yes - that's better. >> src/java.base/share/classes/java/lang/StackWalker.java line 98: >> >>> 96: * >>> 97: *

The information of a {@code StackFrame} available is determined by the >>> 98: * {@linkplain Option stack walking options} of a stack walker. >> >> Would this read better as "The information available from a {@code StackFrame} is determined ... "? > > What about "Stack walker options configure the stack frame information obtained by a StackWalker." - the first sentence from the Option javadoc and use it in the class spec of StackWalker and StackFrame. Sounds good! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309117609 PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309116727 From alanb at openjdk.org Tue Aug 29 17:08:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Aug 2023 17:08:13 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 16:59:22 GMT, Daniel Fuchs wrote: >> how about "s/filtering/excluding"? > > Yes - that's better. The example use filter so it might be better to have the text use the same word, up to you, I think "filtering out known implementation classes" works too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309122820 From sgibbons at openjdk.org Tue Aug 29 17:53:12 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Tue, 29 Aug 2023 17:53:12 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v3] In-Reply-To: References: Message-ID: <2pDs2Z-eS0Ut2gea76FkSsNFHH4JF4GetfQLf9QEyIg=.4f05ff23-3bfe-4999-a2d0-d66ab940706b@github.com> On Wed, 23 Aug 2023 23:17:00 GMT, Scott Gibbons wrote: >> Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. >> >> UPDATE: Subsequent commits increase performance gain to ~2x for AVX2, with no significant change to AVX512. >> >> Tested tier1. > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > mxcsr fix; address review comments @jddarcy FYI. If you'd like to review, it would be appreciated. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15210#issuecomment-1697886881 From cjplummer at openjdk.org Tue Aug 29 19:25:12 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 29 Aug 2023 19:25:12 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 09:12:51 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > copyright > I kind of like that it is long and clumsy, that makes it harder to use... ...but it's used in 462 files. That implies it is commonly used. Are you suggesting nearly all those uses are incorrect and eventually should be converted to `createTestJvm()`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698003837 From mchung at openjdk.org Tue Aug 29 20:51:56 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 29 Aug 2023 20:51:56 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: References: Message-ID: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` > can be used instead and such stack walker will save the overhead of extracting the method information > and the memory used for the stack walking. > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can create a stack walker instance with `DROP_METHOD_INFO` option: > > > StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(Predicate.not(implClasses::contains)) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Javadoc & specdiff > > https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html > https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > ### Implementation Details > > A `StackWalker` configured with `DROP_METHOD_INFO` option creates `ClassFrameInfo[]` > buffer that is filled by the VM during stack walking. `Sta... Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: - update mode to be int rather than long - update tests - Review feedback on javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15370/files - new: https://git.openjdk.org/jdk/pull/15370/files/3ca53c74..5a48c709 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=06-07 Stats: 127 lines in 14 files changed: 81 ins; 0 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From jjoo at openjdk.org Tue Aug 29 21:11:23 2023 From: jjoo at openjdk.org (Jonathan Joo) Date: Tue, 29 Aug 2023 21:11:23 GMT Subject: RFR: 8315149: Add hsperf counters for CPU time of JVM internal threads Message-ID: 8315149: Add hsperf counters for CPU time of JVM internal threads ------------- Commit messages: - Add hsperf counters for CPU time of JVM internal threads Changes: https://git.openjdk.org/jdk/pull/15082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315149 Stats: 170 lines in 17 files changed: 170 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15082/head:pull/15082 PR: https://git.openjdk.org/jdk/pull/15082 From jbhateja at openjdk.org Wed Aug 30 01:31:21 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 30 Aug 2023 01:31:21 GMT Subject: RFR: JDK-8314056 Remove runtime platform check from frem/drem [v3] In-Reply-To: References: Message-ID: On Wed, 23 Aug 2023 23:17:00 GMT, Scott Gibbons wrote: >> Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. >> >> UPDATE: Subsequent commits increase performance gain to ~2x for AVX2, with no significant change to AVX512. >> >> Tested tier1. > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > mxcsr fix; address review comments Marked as reviewed by jbhateja (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15210#pullrequestreview-1601725307 From sgibbons at openjdk.org Wed Aug 30 01:31:22 2023 From: sgibbons at openjdk.org (Scott Gibbons) Date: Wed, 30 Aug 2023 01:31:22 GMT Subject: Integrated: JDK-8314056 Remove runtime platform check from frem/drem In-Reply-To: References: Message-ID: On Wed, 9 Aug 2023 16:48:36 GMT, Scott Gibbons wrote: > Remove platform check and move code to stubGenerator. This fix increases performance by ~4.5%. > > UPDATE: Subsequent commits increase performance gain to ~2x for AVX2, with no significant change to AVX512. > > Tested tier1. This pull request has now been integrated. Changeset: ce2a7ea4 Author: Scott Gibbons Committer: Jatin Bhateja URL: https://git.openjdk.org/jdk/commit/ce2a7ea40a22c652e5f8559c91d5eea197e2d708 Stats: 196 lines in 8 files changed: 67 ins; 86 del; 43 mod 8314056: Remove runtime platform check from frem/drem Reviewed-by: sviswanathan, jbhateja ------------- PR: https://git.openjdk.org/jdk/pull/15210 From cslucas at openjdk.org Wed Aug 30 03:20:38 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 30 Aug 2023 03:20:38 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store Message-ID: I believe the factory methods for AddPNode should be in the AddPNode class. The make_load / make_store methods in PhaseMacroExpand can be refactored to instead just use the "make" methods from Load/Store classes. Tested with tier1-3. ------------- Commit messages: - Refactoring on PhaseMacroExpand Changes: https://git.openjdk.org/jdk/pull/15480/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15480&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315279 Stats: 92 lines in 11 files changed: 37 ins; 32 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/15480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15480/head:pull/15480 PR: https://git.openjdk.org/jdk/pull/15480 From haosun at openjdk.org Wed Aug 30 03:32:07 2023 From: haosun at openjdk.org (Hao Sun) Date: Wed, 30 Aug 2023 03:32:07 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 12:08:49 GMT, Fredrik Bredberg wrote: > Implementation of relativized extended_sp in interpreter frames for AArch64 and RISC-V. > > By changing the "extended_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "extended_sp". The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on aarch64. RISC-V was sanity tested using Qemu. AArch64 part is good to me. ------------- Marked as reviewed by haosun (Committer). PR Review: https://git.openjdk.org/jdk/pull/15468#pullrequestreview-1601802493 From alanb at openjdk.org Wed Aug 30 07:12:24 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Aug 2023 07:12:24 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> References: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> Message-ID: On Tue, 29 Aug 2023 20:51:56 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: > > - update mode to be int rather than long > - update tests > - Review feedback on javadoc The updated proposal/javadoc looks good, just in two minds on whether the overload with the varargs should be added. The Set.of factory methods make is really easy to use the existing getInstance(Set) method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1698616974 From dholmes at openjdk.org Wed Aug 30 07:22:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 30 Aug 2023 07:22:10 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2] In-Reply-To: <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com> References: <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com> Message-ID: On Tue, 29 Aug 2023 16:45:12 GMT, Roger Riggs wrote: >> I don't think this is the best change across so many files. >> It gives a very ugly name to a common test function and affects a very large number of tests. > >> @RogerRiggs If it is only the name you want changed, maybe you can offer a better name? > @lkorinth > > Sorry for the too short comment; I wanted to make sure it wasn't integrated before I could look at it more closely. > Neither the bug report or the PR describe the problem and its ramifications, only the solution. > Can you elaborate on the conditions that lead to this. (and include them in the bug report). @RogerRiggs , @plummercj , please see the additional discussion in the parent bug: https://bugs.openjdk.org/browse/JDK-8314823 ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698629345 From dholmes at openjdk.org Wed Aug 30 07:47:17 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 30 Aug 2023 07:47:17 GMT Subject: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 01:50:07 GMT, Jonathan Joo wrote: > 8315149: Add hsperf counters for CPU time of internal GC threads This doesn't seem unreasonable, but I do wonder what impact this has on the GC threads to collect this data? I mentioned it a couple of times, but generally speaking should we only initialize these perf counters when `os::is_thread_cpu_time_supported()`? Or do they need to be readable regardless? Thanks. src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 457: > 455: reset_at_marking_complete(); > 456: > 457: if (UsePerfData) { Should this also check `os::is_thread_cpu_time_supported()`? src/hotspot/share/gc/g1/g1ConcurrentMark.hpp line 377: > 375: VerifyLocation location); > 376: > 377: Spurious blank line added. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 116: > 114: } > 115: > 116: if (UsePerfData) { Again should we only initialize if also `os::is_thread_cpu_time_supported()`? src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 166: > 164: // The primary thread (_threads[0]) updates the counter for all worker > 165: // threads, because: > 166: // the primary thread is always waken up first from being blocked on a monitor s/waken/woken/ src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 174: > 172: "Must be called from G1ConcurrentRefineThreadControl::_threads[0] to " > 173: "avoid races"); > 174: assert(UsePerfData, "Must be enabled"); `&& os::is_thread_cpu_time_supported()` ? ------------- PR Review: https://git.openjdk.org/jdk/pull/15082#pullrequestreview-1602076724 PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1309822503 PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1309823735 PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1309824856 PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1309825515 PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1309826501 From aph at openjdk.org Wed Aug 30 08:17:13 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 30 Aug 2023 08:17:13 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames In-Reply-To: References: Message-ID: <8OudLKJXlb9Ho6-oksrlhw3MCQEY0sjPkUi7svVmyaE=.6eb62341-dd9b-469d-95aa-e923bb18a50b@github.com> On Tue, 29 Aug 2023 12:08:49 GMT, Fredrik Bredberg wrote: > Implementation of relativized extended_sp in interpreter frames for AArch64 and RISC-V. > > By changing the "extended_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "extended_sp". The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on aarch64. RISC-V was sanity tested using Qemu. src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 815: > 813: __ sub(esp, esp, entry_size); > 814: __ sub(rscratch1, sp, rfp); > 815: __ asr(rscratch1, rscratch1, Interpreter::logStackElementSize); The shifts when calculating the relativized extended SP increase latency and reduce throughput, and they don't do anything useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15468#discussion_r1309871515 From tschatzl at openjdk.org Wed Aug 30 08:38:14 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 30 Aug 2023 08:38:14 GMT Subject: RFR: 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize In-Reply-To: References: Message-ID: <_fHnwR90I3zB_PT9YjajhjJJPwyXOZVol1sXNuJo8b4=.17791f97-dcb4-4be9-81f9-5bb76d6c8794@github.com> On Tue, 29 Aug 2023 16:15:44 GMT, Albert Mingkun Yang wrote: > Use more precise type and range for `GCDrainStackTargetSize`. > > The change to `TASKQUEUE_SIZE` is there, because they are used in the same `MIN2`. (All uses expect `TASKQUEUE_SIZE` to be `uint` as well.) Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2322: > 2320: uint target_size; > 2321: if (partially) { > 2322: target_size = MIN2(_task_queue->max_elems()/3, GCDrainStackTargetSize); Suggestion: target_size = MIN2(_task_queue->max_elems() / 3, GCDrainStackTargetSize); src/hotspot/share/gc/shared/gc_globals.hpp line 687: > 685: "Delay between expansion and allocation (in milliseconds)") \ > 686: \ > 687: product(uint, GCDrainStackTargetSize, 64, \ Suggestion: product(uint, GCDrainStackTargetSize, 64, \ src/hotspot/share/gc/shared/gc_globals.hpp line 690: > 688: "Number of entries we will try to leave on the stack " \ > 689: "during parallel gc") \ > 690: range(0, (max_juint-1)/2) \ Suggestion: range(0, (UINT_MAX - 1) / 2) \ Avoid using `juint_*` in code not interfacing java. Also the `` is indented improperly, and even in above suggestion it might still be. ------------- PR Review: https://git.openjdk.org/jdk/pull/15472#pullrequestreview-1602181980 PR Review Comment: https://git.openjdk.org/jdk/pull/15472#discussion_r1309898852 PR Review Comment: https://git.openjdk.org/jdk/pull/15472#discussion_r1309897911 PR Review Comment: https://git.openjdk.org/jdk/pull/15472#discussion_r1309896479 From lkorinth at openjdk.org Wed Aug 30 09:23:55 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 30 Aug 2023 09:23:55 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: > Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. > > I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` > > Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: > > /** > * Create ProcessBuilder using the java launcher from the jdk to > * be tested. > * > *

Please observe that you likely should use > * createTestJvm() instead of this method because createTestJvm() > * will add JVM options from "test.vm.opts" and "test.java.opts" > * and this method will not do that. > * > * @param command Arguments to pass to the java command. > * @return The ProcessBuilder instance representing the java command. > */ > > > I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... > > I have run tier 1 testing, and I have started more exhaustive testing. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: fix static import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15452/files - new: https://git.openjdk.org/jdk/pull/15452/files/f3418c80..27da7150 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452 PR: https://git.openjdk.org/jdk/pull/15452 From ayang at openjdk.org Wed Aug 30 09:40:20 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 30 Aug 2023 09:40:20 GMT Subject: RFR: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion [v2] In-Reply-To: References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Message-ID: On Tue, 29 Aug 2023 13:21:35 GMT, Albert Mingkun Yang wrote: >> Use unsigned type for heap-region-size related shifts in HeapRegion. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into g1-heap-region-log-uint > - g1-heap-region-log-uint Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15360#issuecomment-1698828094 From ayang at openjdk.org Wed Aug 30 09:40:21 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 30 Aug 2023 09:40:21 GMT Subject: Integrated: 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion In-Reply-To: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> References: <0s0_gYMRgYYSd_yhbbMdJvGSBzpD3gNB78oRpsp0eCA=.eaba7fc7-5d53-4b4f-8bba-516b566eed8a@github.com> Message-ID: On Mon, 21 Aug 2023 12:25:12 GMT, Albert Mingkun Yang wrote: > Use unsigned type for heap-region-size related shifts in HeapRegion. > > Test: tier1-3 This pull request has now been integrated. Changeset: cb3f9680 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/cb3f9680d35f2afbd973c946ad4ccf94f30fffc9 Stats: 24 lines in 9 files changed: 4 ins; 4 del; 16 mod 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/15360 From tschatzl at openjdk.org Wed Aug 30 09:49:32 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 30 Aug 2023 09:49:32 GMT Subject: RFR: 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize [v2] In-Reply-To: <82X0oUfWsiPcALA_ghgALdreCBgf3tE7Cg7-hdLogyk=.2667867e-5d2a-4fd8-bab6-a135863732fa@github.com> References: <82X0oUfWsiPcALA_ghgALdreCBgf3tE7Cg7-hdLogyk=.2667867e-5d2a-4fd8-bab6-a135863732fa@github.com> Message-ID: <_Gbnx8yjWhJdwjfJzwN-k_8oc5JKwpJ2eKkhzCLk9rU=.d57a86b5-edd7-4b00-b36e-71d323716b5c@github.com> On Wed, 30 Aug 2023 09:44:33 GMT, Albert Mingkun Yang wrote: >> Use more precise type and range for `GCDrainStackTargetSize`. >> >> The change to `TASKQUEUE_SIZE` is there, because they are used in the same `MIN2`. (All uses expect `TASKQUEUE_SIZE` to be `uint` as well.) > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15472#pullrequestreview-1602319485 From ayang at openjdk.org Wed Aug 30 09:49:32 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 30 Aug 2023 09:49:32 GMT Subject: RFR: 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize [v2] In-Reply-To: References: Message-ID: <82X0oUfWsiPcALA_ghgALdreCBgf3tE7Cg7-hdLogyk=.2667867e-5d2a-4fd8-bab6-a135863732fa@github.com> > Use more precise type and range for `GCDrainStackTargetSize`. > > The change to `TASKQUEUE_SIZE` is there, because they are used in the same `MIN2`. (All uses expect `TASKQUEUE_SIZE` to be `uint` as well.) Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15472/files - new: https://git.openjdk.org/jdk/pull/15472/files/483dfbec..12f8e961 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15472&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15472&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/15472.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15472/head:pull/15472 PR: https://git.openjdk.org/jdk/pull/15472 From joachim.kern at sap.com Wed Aug 30 10:56:02 2023 From: joachim.kern at sap.com (Kern, Joachim) Date: Wed, 30 Aug 2023 10:56:02 +0000 Subject: SelectorManager threads are discriminated in race to get threads_lock mutex In-Reply-To: References: Message-ID: Hi guys, The ContinuationFrameTest.java on AIX fails to end within the gracedelay period. The gracedelay period function in ReferenceTracker.java effectively does the following: for (i = 0; i < 50; i++) { if (!TRACKERS.stream().anyMatch(hasOutstanding)) break; System.gc(); Thread.sleep(10); } During this grace period there are at least 3 thread categories fighting for the threads_lock mutex. 1. The SafepointSynchronize::begin() locks the threads_lock mutex for the gc. It holds the mutex for about 300ms. 2. The wait_until_not_protected() function, which is called a dozen times during one loop iteration. It holds the mutex for about 0.4ms. 3. And the SelectorManager threads which need the mutex one time to complete their shutdown. They need the mutex for about 0.5ms. The threads of all three categories are running with identical native thread priority . On the various Linux derivates(x86 and ppc64) you can see, that the SelectorManager threads are finding slots between the other mutex consumers, so that all threads are shutdown within about 7 loop iterations. On AIX the SelectorManager threads can?t make it or less often. So, some of them are still alive after the complete grace period, although they were queued up even before the grace period. This means in total 50 iterations where their requests were ignored and all later coming requests from 1.+2. were satisfied. So, how are the thread priorities handled in hotspot. Why are the AIX SelectorManager threads discriminated. Can you please help me with an idea. Greetings Joachim -------------- next part -------------- An HTML attachment was scrubbed... URL: From msheppar at openjdk.org Wed Aug 30 11:34:12 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 30 Aug 2023 11:34:12 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import I don't think a name change is required. The method is createJavaProcessBuilder with a "list" of argurments and a builder is returned. As such, there is no inference, in the name, that test args will be propagated. Adding the additional java doc description should be sufficient to dispell any misconceptions. The createTestJvm is a misnomer as it returns a ProcessBulder rather than a Process, which is what I would expected from createTestJvm, without looking at its signature. So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g. createJavaProcessBuilder(List command, boolean addTestOpts) { ... } createProcessBuilderIgnoreJavaTestOpt(cmdArgs) maps to createJavaProcessBuilder(cmdArgs, false) createTestJvm(cmdArgs) maps to createJavaProcessBuilder(cmdArgs, true) But this is a lot more work. alternatively change createTestJvm to createTestJavaProcessBuilder or createJavaProcessBuilderAddTestOpts ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698985460 From fbredberg at openjdk.org Wed Aug 30 12:44:14 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 30 Aug 2023 12:44:14 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames In-Reply-To: <8OudLKJXlb9Ho6-oksrlhw3MCQEY0sjPkUi7svVmyaE=.6eb62341-dd9b-469d-95aa-e923bb18a50b@github.com> References: <8OudLKJXlb9Ho6-oksrlhw3MCQEY0sjPkUi7svVmyaE=.6eb62341-dd9b-469d-95aa-e923bb18a50b@github.com> Message-ID: <9WjAQLyrb8l7o2-UfN1XE_MKSEo-faxhwZG5NWtlabI=.87878628-6bdc-40d9-bd6e-f34ef73dc030@github.com> On Wed, 30 Aug 2023 08:14:25 GMT, Andrew Haley wrote: > The shifts when calculating the relativized extended SP increase latency and reduce throughput, and they don't do anything useful. It's true that the shift instructions add a bit of unnecessary overhead, but all the relativize and derelativize code today is based on pointer arithmetic. For instance interpreter frame locals are found at: `fp() + *addr_at(interpreter_frame_locals_offset)` So in order to get rid of the shifts we would need to move away from pointer arithmetic, which means adding a lot of explicit casts in the C++ code. To get the pointer to the locals the code above would have to be changed into: `(intptr_t*)((char *)fp() + (char *)*addr_at(interpreter_frame_locals_offset))` I choose to stick to the definition where a relativized value is "a word index from the frame pointer" and not change it to "number of bytes from the frame pointer", because it meant less changes to the C++ code. Some interpreter frame members (such as `extended_sp`) doesn't show up in the C++ code as much as `locals`, but I didn't want to have different representations for a relativized pointer, so all of them are "word index from the frame pointer". Also, the overhead of the shifts is likely negligibly since we now calculate the relativized value once, and not every time we freeze and thaw. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15468#discussion_r1310213478 From aph at openjdk.org Wed Aug 30 13:31:12 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 30 Aug 2023 13:31:12 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames In-Reply-To: <9WjAQLyrb8l7o2-UfN1XE_MKSEo-faxhwZG5NWtlabI=.87878628-6bdc-40d9-bd6e-f34ef73dc030@github.com> References: <8OudLKJXlb9Ho6-oksrlhw3MCQEY0sjPkUi7svVmyaE=.6eb62341-dd9b-469d-95aa-e923bb18a50b@github.com> <9WjAQLyrb8l7o2-UfN1XE_MKSEo-faxhwZG5NWtlabI=.87878628-6bdc-40d9-bd6e-f34ef73dc030@github.com> Message-ID: On Wed, 30 Aug 2023 12:41:32 GMT, Fredrik Bredberg wrote: >> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 815: >> >>> 813: __ sub(esp, esp, entry_size); >>> 814: __ sub(rscratch1, sp, rfp); >>> 815: __ asr(rscratch1, rscratch1, Interpreter::logStackElementSize); >> >> The shifts when calculating the relativized extended SP increase latency and reduce throughput, and they don't do anything useful. > >> The shifts when calculating the relativized extended SP increase latency and reduce throughput, and they don't do anything useful. > > It's true that the shift instructions add a bit of unnecessary overhead, but all the relativize and derelativize code today is based on pointer arithmetic. For instance interpreter frame locals are found at: > > `fp() + *addr_at(interpreter_frame_locals_offset)` > > So in order to get rid of the shifts we would need to move away from pointer arithmetic, which means adding a lot of explicit casts in the C++ code. To get the pointer to the locals the code above would have to be changed into: > > `(intptr_t*)((char *)fp() + (char *)*addr_at(interpreter_frame_locals_offset))` > > I choose to stick to the definition where a relativized value is "a word index from the frame pointer" and not change it to "number of bytes from the frame pointer", because it meant less changes to the C++ code. > > Some interpreter frame members (such as `extended_sp`) doesn't show up in the C++ code as much as `locals`, but I didn't want to have different representations for a relativized pointer, so all of them are "word index from the frame pointer". > > Also, the overhead of the shifts is likely negligibly since we now calculate the relativized value once, and not every time we freeze and thaw. OK, fair enough. It's somewhat annoying and pointless, but we can live with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15468#discussion_r1310283382 From aph at openjdk.org Wed Aug 30 13:31:10 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 30 Aug 2023 13:31:10 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames In-Reply-To: References: Message-ID: <-fqg4rWkVQhX8i00hqPWXM8CgocwV8crpVCIB4wb_c0=.562f3c5d-aad0-4363-9900-c5d97d7525f7@github.com> On Tue, 29 Aug 2023 12:08:49 GMT, Fredrik Bredberg wrote: > Implementation of relativized extended_sp in interpreter frames for AArch64 and RISC-V. > > By changing the "extended_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "extended_sp". The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on aarch64. RISC-V was sanity tested using Qemu. Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15468#pullrequestreview-1602714251 From aph at openjdk.org Wed Aug 30 13:34:14 2023 From: aph at openjdk.org (Andrew Haley) Date: Wed, 30 Aug 2023 13:34:14 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 12:08:49 GMT, Fredrik Bredberg wrote: > Implementation of relativized extended_sp in interpreter frames for AArch64 and RISC-V. > > By changing the "extended_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "extended_sp". The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on aarch64. RISC-V was sanity tested using Qemu. src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp line 89: > 87: Label L; > 88: ldr(rscratch1, Address(rfp, frame::interpreter_frame_extended_sp_offset * wordSize)); > 89: lea(rscratch1, Address(rfp, rscratch1, Address::lsl(3))); Suggestion: lea(rscratch1, Address(rfp, rscratch1, Address::lsl(LogBytesPerWord))); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15468#discussion_r1310287958 From fyang at openjdk.org Wed Aug 30 14:41:13 2023 From: fyang at openjdk.org (Fei Yang) Date: Wed, 30 Aug 2023 14:41:13 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 12:08:49 GMT, Fredrik Bredberg wrote: > Implementation of relativized extended_sp in interpreter frames for AArch64 and RISC-V. > > By changing the "extended_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "extended_sp". The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on aarch64. RISC-V was sanity tested using Qemu. Hello, I am arranging some more testing on my RISC-V board. BTW: You need to merge master to make the GHA happy. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15468#issuecomment-1699312382 From rriggs at openjdk.org Wed Aug 30 15:10:13 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 30 Aug 2023 15:10:13 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import In the context of the goal is to declaratively identify tests that do or do not benefit from additional test flags renaming the `createjavaProcessBuilder` method does not further that goal. The method name and javadoc of `createjavaProcessBuilder` do not imply that the test options are consulted or used; it only says it creates a ProcessBuilder, and does not promise or document more than that. The javadoc should probably describe the use of the the three properties that modify the way that the java is launched. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699362435 From dfuchs at openjdk.org Wed Aug 30 15:20:20 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 30 Aug 2023 15:20:20 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> References: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> Message-ID: On Tue, 29 Aug 2023 20:51:56 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks >> like logging may only interest in the Class object but not the method name nor the BCI, >> for example, filters out its implementation classes to find the caller class. It's >> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. >> >> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` >> can be used instead and such stack walker will save the overhead of extracting the method information >> and the memory used for the stack walking. >> >> New factory methods to take a parameter to specify the kind of stack walker to be created are defined. >> This provides a simple way for existing code, for example logging frameworks, to take advantage of >> this enhancement with the least change as it can keep the existing function for traversing >> `StackFrame`s. >> >> For example: to find the first caller filtering a known list of implementation class, >> existing code can create a stack walker instance with `DROP_METHOD_INFO` option: >> >> >> StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); >> Optional> callerClass = walker.walk(s -> >> s.map(StackFrame::getDeclaringClass) >> .filter(Predicate.not(implClasses::contains)) >> .findFirst()); >> >> >> If method information is accessed on the `StackFrame`s produced by this stack walker such as >> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. >> >> #### Javadoc & specdiff >> >> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html >> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html >> >> #### Alternatives Considered >> One alternative is to provide a new API: >> ` T walkClass(Function, ? extends T> function)` >> >> In this case, the caller would need to pass a function that takes a stream >> of `Class` object instead of `StackFrame`. Existing code would have to >> modify calls to the `walk` method to `walkClass` and the function body. >> >> ### Implementation Details >> >> A `StackWalker` configured with `DROP_METHOD_INFO` ... > > Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: > > - update mode to be int rather than long > - update tests > - Review feedback on javadoc src/java.base/share/classes/java/lang/StackStreamFactory.java line 694: > 692: // no method information is available; should just filter > 693: // "Continuation::yield0". > 694: return classFrames[index].declaringClass() == Continuation.class; Is that going to be an issue if by chance the frame is some other method on continuation? Could that comment be clarified a bit? I am not sure what is meant by `should just filter "Continuation::yield0"`; Does it mean: that's what we should do, but we can't, so we filter any method on `Continuation` instead? Or does it mean: the only method we expect here if declaringClass is `Continuation` is `yield0`, so the line below should only filter out `Continuation::yield0`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310422354 From fbredberg at openjdk.org Wed Aug 30 15:24:01 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 30 Aug 2023 15:24:01 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames [v2] In-Reply-To: References: Message-ID: <9M6TjPmr-LAzujWGq-BCDgL0gZUTxS9cAwamHSJIegs=.b9b70cd8-cccf-4f0d-b99e-87d0325cf33e@github.com> > Implementation of relativized extended_sp in interpreter frames for AArch64 and RISC-V. > > By changing the "extended_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "extended_sp". The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on aarch64. RISC-V was sanity tested using Qemu. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Updated aarch64 after review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15468/files - new: https://git.openjdk.org/jdk/pull/15468/files/b67579df..1256fe65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15468&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15468&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15468.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15468/head:pull/15468 PR: https://git.openjdk.org/jdk/pull/15468 From fbredberg at openjdk.org Wed Aug 30 15:24:04 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 30 Aug 2023 15:24:04 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames [v2] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 13:31:09 GMT, Andrew Haley wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated aarch64 after review > > src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp line 89: > >> 87: Label L; >> 88: ldr(rscratch1, Address(rfp, frame::interpreter_frame_extended_sp_offset * wordSize)); >> 89: lea(rscratch1, Address(rfp, rscratch1, Address::lsl(3))); > > Suggestion: > > lea(rscratch1, Address(rfp, rscratch1, Address::lsl(LogBytesPerWord))); Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15468#discussion_r1310441531 From alanb at openjdk.org Wed Aug 30 15:34:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Aug 2023 15:34:21 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: References: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> Message-ID: On Wed, 30 Aug 2023 15:03:27 GMT, Daniel Fuchs wrote: >> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision: >> >> - update mode to be int rather than long >> - update tests >> - Review feedback on javadoc > > src/java.base/share/classes/java/lang/StackStreamFactory.java line 694: > >> 692: // no method information is available; should just filter >> 693: // "Continuation::yield0". >> 694: return classFrames[index].declaringClass() == Continuation.class; > > Is that going to be an issue if by chance the frame is some other method on continuation? > Could that comment be clarified a bit? > I am not sure what is meant by `should just filter "Continuation::yield0"`; Does it mean: that's what we should do, but we can't, so we filter any method on `Continuation` instead? Or does it mean: the only method we expect here if declaringClass is `Continuation` is `yield0`, so the line below should only filter out `Continuation::yield0`? The Continuation frames around enter and yielding are hidden. Continuation.yield0 was the only frame that required special handling here, it may need to be re-checked to see if it is still required when using SHOW_HIDDEN_FRAMES. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310462843 From lmesnik at openjdk.org Wed Aug 30 16:15:23 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 30 Aug 2023 16:15:23 GMT Subject: Integrated: 8314835: gtest wrappers should be marked as flagless In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 00:31:34 GMT, Leonid Mesnik wrote: > The gtest wrappers don't accept external vm flags and no need to run with them. This pull request has now been integrated. Changeset: 1ea6463f Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/1ea6463fbb95258725ed4a11621ec662859a76e0 Stats: 7 lines in 3 files changed: 6 ins; 0 del; 1 mod 8314835: gtest wrappers should be marked as flagless Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/15462 From mchung at openjdk.org Wed Aug 30 16:32:16 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 30 Aug 2023 16:32:16 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: References: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> Message-ID: On Wed, 30 Aug 2023 07:09:34 GMT, Alan Bateman wrote: > The updated proposal/javadoc looks good, just in two minds on whether the overload with the varargs should be added. The Set.of factory methods make is really easy to use the existing getInstance(Set) method. Indeed, Set.of factory methods are easy to use. I'm okay with taking it out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1699497438 From lkorinth at openjdk.org Wed Aug 30 17:13:53 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 30 Aug 2023 17:13:53 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: <3xqrbByJLBJTDN1-C_aG0wwe6PFy09-tMyL0TwEn4Gc=.88dbe2a2-ad5d-4545-ab30-4a9e5312641f@github.com> On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import I have some ideas that I will work on that might lead to a new proposal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699542111 From stefank at openjdk.org Wed Aug 30 17:40:33 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 30 Aug 2023 17:40:33 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"` >> >> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling: >> >> /** >> * Create ProcessBuilder using the java launcher from the jdk to >> * be tested. >> * >> *

Please observe that you likely should use >> * createTestJvm() instead of this method because createTestJvm() >> * will add JVM options from "test.vm.opts" and "test.java.opts" >> * and this method will not do that. >> * >> * @param command Arguments to pass to the java command. >> * @return The ProcessBuilder instance representing the java command. >> */ >> >> >> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use... >> >> I have run tier 1 testing, and I have started more exhaustive testing. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > fix static import >From talking to other HotSpot devs it is quite clear that the different names lead to mistakes when writing (copy-n-pasting) tests, so I'm happy that we try to figure out some way to make it more obvious when we prepend the extra test options and when we don't. I agree with @msheppar that `createTestJvm` isn't a good name and I wouldn't be opposed to changing that name instead of `createJavaProcessBuilder`. However, if we do rename that function I strongly urge us to also rename the corresponding `executeTestJvm` function. I also think it is too obscure that functions with *Test* in the name prepend the extra test options, and those without *Test* don't, so I'd like to get rid of that convention. I wouldn't be opposed to a change that: * Keeps the `createJavaProcessBuilder` name * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts` * Renames `executeTestJvm` to `executeJavaPrependTestOpts` * Removes `createTestJava` * Removes `executeTestJava` ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699588853 From mchung at openjdk.org Wed Aug 30 18:09:34 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 30 Aug 2023 18:09:34 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: References: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> Message-ID: <7tOxwC_i6O7yPZUvq_7g2ocDI1KOERbjd_mblthaS_A=.a699200f-a696-4db4-b1c4-1af257c7ccee@github.com> On Wed, 30 Aug 2023 15:31:27 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/StackStreamFactory.java line 694: >> >>> 692: // no method information is available; should just filter >>> 693: // "Continuation::yield0". >>> 694: return classFrames[index].declaringClass() == Continuation.class; >> >> Is that going to be an issue if by chance the frame is some other method on continuation? >> Could that comment be clarified a bit? >> I am not sure what is meant by `should just filter "Continuation::yield0"`; Does it mean: that's what we should do, but we can't, so we filter any method on `Continuation` instead? Or does it mean: the only method we expect here if declaringClass is `Continuation` is `yield0`, so the line below should only filter out `Continuation::yield0`? > > The Continuation frames around enter and yielding are hidden. Continuation.yield0 was the only frame that required special handling here, it may need to be re-checked to see if it is still required when using SHOW_HIDDEN_FRAMES. Looks like the filtering is not needed. https://bugs.openjdk.org/browse/JDK-8304919 marked those methods with `@Hidden`. If `SHOW_HIDDEN_FRAMES` is set, those frames should be included unless there is a reason not to. I will update the patch to remove the filtering in both `StackFrameBuffer` and `ClassFrameBuffer`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310645327 From mli at openjdk.org Wed Aug 30 19:09:27 2023 From: mli at openjdk.org (Hamlin Li) Date: Wed, 30 Aug 2023 19:09:27 GMT Subject: RFR: 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize [v2] In-Reply-To: <82X0oUfWsiPcALA_ghgALdreCBgf3tE7Cg7-hdLogyk=.2667867e-5d2a-4fd8-bab6-a135863732fa@github.com> References: <82X0oUfWsiPcALA_ghgALdreCBgf3tE7Cg7-hdLogyk=.2667867e-5d2a-4fd8-bab6-a135863732fa@github.com> Message-ID: On Wed, 30 Aug 2023 09:49:32 GMT, Albert Mingkun Yang wrote: >> Use more precise type and range for `GCDrainStackTargetSize`. >> >> The change to `TASKQUEUE_SIZE` is there, because they are used in the same `MIN2`. (All uses expect `TASKQUEUE_SIZE` to be `uint` as well.) > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review LGTM. ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15472#pullrequestreview-1603334481 From evergizova at openjdk.org Wed Aug 30 19:24:00 2023 From: evergizova at openjdk.org (Ekaterina Vergizova) Date: Wed, 30 Aug 2023 19:24:00 GMT Subject: RFR: 8314220: Configurable InlineCacheBuffer size [v2] In-Reply-To: References: Message-ID: > InlineCacheBuffer size is currently hardcoded to 10K. > This can lead to multiple ICBufferFull safepoints for InlineCacheBuffer cleanup and possible performance degradation. > > Added experimental command line option InlineCacheBufferSize with the same default value, allowing it to be configured for performance experiments with ICBufferFull safepoints frequency. Ekaterina Vergizova has updated the pull request incrementally with one additional commit since the last revision: Changed type, added range check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15271/files - new: https://git.openjdk.org/jdk/pull/15271/files/e89b6430..69d603e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15271&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15271&range=00-01 Stats: 29 lines in 3 files changed: 28 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15271/head:pull/15271 PR: https://git.openjdk.org/jdk/pull/15271 From evergizova at openjdk.org Wed Aug 30 19:24:00 2023 From: evergizova at openjdk.org (Ekaterina Vergizova) Date: Wed, 30 Aug 2023 19:24:00 GMT Subject: RFR: 8314220: Configurable InlineCacheBuffer size In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 19:54:58 GMT, Dean Long wrote: > I like the idea of getting rid of this arbitrary limit, but it might be better to either: > > 1. scale the default size value based on the code cache size (ergonomics)? > 2. grow the buffer as needed, no size flag needed > I would prefer 2). @dean-long, good ideas, but they require some investigations and non-trivial changes. Maybe it's better to integrate this simple approach, that can be useful for performance experiments and can possibly be backported to 17u/11u due to its simplicity, and then implement one of your ideas separately? Since the suggested InlineCacheBufferSize option is experimental, it can be dropped later without any notice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15271#issuecomment-1699708946 From evergizova at openjdk.org Wed Aug 30 19:24:01 2023 From: evergizova at openjdk.org (Ekaterina Vergizova) Date: Wed, 30 Aug 2023 19:24:01 GMT Subject: RFR: 8314220: Configurable InlineCacheBuffer size [v2] In-Reply-To: References: Message-ID: On Mon, 14 Aug 2023 19:54:17 GMT, Coleen Phillimore wrote: >> Ekaterina Vergizova has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed type, added range check > > src/hotspot/share/runtime/globals.hpp line 299: > >> 297: \ >> 298: product(uintx, InlineCacheBufferSize, 10*K, EXPERIMENTAL, \ >> 299: "InlineCacheBuffer size") \ > > Can you make this type an int and add a range to it? Line 143 above will get -Wconversion warnings if we ever turned them on. Thanks, I changed type to int and added a range check constraint. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15271#discussion_r1310715607 From manc at openjdk.org Wed Aug 30 20:27:26 2023 From: manc at openjdk.org (Man Cao) Date: Wed, 30 Aug 2023 20:27:26 GMT Subject: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 07:44:07 GMT, David Holmes wrote: > This doesn't seem unreasonable, but I do wonder what impact this has on the GC threads to collect this data? We did some benchmarking when we first implemented these counters in our internal JDK 8. There was no observable performance difference. We could redo the benchmarking in JDK HEAD if people are concerned with accounting overhead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15082#issuecomment-1699788606 From kvn at openjdk.org Wed Aug 30 21:13:40 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 30 Aug 2023 21:13:40 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 03:13:08 GMT, Cesar Soares Lucas wrote: > I believe the factory methods for AddPNode should be in the AddPNode class. The make_load / make_store methods in PhaseMacroExpand can be refactored to instead just use the "make" methods from Load/Store classes. > > Tested with tier1-3. Good cleanup. My only suggestion is to keep `AddPNode::make()` and `PhaseValues::makecon()` in header files .hpp - they are small and no need to put to .cpp files. ------------- PR Review: https://git.openjdk.org/jdk/pull/15480#pullrequestreview-1603482700 From jjoo at openjdk.org Wed Aug 30 22:58:41 2023 From: jjoo at openjdk.org (Jonathan Joo) Date: Wed, 30 Aug 2023 22:58:41 GMT Subject: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v2] In-Reply-To: References: Message-ID: > 8315149: Add hsperf counters for CPU time of internal GC threads Jonathan Joo has updated the pull request incrementally with one additional commit since the last revision: address dholmes@ comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15082/files - new: https://git.openjdk.org/jdk/pull/15082/files/6c32e93d..557dbfa6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15082&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15082&range=00-01 Stats: 5 lines in 3 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15082/head:pull/15082 PR: https://git.openjdk.org/jdk/pull/15082 From myano at openjdk.org Thu Aug 31 00:21:15 2023 From: myano at openjdk.org (Masanori Yano) Date: Thu, 31 Aug 2023 00:21:15 GMT Subject: Withdrawn: 8308751: Create new switch to print error reporting output to both hs_err_pid file and stdout/stderr In-Reply-To: References: Message-ID: <9wmFf-wA4316FrovrPDhpOmvVC8dS7dj3OGIUDPlD4Y=.130a6902-84fe-4912-8d29-cf4c44966c97@github.com> On Wed, 24 May 2023 08:15:29 GMT, Masanori Yano wrote: > I think it makes sense to add the ErrorFileWithStdout and ErrorFileWithStderr for troubleshooting. > I would appriciate if someone could review it. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14114 From cslucas at openjdk.org Thu Aug 31 00:58:44 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 31 Aug 2023 00:58:44 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v2] In-Reply-To: References: Message-ID: > I believe the factory methods for AddPNode should be in the AddPNode class. The make_load / make_store methods in PhaseMacroExpand can be refactored to instead just use the "make" methods from Load/Store classes. > > Tested with tier1-3. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: move definitions to hpp files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15480/files - new: https://git.openjdk.org/jdk/pull/15480/files/776b202c..5d988b01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15480&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15480&range=00-01 Stats: 42 lines in 4 files changed: 13 ins; 24 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15480/head:pull/15480 PR: https://git.openjdk.org/jdk/pull/15480 From kvn at openjdk.org Thu Aug 31 02:55:01 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 31 Aug 2023 02:55:01 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v2] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 00:58:44 GMT, Cesar Soares Lucas wrote: >> I believe the factory methods for AddPNode should be in the AddPNode class. The make_load / make_store methods in PhaseMacroExpand can be refactored to instead just use the "make" methods from Load/Store classes. >> >> Tested with tier1-3. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > move definitions to hpp files Good. You need second review. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15480#pullrequestreview-1603781408 From dholmes at openjdk.org Thu Aug 31 05:48:04 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 31 Aug 2023 05:48:04 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 11:31:20 GMT, Mark Sheppard wrote: > So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g. createJavaProcessBuilder(List command, boolean addTestOpts) { ... } @msheppar that is actually where we started, and it was then split into two differently named methods to "make it clear" which one included the test opts without having to remember the name of the parameter that the true/false argument was bound to. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700402301 From dholmes at openjdk.org Thu Aug 31 05:54:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 31 Aug 2023 05:54:10 GMT Subject: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v2] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 22:58:41 GMT, Jonathan Joo wrote: >> 8315149: Add hsperf counters for CPU time of internal GC threads > > Jonathan Joo has updated the pull request incrementally with one additional commit since the last revision: > > address dholmes@ comments src/hotspot/share/gc/shared/collectedHeap.cpp line 280: > 278: _perf_parallel_gc_threads_cpu_time = > 279: PerfDataManager::create_variable(NULL_NS, "par_gc_thread_time", > 280: PerfData::U_Ticks, CHECK); Shouldn't this initialization be guarded like the others? src/hotspot/share/runtime/vmThread.cpp line 142: > 140: _perf_vm_thread_cpu_time = > 141: PerfDataManager::create_variable(NULL_NS, "vm_thread_time", > 142: PerfData::U_Ticks, CHECK); Again should not this initialization be guarded like the others. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1311123866 PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1311124544 From dholmes at openjdk.org Thu Aug 31 05:58:04 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 31 Aug 2023 05:58:04 GMT Subject: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v2] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 22:58:41 GMT, Jonathan Joo wrote: >> 8315149: Add hsperf counters for CPU time of internal GC threads > > Jonathan Joo has updated the pull request incrementally with one additional commit since the last revision: > > address dholmes@ comments src/hotspot/share/gc/shared/stringdedup/stringDedupThread.hpp line 44: > 42: > 43: // Perf data for CPU time consumed by the string dedup thread. > 44: static PerfVariable* _g1_concurrent_dedup_thread_cpu_time; This variable seems unused. ?? src/hotspot/share/runtime/vmThread.hpp line 129: > 127: static PerfVariable* perf_vm_thread_cpu_time() { > 128: return _perf_vm_thread_cpu_time; > 129: } Why do you need an accessor for the cpu-time variable in the VMThread but none of the others? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1311127306 PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1311126570 From alanb at openjdk.org Thu Aug 31 06:51:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 31 Aug 2023 06:51:00 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote: > I wouldn't be opposed to a change that: > > * Keeps the `createJavaProcessBuilder` name > * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts` > * Renames `executeTestJvm` to `executeJavaPrependTestOpts` > * Removes `createTestJava` > * Removes `executeTestJava` The good thing with this is that it very explicit at the use-sites where the test opts are prepended. Also moving from "Jvm" to "Java" is probably right as it executes the "java" launcher, the options are a mix of java launcher options (that the VM doesn't know about) and VM options. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700459277 From chagedorn at openjdk.org Thu Aug 31 07:09:01 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 31 Aug 2023 07:09:01 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v2] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 00:58:44 GMT, Cesar Soares Lucas wrote: >> I believe the factory methods for AddPNode should be in the AddPNode class. The make_load / make_store methods in PhaseMacroExpand can be refactored to instead just use the "make" methods from Load/Store classes. >> >> Tested with tier1-3. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > move definitions to hpp files Otherwise, the clean-up looks good. src/hotspot/share/opto/addnode.hpp line 177: > 175: > 176: // Helper methods roughly modeled after GraphKit: > 177: static Node* make(PhaseIterGVN* igvn, Node* base, Node* ptr, Node* offset) { I suggest to pass `igvn` as reference here (i.e. `PhaseIterGVN&`) and below. Then you can avoid to use `&igvn()` in the code and just pass it as reference directly. src/hotspot/share/opto/macro.cpp line 1683: > 1681: > 1682: Node* memadr = AddPNode::make(&_igvn, object, oopDesc::mark_offset_in_bytes()); > 1683: rawmem = transform_later(StoreNode::make(_igvn, control, rawmem, memadr, nullptr, mark_node, TypeX_X->basic_type(), MemNode::unordered)); You could still think about keeping `make_load/store()` and just replace `basic_plus_adr()` with `AddPNode::make()` there which might make it easier to read the code here. But both is fine and I leave it up to you to decide. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15480#pullrequestreview-1604052768 PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1311168043 PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1311173320 From alanb at openjdk.org Thu Aug 31 07:23:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 31 Aug 2023 07:23:09 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8] In-Reply-To: References: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com> Message-ID: On Wed, 30 Aug 2023 16:29:31 GMT, Mandy Chung wrote: > Indeed, Set.of factory methods are easy to use. I'm okay with taking it out. It would be easy to add in the future if needed, say if more options were introduced and the common case requires 2 or more options. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1700499172 From david.holmes at oracle.com Thu Aug 31 07:25:25 2023 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Aug 2023 17:25:25 +1000 Subject: SelectorManager threads are discriminated in race to get threads_lock mutex In-Reply-To: References: Message-ID: On 30/08/2023 8:56 pm, Kern, Joachim wrote: > Hi guys, > > The ContinuationFrameTest.java > on AIX fails to end within the gracedelay period. > > The gracedelay period function in** ReferenceTracker.java > effectively does the following:** > > for (i = 0; i < 50; i++) { > > ??????????? if (!TRACKERS.stream().anyMatch(hasOutstanding)) > > ????????????????break; > > ??????????? System.gc(); > > ??????????? Thread.sleep(10); > > } > > During this grace period there are at least 3 thread categories fighting > for the threads_lockmutex. > > 1.TheSafepointSynchronize > ::begin () locks thethreads_lock mutex for the gc. It holds the mutex for about 300ms. > > 2.The wait_until_not_protected()function, which is called a dozen times > during one loop iteration. It holds the mutex for about 0.4ms. > > 3.And the SelectorManager threads which need the mutex one time to > complete their shutdown. They need the mutex for about 0.5ms. #2 and #3 are related as wait_until_not_protected is used during thread termination and detaching (for JNI attached threads). > The threads of all three categories are running with _identical_ native > thread priority . > > On the various Linux derivates(x86 and ppc64) you can see, that the > SelectorManagerthreads are finding slots between the other mutex > consumers, so that all threads are shutdown within about 7 loop iterations. > > On AIX the SelectorManagerthreads can?t make it or less often. So, some > of them are still alive after the complete grace period, although they > were queued up even before the grace period. This means in total 50 > iterations where their requests were ignored and all later coming > requests from 1.+2. were satisfied. > > So, how are the thread priorities handled in hotspot. Why are the AIX > SelectorManagerthreads discriminated. By default they are ignored - see os::set_native_priority for each OS and note that ThreadPriorityPolicy == 0 by default. > Can you please help me with an idea. It is probably more the barging/queuing policy of the mutex implementation than actual thread scheduling priority. But that would be a question for the AIX developers. Cheers, David ----- > Greetings > > Joachim > From ayang at openjdk.org Thu Aug 31 09:52:12 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 31 Aug 2023 09:52:12 GMT Subject: RFR: 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize [v2] In-Reply-To: <82X0oUfWsiPcALA_ghgALdreCBgf3tE7Cg7-hdLogyk=.2667867e-5d2a-4fd8-bab6-a135863732fa@github.com> References: <82X0oUfWsiPcALA_ghgALdreCBgf3tE7Cg7-hdLogyk=.2667867e-5d2a-4fd8-bab6-a135863732fa@github.com> Message-ID: On Wed, 30 Aug 2023 09:49:32 GMT, Albert Mingkun Yang wrote: >> Use more precise type and range for `GCDrainStackTargetSize`. >> >> The change to `TASKQUEUE_SIZE` is there, because they are used in the same `MIN2`. (All uses expect `TASKQUEUE_SIZE` to be `uint` as well.) > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15472#issuecomment-1700718268 From ayang at openjdk.org Thu Aug 31 09:52:14 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 31 Aug 2023 09:52:14 GMT Subject: Integrated: 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize In-Reply-To: References: Message-ID: On Tue, 29 Aug 2023 16:15:44 GMT, Albert Mingkun Yang wrote: > Use more precise type and range for `GCDrainStackTargetSize`. > > The change to `TASKQUEUE_SIZE` is there, because they are used in the same `MIN2`. (All uses expect `TASKQUEUE_SIZE` to be `uint` as well.) This pull request has now been integrated. Changeset: b0353add Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/b0353addf2bb649f98db7194a110c2152c0ed58b Stats: 9 lines in 4 files changed: 0 ins; 2 del; 7 mod 8315242: G1: Fix -Wconversion warnings around GCDrainStackTargetSize Reviewed-by: tschatzl, mli ------------- PR: https://git.openjdk.org/jdk/pull/15472 From msheppar at openjdk.org Thu Aug 31 10:11:02 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 31 Aug 2023 10:11:02 GMT Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 05:45:27 GMT, David Holmes wrote: > > So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g. > > createJavaProcessBuilder(List command, boolean addTestOpts) { ... } > > @msheppar that is actually where we started, and it was then split into two differently named methods to "make it clear" which one included the test opts without having to remember the name of the parameter that the true/false argument was bound to. cheers David thanks for the clarification on background ------------- PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700749844 From fbredberg at openjdk.org Thu Aug 31 12:05:40 2023 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 31 Aug 2023 12:05:40 GMT Subject: RFR: 8315069: Relativize extended_sp in interpreter frames [v3] In-Reply-To: References: Message-ID: > Implementation of relativized extended_sp in interpreter frames for AArch64 and RISC-V. > > By changing the "extended_sp" member in interpreter frames from being an absolute address into an offset that is relative to the frame pointer, we don't need to change the value as we freeze and thaw frames of virtual threads. This is since we might freeze and thaw from and to different worker threads, so the absolute address to locals might change, but the offset from the frame pointer will be constant. > > This subtask only handles "extended_sp". The relativization of other interpreter frame members are handled in other subtasks to JDK-8289296. > > Tested tier1-tier7 on aarch64. RISC-V was sanity tested using Qemu. Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8315069_relativize_extended_sp - Updated aarch64 after review - 8315069: Relativize extended_sp in interpreter frames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15468/files - new: https://git.openjdk.org/jdk/pull/15468/files/1256fe65..d9f2e389 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15468&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15468&range=01-02 Stats: 14505 lines in 454 files changed: 9536 ins; 2580 del; 2389 mod Patch: https://git.openjdk.org/jdk/pull/15468.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15468/head:pull/15468 PR: https://git.openjdk.org/jdk/pull/15468 From dchuyko at openjdk.org Thu Aug 31 12:07:25 2023 From: dchuyko at openjdk.org (Dmitry Chuyko) Date: Thu, 31 Aug 2023 12:07:25 GMT Subject: RFR: 8309271: A way to align already compiled methods with compiler directives [v6] In-Reply-To: References: Message-ID: > Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack. > > A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers. > > It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives (so bypass inlined methods). > > Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Prior to that we can try to re-compile the method letting compile broker to perform it taking new directives stack into account. Re-compilation helps to prevent hot methods from execution in the interpreter. > > A new flag `-r` has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and puts methods that have any active non-default matching compiler directives to re-compilation if possible, otherwise marks them for deoptimization. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be refreshed. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be refreshed, but this can be achieved by having rules for them. > > In addition, a new diagnostic command `Compiler.replace_directives`, has been added for ... Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'openjdk:master' into compiler-directives-force-update - jcheck - Unnecessary import - force_update->refresh - Merge branch 'openjdk:master' into compiler-directives-force-update - Use only top directive for add/remove; better mutex rank definition; texts - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Safe handling of non-java methods - Merge branch 'openjdk:master' into compiler-directives-force-update - ... and 14 more: https://git.openjdk.org/jdk/compare/145d8bc1...b4eb6de0 ------------- Changes: https://git.openjdk.org/jdk/pull/14111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=05 Stats: 372 lines in 15 files changed: 339 ins; 3 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/14111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111 PR: https://git.openjdk.org/jdk/pull/14111 From gavrilinid at gmail.com Thu Aug 31 15:08:29 2023 From: gavrilinid at gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0JPQsNCy0YDQuNC70LjQvQ==?=) Date: Thu, 31 Aug 2023 18:08:29 +0300 Subject: UseVectorizedMismatchIntrinsic option on RISC-V Message-ID: Hi, On RISC-V we don`t have a node for VectorizedMismatch, and when -XX:+UseVectorizedMismatchIntrinsic option set we got a fatal error caused by: https://github.com/openjdk/jdk/blob/29ff1e45b910c07711c4f4c3d821712dd9a1e3ba/src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp#L803-L805. On other architectures where we don`t have such intrinsic we got only warning. Also, on RISC-V for unimplemented intrinsics like _updateCRC32, _updateCRC32C when we turn on UseCRC32Intrinsics option only warning produced on output. Do we have any reasons to throw a fatal error in VectorizedMismatch? Can we throw a warning when the UseVectorizedMismatchIntrinsic option is turned on? Changes example available here: https://github.com/Ilyagavrilin/jdk/commit/a6d15bb92875785d3493249d4392cff643ae02f7 With best regards, Ilya -------------- next part -------------- An HTML attachment was scrubbed... URL: From cslucas at openjdk.org Thu Aug 31 15:37:02 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 31 Aug 2023 15:37:02 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v2] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 06:47:10 GMT, Christian Hagedorn wrote: >> Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: >> >> move definitions to hpp files > > src/hotspot/share/opto/addnode.hpp line 177: > >> 175: >> 176: // Helper methods roughly modeled after GraphKit: >> 177: static Node* make(PhaseIterGVN* igvn, Node* base, Node* ptr, Node* offset) { > > I suggest to pass `igvn` as reference here (i.e. `PhaseIterGVN&`) and below. Then you can avoid to use `&igvn()` in the code and just pass it as reference directly. That's a good idea. Thanks! > src/hotspot/share/opto/macro.cpp line 1683: > >> 1681: >> 1682: Node* memadr = AddPNode::make(&_igvn, object, oopDesc::mark_offset_in_bytes()); >> 1683: rawmem = transform_later(StoreNode::make(_igvn, control, rawmem, memadr, nullptr, mark_node, TypeX_X->basic_type(), MemNode::unordered)); > > You could still think about keeping `make_load/store()` and just replace `basic_plus_adr()` with `AddPNode::make()` there which might make it easier to read the code here. But both is fine and I leave it up to you to decide. Yeah, I actually tried that but the reuse of make_load/store wasn't justifiable without a much bigger refactor. I'll leave that refactor for another PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1311821426 PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1311823254 From cslucas at openjdk.org Thu Aug 31 16:05:32 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 31 Aug 2023 16:05:32 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v3] In-Reply-To: References: Message-ID: > I believe the factory methods for AddPNode should be in the AddPNode class. The make_load / make_store methods in PhaseMacroExpand can be refactored to instead just use the "make" methods from Load/Store classes. > > Tested with tier1-3. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Use reference instead of pointer. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15480/files - new: https://git.openjdk.org/jdk/pull/15480/files/5d988b01..c4205846 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15480&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15480&range=01-02 Stats: 30 lines in 7 files changed: 0 ins; 0 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/15480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15480/head:pull/15480 PR: https://git.openjdk.org/jdk/pull/15480 From vlivanov at openjdk.org Thu Aug 31 16:32:03 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 31 Aug 2023 16:32:03 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v3] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 16:05:32 GMT, Cesar Soares Lucas wrote: >> I believe the factory methods for AddPNode should be in the AddPNode class. The make_load / make_store methods in PhaseMacroExpand can be refactored to instead just use the "make" methods from Load/Store classes. >> >> Tested with tier1-3. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Use reference instead of pointer. src/hotspot/share/opto/addnode.hpp line 181: > 179: } > 180: > 181: static Node* make(PhaseIterGVN& igvn, Node* base, int offset) { The overloads do look confusing now. When seeing a call to a factory method, I expect to see all inputs to be separately initialized. With `basic_plus_adr` the intention was clearer. I'm not against the refactoring, but it feels like it moves the code in the wrong direction. The root problem is that we can't use `GraphKit `during macro expansion, so we duplicated functionality there over time. (`PhaseIdealLoop` is another victim.) A better way would be to use `GraphKit` directly. And when we discussed it last time [1], Roland mentioned it was already implemented in Valhalla repo. [1] https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2020-August/039612.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1311898349 From cslucas at openjdk.org Thu Aug 31 16:45:09 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 31 Aug 2023 16:45:09 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v3] In-Reply-To: References: Message-ID: On Thu, 31 Aug 2023 16:28:55 GMT, Vladimir Ivanov wrote: > I expect to see all inputs to be separately initialized. I'm not sure what you mean by this part. Can you elaborate a little here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1311912885 From vlivanov at openjdk.org Thu Aug 31 17:06:04 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 31 Aug 2023 17:06:04 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v3] In-Reply-To: References: Message-ID: <3_ThxcuU3e_hPvWi4lJBfXsyG4Ky_eyyifbkZ2izlKQ=.0070b59a-31ae-4ede-9625-a9e4bf3b7a16@github.com> On Thu, 31 Aug 2023 16:42:12 GMT, Cesar Soares Lucas wrote: >> src/hotspot/share/opto/addnode.hpp line 181: >> >>> 179: } >>> 180: >>> 181: static Node* make(PhaseIterGVN& igvn, Node* base, int offset) { >> >> The overloads do look confusing now. When seeing a call to a factory method, I expect to see all inputs to be separately initialized. With `basic_plus_adr` the intention was clearer. >> >> I'm not against the refactoring, but it feels like it moves the code in the wrong direction. The root problem is that we can't use `GraphKit `during macro expansion, so we duplicated functionality there over time. (`PhaseIdealLoop` is another victim.) >> >> A better way would be to use `GraphKit` directly. And when we discussed it last time [1], Roland mentioned it was already implemented in Valhalla repo. >> >> [1] https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2020-August/039612.html > >> I expect to see all inputs to be separately initialized. > > I'm not sure what you mean by this part. Can you elaborate a little here? static Node* make(PhaseIterGVN& igvn, Node* base, Node* ptr, Node* offset) { return igvn.register_new_node_with_optimizer(new AddPNode(base, ptr, offset)); } vs static Node* make(PhaseIterGVN& igvn, Node* base, int offset) { return (offset == 0) ? base : make(igvn, base, base, (Node*) igvn.makecon(offset)); } IMO latter case adds more confusion than improves readability. Why not unconditionally call `AddPNode::make(base, base, offset)` instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1311936070 From mchung at openjdk.org Thu Aug 31 17:09:40 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 31 Aug 2023 17:09:40 GMT Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9] In-Reply-To: References: Message-ID: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com> > 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks > like logging may only interest in the Class object but not the method name nor the BCI, > for example, filters out its implementation classes to find the caller class. It's > similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element. > > This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information. If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO` > can be used instead and such stack walker will save the overhead of extracting the method information > and the memory used for the stack walking. > > New factory methods to take a parameter to specify the kind of stack walker to be created are defined. > This provides a simple way for existing code, for example logging frameworks, to take advantage of > this enhancement with the least change as it can keep the existing function for traversing > `StackFrame`s. > > For example: to find the first caller filtering a known list of implementation class, > existing code can create a stack walker instance with `DROP_METHOD_INFO` option: > > > StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE); > Optional> callerClass = walker.walk(s -> > s.map(StackFrame::getDeclaringClass) > .filter(Predicate.not(implClasses::contains)) > .findFirst()); > > > If method information is accessed on the `StackFrame`s produced by this stack walker such as > `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown. > > #### Javadoc & specdiff > > https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html > https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html > > #### Alternatives Considered > One alternative is to provide a new API: > ` T walkClass(Function, ? extends T> function)` > > In this case, the caller would need to pass a function that takes a stream > of `Class` object instead of `StackFrame`. Existing code would have to > modify calls to the `walk` method to `walkClass` and the function body. > > ### Implementation Details > > A `StackWalker` configured with `DROP_METHOD_INFO` option creates `ClassFrameInfo[]` > buffer that is filled by the VM during stack walking. `Sta... Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge - Remove the new getInstance method taking varargs - update mode to be int rather than long - update tests - Review feedback on javadoc - Revised the API change. Add Option::DROP_METHOD_INFO - Review feedback from Remi - fixup javadoc - Review feedback: move JLIA to ClassFrameInfo - review feedback and javadoc clean up - ... and 19 more: https://git.openjdk.org/jdk/compare/c8acab1d...111661bc ------------- Changes: https://git.openjdk.org/jdk/pull/15370/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=08 Stats: 1256 lines in 34 files changed: 690 ins; 276 del; 290 mod Patch: https://git.openjdk.org/jdk/pull/15370.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370 PR: https://git.openjdk.org/jdk/pull/15370 From shade at openjdk.org Thu Aug 31 17:23:05 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 31 Aug 2023 17:23:05 GMT Subject: RFR: 8313202: MutexLocker should disallow null Mutexes [v5] In-Reply-To: <5JqYLMqwPshUm2wyR1rQHndI08xNyDDkj1EqrJwIl3k=.11918918-a906-48ca-8053-e8fa8648d8cd@github.com> References: <5JqYLMqwPshUm2wyR1rQHndI08xNyDDkj1EqrJwIl3k=.11918918-a906-48ca-8053-e8fa8648d8cd@github.com> Message-ID: On Thu, 24 Aug 2023 07:55:01 GMT, Aleksey Shipilev wrote: >> As seen in [JDK-8313081](https://bugs.openjdk.org/browse/JDK-8313081), it is fairly easy to pass nullptr `Mutex` to `MutexLocker` by accident, which would just silently avoid the lock. >> >> There are a few places in Hotspot where we pass `nullptr` to simulate re-entrancy and/or conditionally take the lock. Those places can be more explicit, and the default `MutexLocker` can disallow nullptrs for extra safety. >> >> More thorough testing with different GC/JIT combinations is running now, we might find more issues there. Meanwhile, please comment on the approach. >> >> Additional testing: >> - [x] `grep -R "MutexLocker " src/hotspot | grep -i null`, only new `ConditionalMutexLocker` hits >> - [x] `grep -R "MutexLocker " src/hotspot | grep -i ?`, no hits >> - [x] Linux AArch64 fastdebug, `tier1 tier2 tier3` x `Serial Parallel G1 Shenandoah` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'master' into JDK-8313202-mutexlocker-nulls > - Merge branch 'master' into JDK-8313202-mutexlocker-nulls > - Accept one more potentially nullptr mutex > - Merge branch 'master' into JDK-8313202-mutexlocker-nulls > - Replace ReentrantMutexLocker with ConditionalMutexLocker > - Workaround for JDK-8313210 > - Fixing CodeCache analytics > - Initial work I have finally managed to pass different combinations of GCs and compilers on current mainline, and no new bugs found. I plan to integrate early next week, unless there are other suggestions to this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15043#issuecomment-1701449194 From stuefe at openjdk.org Thu Aug 31 18:14:23 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 31 Aug 2023 18:14:23 GMT Subject: RFR: JDK-8314890: Reduce number of loads for Klass decoding in static code [v4] In-Reply-To: References: Message-ID: > Small change that reduces the number of loads generated by the C++ compiler for a narrow Klass decoding operation (`CompressedKlassPointers::decode_xxx()`. > > Stock: three loads (with two probably sharing a cache line) - UseCompressedClassPointers, encoding base and shift. > > > 8b7b62: 48 8d 05 7f 1b c3 00 lea 0xc31b7f(%rip),%rax # 14e96e8 > 8b7b69: 0f b6 00 movzbl (%rax),%eax > 8b7b6c: 84 c0 test %al,%al > 8b7b6e: 0f 84 9c 00 00 00 je 8b7c10 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> > 8b7b74: 48 8d 15 05 62 c6 00 lea 0xc66205(%rip),%rdx # 151dd80 <_ZN23CompressedKlassPointers6_shiftE> > 8b7b7b: 8b 7b 08 mov 0x8(%rbx),%edi > 8b7b7e: 8b 0a mov (%rdx),%ecx > 8b7b80: 48 8d 15 01 62 c6 00 lea 0xc66201(%rip),%rdx # 151dd88 <_ZN23CompressedKlassPointers5_baseE> > 8b7b87: 48 d3 e7 shl %cl,%rdi > 8b7b8a: 48 03 3a add (%rdx),%rdi > > > Patched: one load loads all three. Since shift occupies the lowest 8 bits, compiled code uses 8bit register; ditto the UseCompressedOops flag. > > > 8ba302: 48 8d 05 97 9c c2 00 lea 0xc29c97(%rip),%rax # 14e3fa0 <_ZN23CompressedKlassPointers6_comboE> > 8ba309: 48 8b 08 mov (%rax),%rcx > 8ba30c: f6 c5 01 test $0x1,%ch # use compressed klass pointers? > 8ba30f: 0f 84 9b 00 00 00 je 8ba3b0 <_ZN10HeapRegion14object_iterateEP13ObjectClosure+0x260> > 8ba315: 8b 7b 08 mov 0x8(%rbx),%edi > 8ba318: 48 d3 e7 shl %cl,%rdi # shift > 8ba31b: 66 31 c9 xor %cx,%cx # zero out lower 16 bits of base > 8ba31e: 48 01 cf add %rcx,%rdi # add base > 8ba321: 8b 4f 08 mov 0x8(%rdi),%ecx > > --- > > Performance measurements: > > G1, doing a full GC over a heap filled with 256 mio life j.l.Object instances. > > I see a reduction of Full Pause times between 1.2% and 5%. I am unsure how reliable these numbers are since, despite my efforts (running tests on isolated CPUs etc.), the standard deviation was quite high at ?4%. Still, in general, numbers seemed to go down rather than up. > > --- > > Future extensions: > > This patch uses the fact that the encoding base is aligned to metaspace reserve alignment (16 Mb). We only use 16 of those 24 bits of alignment shadow and could us... Thomas Stuefe 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 branch 'openjdk:master' into optimize-narrow-klass-decoding-in-c++ - APH feedback - Merge branch 'master' into optimize-narrow-klass-decoding-in-c++ - fix -UseCCP case - use 16 bit alignment - with raw bit ops ------------- Changes: https://git.openjdk.org/jdk/pull/15389/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15389&range=03 Stats: 63 lines in 3 files changed: 37 ins; 13 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/15389.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15389/head:pull/15389 PR: https://git.openjdk.org/jdk/pull/15389 From cslucas at openjdk.org Thu Aug 31 20:36:04 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 31 Aug 2023 20:36:04 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v3] In-Reply-To: <3_ThxcuU3e_hPvWi4lJBfXsyG4Ky_eyyifbkZ2izlKQ=.0070b59a-31ae-4ede-9625-a9e4bf3b7a16@github.com> References: <3_ThxcuU3e_hPvWi4lJBfXsyG4Ky_eyyifbkZ2izlKQ=.0070b59a-31ae-4ede-9625-a9e4bf3b7a16@github.com> Message-ID: On Thu, 31 Aug 2023 17:02:49 GMT, Vladimir Ivanov wrote: >>> I expect to see all inputs to be separately initialized. >> >> I'm not sure what you mean by this part. Can you elaborate a little here? > > static Node* make(PhaseIterGVN& igvn, Node* base, Node* ptr, Node* offset) { > return igvn.register_new_node_with_optimizer(new AddPNode(base, ptr, offset)); > } > > vs > > static Node* make(PhaseIterGVN& igvn, Node* base, int offset) { > return (offset == 0) ? base : make(igvn, base, base, (Node*) igvn.makecon(offset)); > } > > > IMO latter case adds more confusion than improves readability. Why not unconditionally call `AddPNode::make(base, base, offset)` instead? Thanks for clarifying @iwanowww . I think I see your point now. My original intent was to just move these methods out of PhaseMacroExpand and not much else. I'm going to do some more refactoring and patch all users of these make methods to just use this single method: `static Node* make(PhaseIterGVN& igvn, Node* base, Node* ptr, Node* offset)`. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1312197579 From vlivanov at openjdk.org Thu Aug 31 20:59:09 2023 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 31 Aug 2023 20:59:09 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v3] In-Reply-To: References: <3_ThxcuU3e_hPvWi4lJBfXsyG4Ky_eyyifbkZ2izlKQ=.0070b59a-31ae-4ede-9625-a9e4bf3b7a16@github.com> Message-ID: On Thu, 31 Aug 2023 20:32:56 GMT, Cesar Soares Lucas wrote: >> static Node* make(PhaseIterGVN& igvn, Node* base, Node* ptr, Node* offset) { >> return igvn.register_new_node_with_optimizer(new AddPNode(base, ptr, offset)); >> } >> >> vs >> >> static Node* make(PhaseIterGVN& igvn, Node* base, int offset) { >> return (offset == 0) ? base : make(igvn, base, base, (Node*) igvn.makecon(offset)); >> } >> >> >> IMO latter case adds more confusion than improves readability. Why not unconditionally call `AddPNode::make(base, base, offset)` instead? > > Thanks for clarifying @iwanowww . I think I see your point now. My original intent was to just move these methods out of PhaseMacroExpand and not much else. > > I'm going to do some more refactoring and patch all users of these make methods to just use this single method: `static Node* make(PhaseIterGVN& igvn, Node* base, Node* ptr, Node* offset)`. What do you think? Sounds good. But in the future I'd like to see `PhaseMacroExpand` and `PhaseIdealLoop` migrated to `GraphKit` instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1312206706 From cslucas at openjdk.org Thu Aug 31 21:22:51 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 31 Aug 2023 21:22:51 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v3] In-Reply-To: References: <3_ThxcuU3e_hPvWi4lJBfXsyG4Ky_eyyifbkZ2izlKQ=.0070b59a-31ae-4ede-9625-a9e4bf3b7a16@github.com> Message-ID: On Thu, 31 Aug 2023 20:42:39 GMT, Vladimir Ivanov wrote: >> Thanks for clarifying @iwanowww . I think I see your point now. My original intent was to just move these methods out of PhaseMacroExpand and not much else. >> >> I'm going to do some more refactoring and patch all users of these make methods to just use this single method: `static Node* make(PhaseIterGVN& igvn, Node* base, Node* ptr, Node* offset)`. What do you think? > > Sounds good. > > But in the future I'd like to see `PhaseMacroExpand` and `PhaseIdealLoop` migrated to `GraphKit` instead. Actually, I think it's silly to create a method to just do a "return ... new AddP": static Node* make(PhaseIterGVN& igvn, Node* base, Node* ptr, Node* offset) { return igvn.register_new_node_with_optimizer(new AddPNode(base, ptr, offset)); } I can just replace the uses of this `make` with a `new AddP...`. > But in the future I'd like to see PhaseMacroExpand and PhaseIdealLoop migrated to GraphKit instead. Roger that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1312299405 From cslucas at openjdk.org Thu Aug 31 21:56:07 2023 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 31 Aug 2023 21:56:07 GMT Subject: RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v4] In-Reply-To: References: Message-ID: > I believe the factory methods for AddPNode should be in the AddPNode class. The make_load / make_store methods in PhaseMacroExpand can be refactored to instead just use the "make" methods from Load/Store classes. > > Tested with tier1-3. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Convert uses of AddPNode::make to new AddPNode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15480/files - new: https://git.openjdk.org/jdk/pull/15480/files/c4205846..943acfff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15480&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15480&range=02-03 Stats: 42 lines in 8 files changed: 1 ins; 18 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/15480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15480/head:pull/15480 PR: https://git.openjdk.org/jdk/pull/15480