From rkennke at openjdk.org Fri Feb 3 18:17:23 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 3 Feb 2023 18:17:23 GMT Subject: [master] RFR: Merge jdk:jdk-21+8 Message-ID: As subject says. 3 tests were failing after the merge: - runtime/CompressedOops/CompressedClassSpaceSize.java: according to @tstuefe, the test requires adjusting the minimum size. This is related to [JDK-8294677](https://bugs.openjdk.org/browse/JDK-8294677). - runtime/CompressedOops/CompressedClassPointerEncoding.java: This test is new in Lilliput. Some tests failed due to misaligned class space. I commented out those tests and filed [JDK-8301786](https://bugs.openjdk.org/browse/JDK-8301786). - compiler/c2/irTests/TestVectorizationNotRun.java: New test that starts failing, presumably because byte[] and long[] don't start at same offset in Lilliput. I problem-listed the test for now, and filed: [JDK-8301785](https://bugs.openjdk.org/browse/JDK-8301785). Testing: - [x] tier1 (aarch64/x86_64) - [x] tier2 (aarch64/x86_64) ------------- Commit messages: - Merge tag 'jdk-21+8' into merge-jdk-21+8 - 8294527: Some java.security.debug options missing from security docs - 8301447: [REDO] CodeHeap has virtual methods that are not overridden - 8295486: Inconsistent constant field values observed during compilation - 8301093: C2 fails assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out - 8300256: C2: vectorization is sometimes skipped on loops where it would succeed - 8301402: os::print_location gets is_global_handle assert - 8301446: Remove unused includes of gc/shared/genOopClosures - 8301459: Serial: Merge KeepAliveClosure into FastKeepAliveClosure - 8301570: Test runtime/jni/nativeStack/ needs to detach the native thread - ... and 451 more: https://git.openjdk.org/lilliput/compare/f9d0f393...e26f82a9 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=lilliput&pr=71&range=00.0 - jdk:jdk-21+8: https://webrevs.openjdk.org/?repo=lilliput&pr=71&range=00.1 Changes: https://git.openjdk.org/lilliput/pull/71/files Stats: 54667 lines in 2641 files changed: 22968 ins; 8800 del; 22899 mod Patch: https://git.openjdk.org/lilliput/pull/71.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/71/head:pull/71 PR: https://git.openjdk.org/lilliput/pull/71 From shade at openjdk.org Fri Feb 3 18:17:23 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 3 Feb 2023 18:17:23 GMT Subject: [master] RFR: Merge jdk:jdk-21+8 In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 09:38:35 GMT, Roman Kennke wrote: > As subject says. > > 3 tests were failing after the merge: > - runtime/CompressedOops/CompressedClassSpaceSize.java: according to @tstuefe, the test requires adjusting the minimum size. This is related to [JDK-8294677](https://bugs.openjdk.org/browse/JDK-8294677). > - runtime/CompressedOops/CompressedClassPointerEncoding.java: This test is new in Lilliput. Some tests failed due to misaligned class space. I commented out those tests and filed [JDK-8301786](https://bugs.openjdk.org/browse/JDK-8301786). > - compiler/c2/irTests/TestVectorizationNotRun.java: New test that starts failing, presumably because byte[] and long[] don't start at same offset in Lilliput. I problem-listed the test for now, and filed: [JDK-8301785](https://bugs.openjdk.org/browse/JDK-8301785). > > Testing: > - [x] tier1 (aarch64/x86_64) > - [x] tier2 (aarch64/x86_64) Marked as reviewed by shade (Committer). ------------- PR: https://git.openjdk.org/lilliput/pull/71 From rkennke at openjdk.org Fri Feb 3 18:23:03 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 3 Feb 2023 18:23:03 GMT Subject: [master] RFR: Merge jdk:jdk-21+8 [v2] In-Reply-To: References: Message-ID: > As subject says. > > 3 tests were failing after the merge: > - runtime/CompressedOops/CompressedClassSpaceSize.java: according to @tstuefe, the test requires adjusting the minimum size. This is related to [JDK-8294677](https://bugs.openjdk.org/browse/JDK-8294677). > - runtime/CompressedOops/CompressedClassPointerEncoding.java: This test is new in Lilliput. Some tests failed due to misaligned class space. I commented out those tests and filed [JDK-8301786](https://bugs.openjdk.org/browse/JDK-8301786). > - compiler/c2/irTests/TestVectorizationNotRun.java: New test that starts failing, presumably because byte[] and long[] don't start at same offset in Lilliput. I problem-listed the test for now, and filed: [JDK-8301785](https://bugs.openjdk.org/browse/JDK-8301785). > > Testing: > - [x] tier1 (aarch64/x86_64) > - [x] tier2 (aarch64/x86_64) Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits: - Merge tag 'jdk-21+8' into merge-jdk-21+8 Added tag jdk-21+8 for changeset bc750f70 - 8301514: [Lilliput] Enable fast-locking with ZGC Reviewed-by: shade - 8301545: [Lilliput] Fix aarch64 interpreter load_nklass() Reviewed-by: shade - 8300888: [Lilliput] Remaining missing parts in the SA Reviewed-by: shade - 8300527: [Lilliput] Simplify and optimize loading of Klass* Reviewed-by: shade - 8300733: [Lilliput] Enable fast-locking for Lilliput Reviewed-by: shade - 8300573: [Lilliput] Properly set ZF on anon-check path; avoid some conditional branches Reviewed-by: shade - 8300735: [Lilliput] Adjust GHA and jcheck config Reviewed-by: shade - 8300440: [Lilliput] Implement alternative fast-locking scheme Reviewed-by: shade - Merge jdk:jdk-21+4 Reviewed-by: shade - ... and 68 more: https://git.openjdk.org/lilliput/compare/bc750f70...e26f82a9 ------------- Changes: https://git.openjdk.org/lilliput/pull/71/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=71&range=01 Stats: 6192 lines in 255 files changed: 4089 ins; 934 del; 1169 mod Patch: https://git.openjdk.org/lilliput/pull/71.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/71/head:pull/71 PR: https://git.openjdk.org/lilliput/pull/71 From rkennke at openjdk.org Fri Feb 3 18:23:07 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 3 Feb 2023 18:23:07 GMT Subject: [master] Integrated: Merge jdk:jdk-21+8 In-Reply-To: References: Message-ID: On Fri, 3 Feb 2023 09:38:35 GMT, Roman Kennke wrote: > As subject says. > > 3 tests were failing after the merge: > - runtime/CompressedOops/CompressedClassSpaceSize.java: according to @tstuefe, the test requires adjusting the minimum size. This is related to [JDK-8294677](https://bugs.openjdk.org/browse/JDK-8294677). > - runtime/CompressedOops/CompressedClassPointerEncoding.java: This test is new in Lilliput. Some tests failed due to misaligned class space. I commented out those tests and filed [JDK-8301786](https://bugs.openjdk.org/browse/JDK-8301786). > - compiler/c2/irTests/TestVectorizationNotRun.java: New test that starts failing, presumably because byte[] and long[] don't start at same offset in Lilliput. I problem-listed the test for now, and filed: [JDK-8301785](https://bugs.openjdk.org/browse/JDK-8301785). > > Testing: > - [x] tier1 (aarch64/x86_64) > - [x] tier2 (aarch64/x86_64) This pull request has now been integrated. Changeset: 2f9fe47d Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/2f9fe47db3b31e9c7ddb0587c29a0148190f2270 Stats: 54667 lines in 2641 files changed: 22968 ins; 8800 del; 22899 mod Merge jdk:jdk-21+8 Reviewed-by: shade ------------- PR: https://git.openjdk.org/lilliput/pull/71 From stuefe at openjdk.org Mon Feb 6 16:24:12 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 6 Feb 2023 16:24:12 GMT Subject: [master] RFR: JDK-8301786: [Lilliput] Failing CompressedClassPointerEncoding.java Message-ID: This fixes and expands runtime/CompressedOops/CompressedClassPointerEncoding.java. Test had been broken by integration of [JDK-8294677](https://bugs.openjdk.org/browse/JDK-8294677), but to my embarrassment, I found that the test had never actually been finished, some vital checks were missing. I fixed all that, clarified comments, and also changed the test to have multiple sub tests. I manually tested on x64 and aarch64. On aarch64, I tried to test both `xor` and `movk` encoding modes but was unable to test latter - the lowest valid encoding base that would trigger `movk` mode is `0xa00_00000000`, and the kernel on my Raspi box is compiled for max. 39 bits for virtual user space addresses. That makes mapping at higher addresses fail. See comment in test. There is more work to be done for aarch64: runtime/CompressedOops/CompressedClassPointerEncoding.java asserts. I opened https://bugs.openjdk.org/browse/JDK-8301880 to track that. ------------- Commit messages: - Fix Test Changes: https://git.openjdk.org/lilliput/pull/72/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=72&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301786 Stats: 321 lines in 1 file changed: 201 ins; 54 del; 66 mod Patch: https://git.openjdk.org/lilliput/pull/72.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/72/head:pull/72 PR: https://git.openjdk.org/lilliput/pull/72 From shade at openjdk.org Mon Feb 6 17:24:28 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 6 Feb 2023 17:24:28 GMT Subject: [master] RFR: JDK-8301786: [Lilliput] Failing CompressedClassPointerEncoding.java In-Reply-To: References: Message-ID: <4jfIzShbw2AZPPinKOp59uCRGj1gj59IEK_jS1c5Lhs=.96019789-1e6c-415f-91c3-3b21187284cc@github.com> On Mon, 6 Feb 2023 16:16:13 GMT, Thomas Stuefe wrote: > This fixes and expands runtime/CompressedOops/CompressedClassPointerEncoding.java. > > Test had been broken by integration of [JDK-8294677](https://bugs.openjdk.org/browse/JDK-8294677), but to my embarrassment, I found that the test had never actually been finished, some vital checks were missing. > > I fixed all that, clarified comments, and also changed the test to have multiple sub tests. I manually tested on x64 and aarch64. > > On aarch64, I tried to test both `xor` and `movk` encoding modes but was unable to test latter - the lowest valid encoding base that would trigger `movk` mode is `0xa00_00000000`, and the kernel on my Raspi box is compiled for max. 39 bits for virtual user space addresses. That makes mapping at higher addresses fail. See comment in test. > > There is more work to be done for aarch64: runtime/CompressedOops/CompressedClassPointerEncoding.java asserts. I opened https://bugs.openjdk.org/browse/JDK-8301880 to track that. Looks okay to me. test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointerEncoding.java line 44: > 42: > 43: ///// x64 /////////////////////////////////////////////////////////////// > 44: While I suspect the comments like these are fine for jtreg, this is not the usual style for these. Test IDs are probably enough to get this done. test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointerEncoding.java line 153: > 151: final static int narrowKlassBitSize = 22; > 152: final static int narrowKlassShift = 9; > 153: final static long narrowKlassValueSpan = (long)1 << narrowKlassBitSize; Java style: `1L` instead of `(long)1`. ------------- Marked as reviewed by shade (Committer). PR: https://git.openjdk.org/lilliput/pull/72 From duke at openjdk.org Tue Feb 7 07:08:03 2023 From: duke at openjdk.org (duke) Date: Tue, 7 Feb 2023 07:08:03 GMT Subject: git: openjdk/lilliput: pr/72: Feedback Alexey; massage comments Message-ID: <60732c50-8936-4de3-a903-2435f6296bdb@openjdk.org> Changeset: bda987ca Author: tstuefe Date: 2023-02-07 08:03:17 +0000 URL: https://git.openjdk.org/lilliput/commit/bda987ca0f14032b28205d321f0964b9cacbf655 Feedback Alexey; massage comments ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointerEncoding.java From stuefe at openjdk.org Tue Feb 7 07:10:54 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 7 Feb 2023 07:10:54 GMT Subject: [master] RFR: JDK-8301786: [Lilliput] Failing CompressedClassPointerEncoding.java [v2] In-Reply-To: References: Message-ID: > This fixes and expands runtime/CompressedOops/CompressedClassPointerEncoding.java. > > Test had been broken by integration of [JDK-8294677](https://bugs.openjdk.org/browse/JDK-8294677), but to my embarrassment, I found that the test had never actually been finished, some vital checks were missing. > > I fixed all that, clarified comments, and also changed the test to have multiple sub tests. I manually tested on x64 and aarch64. > > On aarch64, I tried to test both `xor` and `movk` encoding modes but was unable to test latter - the lowest valid encoding base that would trigger `movk` mode is `0xa00_00000000`, and the kernel on my Raspi box is compiled for max. 39 bits for virtual user space addresses. That makes mapping at higher addresses fail. See comment in test. > > There is more work to be done for aarch64: runtime/CompressedOops/CompressedClassPointerEncoding.java asserts. I opened https://bugs.openjdk.org/browse/JDK-8301880 to track that. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Alexey; massage comments ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/72/files - new: https://git.openjdk.org/lilliput/pull/72/files/be6b5575..bda987ca Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=72&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=72&range=00-01 Stats: 17 lines in 1 file changed: 0 ins; 3 del; 14 mod Patch: https://git.openjdk.org/lilliput/pull/72.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/72/head:pull/72 PR: https://git.openjdk.org/lilliput/pull/72 From stuefe at openjdk.org Tue Feb 7 07:10:57 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 7 Feb 2023 07:10:57 GMT Subject: [master] RFR: JDK-8301786: [Lilliput] Failing CompressedClassPointerEncoding.java [v2] In-Reply-To: <4jfIzShbw2AZPPinKOp59uCRGj1gj59IEK_jS1c5Lhs=.96019789-1e6c-415f-91c3-3b21187284cc@github.com> References: <4jfIzShbw2AZPPinKOp59uCRGj1gj59IEK_jS1c5Lhs=.96019789-1e6c-415f-91c3-3b21187284cc@github.com> Message-ID: <0RilZFqzpG5D5k4sQdb8FnPm7BWm4NfKleMd_EbYArk=.7cb1a774-c439-4512-8693-68838d8d3350@github.com> On Mon, 6 Feb 2023 17:21:30 GMT, Aleksey Shipilev wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Alexey; massage comments > > Looks okay to me. thanks @shipilev. ------------- PR: https://git.openjdk.org/lilliput/pull/72 From stuefe at openjdk.org Tue Feb 7 07:10:59 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 7 Feb 2023 07:10:59 GMT Subject: [master] Integrated: JDK-8301786: [Lilliput] Failing CompressedClassPointerEncoding.java In-Reply-To: References: Message-ID: <6fXga6Cfq0gPwCpmZbI6XI24rpWz672xu5zK2BEpWwQ=.4b2e6b5c-fdf3-48a2-b04c-0b31b2b11a09@github.com> On Mon, 6 Feb 2023 16:16:13 GMT, Thomas Stuefe wrote: > This fixes and expands runtime/CompressedOops/CompressedClassPointerEncoding.java. > > Test had been broken by integration of [JDK-8294677](https://bugs.openjdk.org/browse/JDK-8294677), but to my embarrassment, I found that the test had never actually been finished, some vital checks were missing. > > I fixed all that, clarified comments, and also changed the test to have multiple sub tests. I manually tested on x64 and aarch64. > > On aarch64, I tried to test both `xor` and `movk` encoding modes but was unable to test latter - the lowest valid encoding base that would trigger `movk` mode is `0xa00_00000000`, and the kernel on my Raspi box is compiled for max. 39 bits for virtual user space addresses. That makes mapping at higher addresses fail. See comment in test. > > There is more work to be done for aarch64: runtime/CompressedOops/CompressedClassPointerEncoding.java asserts. I opened https://bugs.openjdk.org/browse/JDK-8301880 to track that. This pull request has now been integrated. Changeset: 14672c69 Author: Thomas Stuefe URL: https://git.openjdk.org/lilliput/commit/14672c69ac527179baa28396bcd75dee20170cf3 Stats: 318 lines in 1 file changed: 198 ins; 54 del; 66 mod 8301786: [Lilliput] Failing CompressedClassPointerEncoding.java Reviewed-by: shade ------------- PR: https://git.openjdk.org/lilliput/pull/72 From rkennke at openjdk.org Wed Feb 8 17:51:02 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 8 Feb 2023 17:51:02 GMT Subject: [master] RFR: 8302065: [Lilliput] Cleanups and touch-ups Message-ID: Lilliput accumulated a couple of superfluous changes and could need some minor improvements. ------------- Commit messages: - 8302065: [Lilliput] Cleanups and touch-ups Changes: https://git.openjdk.org/lilliput/pull/73/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=73&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302065 Stats: 41 lines in 14 files changed: 6 ins; 19 del; 16 mod Patch: https://git.openjdk.org/lilliput/pull/73.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/73/head:pull/73 PR: https://git.openjdk.org/lilliput/pull/73 From shade at openjdk.org Thu Feb 9 09:40:16 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 9 Feb 2023 09:40:16 GMT Subject: [master] RFR: 8302065: [Lilliput] Cleanups and touch-ups In-Reply-To: References: Message-ID: On Wed, 8 Feb 2023 11:40:39 GMT, Roman Kennke wrote: > Lilliput accumulated a couple of superfluous changes and could need some minor improvements. Looks good. I cross-referenced in with https://builds.shipilev.net/patch-openjdk-lilliput/ -- and most are clean reversal. A few questions, though. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 109: > 107: > 108: private: > 109: Missed a similar cleanup in `macroAssembler_x86.hpp`, I think. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 815: > 813: if (UseFastLocking) { > 814: // If the owner is ANONYMOUS, we need to fix it - in the slow-path. > 815: testb(Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), (int32_t) (intptr_t) ANONYMOUS_OWNER); Sanity question: This would accept the monitor that has the lowest byte equal to `ANONYMOUS_OWNER`. Are we guaranteed that no monitor would ever have the lowest bit as `1`? Probably true, just checking the reason here. src/hotspot/cpu/x86/vtableStubs_x86_64.cpp line 220: > 218: // The emitted code in lookup_interface_method changes when itable_index exceeds 15. > 219: // For linux, a very narrow estimate would be 112, but Solaris requires some more space (130). > 220: const ptrdiff_t estimate = 137; Upstream has it as `136`. Do we need `137`? ------------- Marked as reviewed by shade (Committer). PR: https://git.openjdk.org/lilliput/pull/73 From rkennke at openjdk.org Thu Feb 9 10:31:15 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 9 Feb 2023 10:31:15 GMT Subject: [master] RFR: 8302065: [Lilliput] Cleanups and touch-ups In-Reply-To: References: Message-ID: On Thu, 9 Feb 2023 09:34:10 GMT, Aleksey Shipilev wrote: >> Lilliput accumulated a couple of superfluous changes and could need some minor improvements. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 815: > >> 813: if (UseFastLocking) { >> 814: // If the owner is ANONYMOUS, we need to fix it - in the slow-path. >> 815: testb(Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)), (int32_t) (intptr_t) ANONYMOUS_OWNER); > > Sanity question: This would accept the monitor that has the lowest byte equal to `ANONYMOUS_OWNER`. Are we guaranteed that no monitor would ever have the lowest bit as `1`? Probably true, just checking the reason here. Valid monitor owners can only be Thread* or ANONYMOUS or NULL (or stack-pointers, but only with stack-locking). Thread instances are allocated at least word-aligned, so no, 1 cannot be a valid monitor owner. ------------- PR: https://git.openjdk.org/lilliput/pull/73 From rkennke at openjdk.org Thu Feb 9 10:37:52 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 9 Feb 2023 10:37:52 GMT Subject: [master] RFR: 8302065: [Lilliput] Cleanups and touch-ups [v2] In-Reply-To: References: Message-ID: > Lilliput accumulated a couple of superfluous changes and could need some minor improvements. Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Remove newline ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/73/files - new: https://git.openjdk.org/lilliput/pull/73/files/03b3a08e..4fff8340 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=73&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=73&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/lilliput/pull/73.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/73/head:pull/73 PR: https://git.openjdk.org/lilliput/pull/73 From rkennke at openjdk.org Thu Feb 9 10:37:56 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 9 Feb 2023 10:37:56 GMT Subject: [master] RFR: 8302065: [Lilliput] Cleanups and touch-ups [v2] In-Reply-To: References: Message-ID: On Thu, 9 Feb 2023 09:35:03 GMT, Aleksey Shipilev wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove newline > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 109: > >> 107: >> 108: private: >> 109: > > Missed a similar cleanup in `macroAssembler_x86.hpp`, I think. Right. I removed the newline in that file, too. > src/hotspot/cpu/x86/vtableStubs_x86_64.cpp line 220: > >> 218: // The emitted code in lookup_interface_method changes when itable_index exceeds 15. >> 219: // For linux, a very narrow estimate would be 112, but Solaris requires some more space (130). >> 220: const ptrdiff_t estimate = 137; > > Upstream has it as `136`. Do we need `137`? I couldn't build/run it with 136, it asked for 137. *shrugs* ------------- PR: https://git.openjdk.org/lilliput/pull/73 From duke at openjdk.org Thu Feb 9 10:38:16 2023 From: duke at openjdk.org (duke) Date: Thu, 9 Feb 2023 10:38:16 GMT Subject: git: openjdk/lilliput: pr/73: Remove newline Message-ID: Changeset: 4fff8340 Author: Roman Kennke Date: 2023-02-09 10:31:19 +0000 URL: https://git.openjdk.org/lilliput/commit/4fff8340273f1fc7770037dfbaf6459551d30a82 Remove newline ! src/hotspot/cpu/x86/macroAssembler_x86.hpp From shade at openjdk.org Thu Feb 9 10:45:11 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 9 Feb 2023 10:45:11 GMT Subject: [master] RFR: 8302065: [Lilliput] Cleanups and touch-ups [v2] In-Reply-To: References: Message-ID: <8O07rVPwPwQW7_72hB6PGwLkzm4Ve3UlB4V0YGikBTw=.b9f7f711-9c0f-43df-a877-527a4fa13d63@github.com> On Thu, 9 Feb 2023 10:37:52 GMT, Roman Kennke wrote: >> Lilliput accumulated a couple of superfluous changes and could need some minor improvements. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove newline Marked as reviewed by shade (Committer). ------------- PR: https://git.openjdk.org/lilliput/pull/73 From rkennke at openjdk.org Thu Feb 9 19:15:45 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 9 Feb 2023 19:15:45 GMT Subject: [master] RFR: 8302065: [Lilliput] Cleanups and touch-ups [v3] In-Reply-To: References: Message-ID: > Lilliput accumulated a couple of superfluous changes and could need some minor improvements. Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Disable CompressedClassPointerEncoding test for windows and macosx ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/73/files - new: https://git.openjdk.org/lilliput/pull/73/files/4fff8340..41978812 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=73&range=02 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=73&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/lilliput/pull/73.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/73/head:pull/73 PR: https://git.openjdk.org/lilliput/pull/73 From duke at openjdk.org Thu Feb 9 19:18:10 2023 From: duke at openjdk.org (duke) Date: Thu, 9 Feb 2023 19:18:10 GMT Subject: git: openjdk/lilliput: pr/73: Disable CompressedClassPointerEncoding test for windows and macosx Message-ID: Changeset: 41978812 Author: Roman Kennke Date: 2023-02-09 19:10:10 +0000 URL: https://git.openjdk.org/lilliput/commit/419788121b35c19196a33d28085698d77f14910b Disable CompressedClassPointerEncoding test for windows and macosx ! test/hotspot/jtreg/ProblemList.txt From rkennke at openjdk.org Fri Feb 10 11:16:18 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 10 Feb 2023 11:16:18 GMT Subject: [master] RFR: 8302209: [Lilliput] Optimize fix-anon monitor owner path Message-ID: When trying to exit a monitor, we need to check if the current owner is anonymous, and if so, fix it before exiting the monitor. So far, we have been doing this by calling into the slow-path and handle it in the runtime. However, it is fairly easy to do in the fast-path and avoid calling into the runtime altogether. Testing: - [x] tier1 (x86_64, aarch64) - [ ] tier2 (x86_64, aarch64) - [ ] jcstress -t sync -m quick ------------- Commit messages: - 8302209: [Lilliput] Optimize fix-anon monitor owner path Changes: https://git.openjdk.org/lilliput/pull/74/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=74&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302209 Stats: 60 lines in 5 files changed: 55 ins; 1 del; 4 mod Patch: https://git.openjdk.org/lilliput/pull/74.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/74/head:pull/74 PR: https://git.openjdk.org/lilliput/pull/74 From duke at openjdk.org Fri Feb 10 11:19:34 2023 From: duke at openjdk.org (duke) Date: Fri, 10 Feb 2023 11:19:34 GMT Subject: git: openjdk/lilliput: created branch pr/74 based on the branch pr/73 containing 1 unique commit Message-ID: <53717da1-39c9-4151-b7cc-7d776e84e31a@openjdk.org> The following commits are unique to the pr/74 branch: ======================================================== c564ada6: 8302209: [Lilliput] Optimize fix-anon monitor owner path From duke at openjdk.org Fri Feb 10 11:25:28 2023 From: duke at openjdk.org (duke) Date: Fri, 10 Feb 2023 11:25:28 GMT Subject: git: openjdk/lilliput: pr/73: 3 new changesets Message-ID: <8fe06e6a-fd0c-4e1a-9094-e6875408c623@openjdk.org> Changeset: 6d23a934 Author: Roman Kennke Date: 2023-02-10 11:11:31 +0000 URL: https://git.openjdk.org/lilliput/commit/6d23a93432c22501be93b31b12f533bf61a9aece Typo and whitespace change ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 61200fa4 Author: Roman Kennke Date: 2023-02-10 11:13:35 +0000 URL: https://git.openjdk.org/lilliput/commit/61200fa4db6a2a4e3d460ebd7a504848e281571e Merge remote-tracking branch 'origin/JDK-8302065' into JDK-8302065 Changeset: fde2611e Author: Roman Kennke Date: 2023-02-10 11:20:34 +0000 URL: https://git.openjdk.org/lilliput/commit/fde2611e68eae2ab50cfc266a905d8da6bf7d684 Fix Problemlist of CompressedClassPointerEncoding test ! test/hotspot/jtreg/ProblemList.txt From rkennke at openjdk.org Fri Feb 10 11:26:41 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 10 Feb 2023 11:26:41 GMT Subject: [master] RFR: 8302065: [Lilliput] Cleanups and touch-ups [v4] In-Reply-To: References: Message-ID: > Lilliput accumulated a couple of superfluous changes and could need some minor improvements. Roman Kennke has updated the pull request incrementally with three additional commits since the last revision: - Fix Problemlist of CompressedClassPointerEncoding test - Merge remote-tracking branch 'origin/JDK-8302065' into JDK-8302065 - Typo and whitespace change ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/73/files - new: https://git.openjdk.org/lilliput/pull/73/files/41978812..fde2611e Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=73&range=03 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=73&range=02-03 Stats: 11 lines in 3 files changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/lilliput/pull/73.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/73/head:pull/73 PR: https://git.openjdk.org/lilliput/pull/73 From rkennke at openjdk.org Fri Feb 10 11:48:53 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 10 Feb 2023 11:48:53 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8302210: [Lilliput/JDK17] Optimize fix-anon monitor owner path Message-ID: When trying to exit a monitor, we need to check if the current owner is anonymous, and if so, fix it before exiting the monitor. So far, we have been doing this by calling into the slow-path and handle it in the runtime. However, it is fairly easy to do in the fast-path and avoid calling into the runtime altogether. Testing: - [x] tier1 (x86_64, aarch64) - [ ] tier2 (x86_64, aarch64) - [ ] jcstress -t sync -m quick (x86_64, aarch64) ------------- Commit messages: - 8302210: [Lilliput/JDK17] Simplify and optimize loading of Klass* Changes: https://git.openjdk.org/lilliput-jdk17u/pull/5/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=5&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8302210 Stats: 62 lines in 5 files changed: 57 ins; 1 del; 4 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/5.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/5/head:pull/5 PR: https://git.openjdk.org/lilliput-jdk17u/pull/5 From duke at openjdk.org Fri Feb 10 11:50:06 2023 From: duke at openjdk.org (duke) Date: Fri, 10 Feb 2023 11:50:06 GMT Subject: git: openjdk/lilliput-jdk17u: created branch pr/5 based on the branch lilliput containing 1 unique commit Message-ID: <77110f6b-35ff-495b-8696-28e934eba771@openjdk.org> The following commits are unique to the pr/5 branch: ======================================================== 9522adc0: 8302210: [Lilliput/JDK17] Simplify and optimize loading of Klass* From rkennke at openjdk.org Fri Feb 10 16:50:22 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 10 Feb 2023 16:50:22 GMT Subject: [master] Integrated: 8302065: [Lilliput] Cleanups and touch-ups In-Reply-To: References: Message-ID: <0WbJjPbzsoxPdXJeOtNw5jRxNmiDQBnvgGVBoxFA1TY=.4195ce7e-756b-43dc-b379-2cd3fa4e6b11@github.com> On Wed, 8 Feb 2023 11:40:39 GMT, Roman Kennke wrote: > Lilliput accumulated a couple of superfluous changes and could need some minor improvements. This pull request has now been integrated. Changeset: 7ed8bfa6 Author: Roman Kennke URL: https://git.openjdk.org/lilliput/commit/7ed8bfa6c5a9bb957df0c3826c4c42061f062a25 Stats: 53 lines in 16 files changed: 15 ins; 20 del; 18 mod 8302065: [Lilliput] Cleanups and touch-ups Reviewed-by: shade ------------- PR: https://git.openjdk.org/lilliput/pull/73 From rkennke at openjdk.org Tue Feb 14 14:47:41 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 14 Feb 2023 14:47:41 GMT Subject: [master] RFR: 8302209: [Lilliput] Optimize fix-anon monitor owner path [v2] In-Reply-To: References: Message-ID: > When trying to exit a monitor, we need to check if the current owner is anonymous, and if so, fix it before exiting the monitor. So far, we have been doing this by calling into the slow-path and handle it in the runtime. However, it is fairly easy to do in the fast-path and avoid calling into the runtime altogether. > > Testing: > - [x] tier1 (x86_64, aarch64) > - [x] tier2 (x86_64, aarch64) > - [ ] jcstress -t sync -m quick Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8302209 - 8302209: [Lilliput] Optimize fix-anon monitor owner path ------------- Changes: https://git.openjdk.org/lilliput/pull/74/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=74&range=01 Stats: 60 lines in 5 files changed: 55 ins; 1 del; 4 mod Patch: https://git.openjdk.org/lilliput/pull/74.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/74/head:pull/74 PR: https://git.openjdk.org/lilliput/pull/74 From duke at openjdk.org Tue Feb 14 14:52:20 2023 From: duke at openjdk.org (duke) Date: Tue, 14 Feb 2023 14:52:20 GMT Subject: git: openjdk/lilliput: pr/74: 2 new changesets Message-ID: Changeset: 7ed8bfa6 Author: Roman Kennke Date: 2023-02-10 16:47:35 +0000 URL: https://git.openjdk.org/lilliput/commit/7ed8bfa6c5a9bb957df0c3826c4c42061f062a25 8302065: [Lilliput] Cleanups and touch-ups Reviewed-by: shade ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/aarch64/vtableStubs_aarch64.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/vtableStubs_x86_64.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 55b6c241 Author: Roman Kennke Date: 2023-02-14 14:41:15 +0000 URL: https://git.openjdk.org/lilliput/commit/55b6c241bad84d7aedb7c7a9a874773914ad359c Merge branch 'master' into JDK-8302209 ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp From rkennke at openjdk.org Tue Feb 21 19:55:56 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 21 Feb 2023 19:55:56 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8302210: [Lilliput/JDK17] Optimize fix-anon monitor owner path [v2] In-Reply-To: References: Message-ID: > When trying to exit a monitor, we need to check if the current owner is anonymous, and if so, fix it before exiting the monitor. So far, we have been doing this by calling into the slow-path and handle it in the runtime. However, it is fairly easy to do in the fast-path and avoid calling into the runtime altogether. > > Testing: > - [x] tier1 (x86_64, aarch64) > - [ ] tier2 (x86_64, aarch64) > - [ ] jcstress -t sync -m quick (x86_64, aarch64) Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/5/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/5/files/9522adc0..c7f29da5 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=5&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=5&range=00-01 Stats: 82 lines in 4 files changed: 77 ins; 1 del; 4 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/5.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/5/head:pull/5 PR: https://git.openjdk.org/lilliput-jdk17u/pull/5 From duke at openjdk.org Tue Feb 21 19:56:37 2023 From: duke at openjdk.org (duke) Date: Tue, 21 Feb 2023 19:56:37 GMT Subject: git: openjdk/lilliput-jdk17u: pr/5: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration Message-ID: <8f39f232-4416-4c72-abe3-2b56efe552c8@openjdk.org> Changeset: c7f29da5 Author: Roman Kennke Date: 2023-02-21 19:51:20 +0000 URL: https://git.openjdk.org/lilliput-jdk17u/commit/c7f29da59410f23a1d7e75966041cfb136b96ed4 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp + test/hotspot/jtreg/runtime/oom/TestOOM.java From rkennke at openjdk.org Tue Feb 21 20:00:29 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 21 Feb 2023 20:00:29 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8302210: [Lilliput/JDK17] Optimize fix-anon monitor owner path [v3] In-Reply-To: References: Message-ID: > When trying to exit a monitor, we need to check if the current owner is anonymous, and if so, fix it before exiting the monitor. So far, we have been doing this by calling into the slow-path and handle it in the runtime. However, it is fairly easy to do in the fast-path and avoid calling into the runtime altogether. > > Testing: > - [x] tier1 (x86_64, aarch64) > - [ ] tier2 (x86_64, aarch64) > - [ ] jcstress -t sync -m quick (x86_64, aarch64) Roman Kennke has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: 8302210: [Lilliput/JDK17] Simplify and optimize loading of Klass* ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/5/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/5/files/c7f29da5..9522adc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=5&range=02 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=5&range=01-02 Stats: 82 lines in 4 files changed: 1 ins; 77 del; 4 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/5.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/5/head:pull/5 PR: https://git.openjdk.org/lilliput-jdk17u/pull/5 From rkennke at openjdk.org Tue Feb 21 20:09:43 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 21 Feb 2023 20:09:43 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration Message-ID: A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. Testing: - [x] runtime/oom/TestOOM.java - [x] tier1 - [ ] tier2 ------------- Commit messages: - 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration Changes: https://git.openjdk.org/lilliput-jdk17u/pull/6/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303027 Stats: 82 lines in 4 files changed: 77 ins; 1 del; 4 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From duke at openjdk.org Tue Feb 21 20:48:35 2023 From: duke at openjdk.org (duke) Date: Tue, 21 Feb 2023 20:48:35 GMT Subject: git: openjdk/lilliput-jdk17u: created branch pr/6 based on the branch lilliput containing 1 unique commit Message-ID: The following commits are unique to the pr/6 branch: ======================================================== 717ab33b: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration From shade at openjdk.org Wed Feb 22 12:23:00 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Feb 2023 12:23:00 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration In-Reply-To: References: Message-ID: On Tue, 21 Feb 2023 20:02:08 GMT, Roman Kennke wrote: > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Looks okay. But depending on the frequency of `block_is_obj(p)` being true, we might just put the `in_full_gc()` condition inside the `block_size()` itself? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Wed Feb 22 12:53:30 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 22 Feb 2023 12:53:30 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration In-Reply-To: References: Message-ID: <_I7-_t5OPhJSJC0ROMfgDi7GXUvU8V9cX3phPVbfDbk=.7856430b-d6ef-4e23-a84f-100d79312a40@github.com> On Wed, 22 Feb 2023 12:20:15 GMT, Aleksey Shipilev wrote: > But depending on the frequency of `block_is_obj(p)` being true, we might just put the `in_full_gc()` condition inside the `block_size()` itself? The actual problem only arises when evacuation fails and GC tries to recover from that (specifically, when the GC is restoring self-forwarded object headers). That is not very performance critical, I think. However, block_size() is called from many other places during GC, and is potentially applied to all (live) objects, e.g. during heap scan. It may be helped a little by bitmap based iteration, but I'd rather not risk affecting performance of all the common paths, if I can avoid it. ------------- PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Wed Feb 22 13:18:46 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 22 Feb 2023 13:18:46 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v2] In-Reply-To: References: Message-ID: > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Use templated iteration loop and block_size() ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/6/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/6/files/717ab33b..38551d5e Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=00-01 Stats: 47 lines in 3 files changed: 18 ins; 24 del; 5 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Wed Feb 22 13:18:48 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 22 Feb 2023 13:18:48 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v2] In-Reply-To: References: Message-ID: On Wed, 22 Feb 2023 12:20:15 GMT, Aleksey Shipilev wrote: > Looks okay. > > But depending on the frequency of `block_is_obj(p)` being true, we might just put the `in_full_gc()` condition inside the `block_size()` itself? I just pushed an attempt to use a templated loop and block_size(), that avoids the duplication AND should perform well. WDYT? (Note: we could achieve the same using constexpr bool arg, but I don't think it is allowed in 17 yet). ------------- PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From shade at openjdk.org Wed Feb 22 14:01:36 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Feb 2023 14:01:36 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v2] In-Reply-To: References: Message-ID: On Wed, 22 Feb 2023 13:18:46 GMT, Roman Kennke wrote: >> A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. >> >> The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. >> >> This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. >> >> The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. >> >> Testing: >> - [x] runtime/oom/TestOOM.java >> - [x] tier1 >> - [ ] tier2 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Use templated iteration loop and block_size() This looks much better, thanks. src/hotspot/share/gc/g1/heapRegion.hpp line 190: > 188: // and the amount of unallocated words if called on top() > 189: template > 190: size_t block_size(const HeapWord* p) const; There is non-templated `block_size` here too, just below. Is the non-templated version used? If so, do you want to drop it and say `template` instead? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Wed Feb 22 14:10:04 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 22 Feb 2023 14:10:04 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v3] In-Reply-To: References: Message-ID: <2L8XFi7Q_CyhaPpGNVI1izDJvvN8iodIH6WDWX6Ww-k=.9b661846-ce20-4ff4-92b6-97725f8d8d00@github.com> > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Use default template arg, and simplify block_size() ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/6/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/6/files/38551d5e..0bcdee81 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=02 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Wed Feb 22 15:54:12 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 22 Feb 2023 15:54:12 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v4] In-Reply-To: References: Message-ID: <5glVHxvLP92OTP3VeDc08ZeHbFidPkig3gYjPQ70prA=.dff5b43d-e75a-4e52-a5a3-002292e2c46d@github.com> > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Rename object_iterate to _impl ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/6/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/6/files/0bcdee81..cb758770 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=03 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Wed Feb 22 18:18:04 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 22 Feb 2023 18:18:04 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v5] In-Reply-To: References: Message-ID: > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Add asserts for sanity ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/6/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/6/files/cb758770..38a16dae Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=04 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Wed Feb 22 19:17:00 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 22 Feb 2023 19:17:00 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v6] In-Reply-To: References: Message-ID: > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Reformat asserts for better readability ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/6/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/6/files/38a16dae..590742c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=05 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=04-05 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From shade at openjdk.org Wed Feb 22 19:28:37 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Feb 2023 19:28:37 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v6] In-Reply-To: References: Message-ID: On Wed, 22 Feb 2023 19:17:00 GMT, Roman Kennke wrote: >> A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. >> >> The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. >> >> This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. >> >> The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. >> >> Testing: >> - [x] runtime/oom/TestOOM.java >> - [x] tier1 >> - [ ] tier2 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Reformat asserts for better readability Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Wed Feb 22 20:44:50 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 22 Feb 2023 20:44:50 GMT Subject: [lilliput-jdk17u:lilliput] RFR: Merge jdk17u:jdk-17.0.7+3 Message-ID: Merging from upstream latest tag. ------------- Commit messages: - Merge tag 'jdk-17.0.7+3' into merge-jdk-17.0.7+3 - 8299970: Speed up compiler/arraycopy/TestArrayCopyConjoint.java - 8298472: AArch64: Detect Ampere-1 and Ampere-1A CPUs and set default options - 8302152: Speed up tests with infinite loops, sleep less - 8301342: Prefer ArrayList to LinkedList in LayoutComparator - 8288332: Tier1 validate-source fails after 8279614 - 8302692: [17u] Update GHA Boot JDK to 17.0.6 - 8301842: JFR: increase checkpoint event size for stacktrace and string pool - 8297437: javadoc cannot link to old docs (with old style anchors) - 8282958: Rendering Issues with Borders on Windows High-DPI systems - ... and 235 more: https://git.openjdk.org/lilliput-jdk17u/compare/685351d2...5cbd1ad8 The webrevs contain the adjustments done while merging with regards to each parent branch: - lilliput: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=7&range=00.0 - jdk17u:jdk-17.0.7+3: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=7&range=00.1 Changes: https://git.openjdk.org/lilliput-jdk17u/pull/7/files Stats: 41692 lines in 740 files changed: 31866 ins; 4089 del; 5737 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/7.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/7/head:pull/7 PR: https://git.openjdk.org/lilliput-jdk17u/pull/7 From rkennke at openjdk.org Thu Feb 23 10:10:43 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 23 Feb 2023 10:10:43 GMT Subject: [lilliput-jdk17u:lilliput] RFR: Merge jdk17u:jdk-17.0.7+3 [v2] In-Reply-To: References: Message-ID: > Merging from upstream latest tag. Roman Kennke 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 tag 'jdk-17.0.7+3' into merge-jdk-17.0.7+3 Added tag jdk-17.0.7+3 for changeset da62b2b37e07 - 8300566: [Lilliput/JDK17] Properly set ZF on anon-check path Reviewed-by: shade - 8300138: [Lilliput/JDK17] Optimize anonymous owner fix-up path Reviewed-by: shade - 8299552: [Lilliput/JDK17] Fix 32bit builds Reviewed-by: shade - 8299478: [Lilliput/JDK17] Fix Windows build Reviewed-by: shade - Use LRB instead of plain resolve in Shenandoah object iterator - Initial import of Lilliput in JDK17u ------------- Changes: https://git.openjdk.org/lilliput-jdk17u/pull/7/files Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=7&range=01 Stats: 4845 lines in 201 files changed: 3080 ins; 910 del; 855 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/7.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/7/head:pull/7 PR: https://git.openjdk.org/lilliput-jdk17u/pull/7 From rkennke at openjdk.org Thu Feb 23 10:10:43 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 23 Feb 2023 10:10:43 GMT Subject: [lilliput-jdk17u:lilliput] Integrated: Merge jdk17u:jdk-17.0.7+3 In-Reply-To: References: Message-ID: On Wed, 22 Feb 2023 18:08:13 GMT, Roman Kennke wrote: > Merging from upstream latest tag. This pull request has now been integrated. Changeset: 23bfadb1 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk17u/commit/23bfadb1fd4349e52c80084b659ee6b659bcf33b Stats: 41692 lines in 740 files changed: 31866 ins; 4089 del; 5737 mod Merge ------------- PR: https://git.openjdk.org/lilliput-jdk17u/pull/7 From rkennke at openjdk.org Thu Feb 23 10:31:28 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 23 Feb 2023 10:31:28 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v7] In-Reply-To: References: Message-ID: > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Roman Kennke 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 'lilliput' into JDK-8303027 - Reformat asserts for better readability - Add asserts for sanity - Rename object_iterate to _impl - Use default template arg, and simplify block_size() - Use templated iteration loop and block_size() - 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/6/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/6/files/590742c5..8cb1b7fe Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=06 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=05-06 Stats: 41692 lines in 740 files changed: 31866 ins; 4089 del; 5737 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Thu Feb 23 13:11:14 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 23 Feb 2023 13:11:14 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v8] In-Reply-To: References: Message-ID: > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Change configuration of reproducer to run with lower memory ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/6/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/6/files/8cb1b7fe..b1b1051d Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=07 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Thu Feb 23 16:07:33 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 23 Feb 2023 16:07:33 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v9] In-Reply-To: References: Message-ID: > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Separate TestOOM tests for 32 bits and 64 bits ------------- Changes: - all: https://git.openjdk.org/lilliput-jdk17u/pull/6/files - new: https://git.openjdk.org/lilliput-jdk17u/pull/6/files/b1b1051d..aeaf7753 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=08 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=6&range=07-08 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/lilliput-jdk17u/pull/6.diff Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u pull/6/head:pull/6 PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Thu Feb 23 19:22:38 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 23 Feb 2023 19:22:38 GMT Subject: [lilliput-jdk17u:lilliput] RFR: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration [v9] In-Reply-To: References: Message-ID: On Thu, 23 Feb 2023 16:07:33 GMT, Roman Kennke wrote: >> A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. >> >> The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. >> >> This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. >> >> The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. >> >> Testing: >> - [x] runtime/oom/TestOOM.java >> - [x] tier1 >> - [ ] tier2 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Separate TestOOM tests for 32 bits and 64 bits It finally passes all GHA except the x-compiles, which is expected. Let's ------------- PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Thu Feb 23 19:22:39 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 23 Feb 2023 19:22:39 GMT Subject: [lilliput-jdk17u:lilliput] Integrated: 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration In-Reply-To: References: Message-ID: On Tue, 21 Feb 2023 20:02:08 GMT, Roman Kennke wrote: > A user provided a (pretty simple) test case that makes the VM crash with Lilliput, when it should exit (somewhat more) gracefully with an OOME. The reason for the crash is that in G1, object_iterate() (or rather, the block_size() method that it calls) does not correctly resolve possibly forwarded objects, and then crashes because it accesses the Klass*, which is overridden by the forwarding pointer. > > The trouble is that, we don't need (or even can't) resolve forwarded objects during full-GC, because there we are using sliding-forwarding which is designed precisely to preserve the object's Klass* while being forwarded. Outside of full-GC we don't need to preserve the Klass* because the Klass* is preserved in the forwarded copy. > > This bug only exists in Lilliput/JDK17, the code path that leads to object_iterate() (restoring self-forwarded objects at evac failure) doesn't exist anymore in later versions - it uses a better way to iterate over the relevant self-forwarded objects. > > The proposed fix is to do two different loops, one that resolves the forwardees when needed, and the other one that doesn't. The alternative would have to check for the condition in_full_gc() on every object being scanned, which would affect performance. I included the test case as jtreg test. > > Testing: > - [x] runtime/oom/TestOOM.java > - [x] tier1 > - [ ] tier2 This pull request has now been integrated. Changeset: 4e089d13 Author: Roman Kennke URL: https://git.openjdk.org/lilliput-jdk17u/commit/4e089d13d4027ccd0b4f3fb6af34e39bfd451a39 Stats: 83 lines in 4 files changed: 80 ins; 0 del; 3 mod 8303027: [Lilliput/JDK17] Correctly resolve forwarded objects in G1 heap iteration Reviewed-by: shade ------------- PR: https://git.openjdk.org/lilliput-jdk17u/pull/6 From rkennke at openjdk.org Fri Feb 24 18:53:33 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 24 Feb 2023 18:53:33 GMT Subject: [master] RFR: 8301562: [Lilliput] Runtime flag to enable Lilliput Message-ID: This change introduces an experimental runtime flag -XX:[+/-]UseCompactObjectHeaders which can be used to disable Lilliput. The flag guards all the relevant places that directly affect the object layout and the accesses to Klass* etc. The change also restores the previous behaviour when -UseCompactObjectHeaders is selected. Testing: - [x] tier1 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders - [x] tier2 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders - [x] tier1 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders - [x] tier2 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders ------------- Commit messages: - Use tbz instruction in load_nklass to avoid touching live flags in verify_oop stub - Comment-out mis-placed assert - Only iterate metadata when not using compact object headers in SA - Problem-list CompressedClassSpaceSize test - Fix TestMetaspacePerfCounters test - Fix BaseOffsets.java test - Revert condition to turn off CDS when Lilliput is disabled - Make UseCompactObjectHeaders default to on - Fix intendation - Revert change in TestMetaspacePerfCounters test - ... and 32 more: https://git.openjdk.org/lilliput/compare/7ed8bfa6...becf81c0 Changes: https://git.openjdk.org/lilliput/pull/70/files Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=70&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301562 Stats: 979 lines in 63 files changed: 631 ins; 70 del; 278 mod Patch: https://git.openjdk.org/lilliput/pull/70.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/70/head:pull/70 PR: https://git.openjdk.org/lilliput/pull/70 From stuefe at openjdk.org Fri Feb 24 18:53:33 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Feb 2023 18:53:33 GMT Subject: [master] RFR: 8301562: [Lilliput] Runtime flag to enable Lilliput In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 13:04:27 GMT, Roman Kennke wrote: > This change introduces an experimental runtime flag -XX:[+/-]UseCompactObjectHeaders which can be used to disable Lilliput. The flag guards all the relevant places that directly affect the object layout and the accesses to Klass* etc. The change also restores the previous behaviour when -UseCompactObjectHeaders is selected. > > Testing: > - [x] tier1 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders > - [x] tier2 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders > - [x] tier1 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders > - [x] tier2 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders LogKlassAlignmentInBytes and everything depending on it will have to be switched to runtime-controlled variables. Nothing complex, just annoying. I'm on it. Hi Roman, Some fixes from my side, see branch https://github.com/tstuefe/lilliput/commits/fixes-to-usecompactobjectheader Suggested changes: 1) https://github.com/tstuefe/lilliput/commit/38dcba1d06a56b01cf7c9a593656f1ae5109b9b0 this makes KlassAlignmentInBytes and friends runtime-controlled. This is really ugly, but the whole ccs- and compressed klass pointer encoding initialization deserves an overhaul, and this is the least intrusive fix possible. 2) https://github.com/tstuefe/lilliput/commit/ad929fafbb4f7c5785e5627b53f0de33dafd2501 Needed to fix a crash when compact headers are enabled. 3) https://github.com/tstuefe/lilliput/commit/e854428c077e596f81e1349107bc37c2b80c5237 Expands gtests to also test all permutations of CCS and CompactHeaders 4) https://github.com/tstuefe/lilliput/commit/4c01e6a017bda54e6cdee62ef8814756829fb489 Needed to move constraint check for CompressedClassPointerSize to after ergo Cheers, thomas Yeah, 32-bit is also broken. Sigh. Okay, some more fixes: https://github.com/tstuefe/lilliput/commit/b2f0364062e706303dc6ec8ee434700a51a99e30 : fix up aarch64 CCS allocation. I have planned to overhaul CCS initialization for a while, maybe its time. There are conceptional flaws, and it is really ugly too with all that aarch64-specific knowledge hardcoded into shared metaspace coding, and ppc64 piggybacking atop of that :-( https://github.com/tstuefe/lilliput/commit/37d386aa1653040859442c0926753a78c17cdd84 : obvious fix for c1 on aarch64 https://github.com/tstuefe/lilliput/commit/dd5af41ce8845fc56f246321cdff55343671bcad : bunch of build fixes on 32-bit. This is another sore point, I really dislike all that 64-bit specific coding compiled into x86. It is this way in head too. I would love to see this fixed. Remaining, as far as I see: - `-XX:-UseCompressedClassPointers` crashes on aarch64 with `Internal Error (/shared/projects/openjdk/lilliput/source/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:2570)` - there are more fixes to be done for x86. `LIR_Assembler::emit_arraycopy` does not build. P.s. I'm out of time now until next month (probably). ------------- PR: https://git.openjdk.org/lilliput/pull/70 From rkennke at openjdk.org Fri Feb 24 18:53:34 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 24 Feb 2023 18:53:34 GMT Subject: [master] RFR: 8301562: [Lilliput] Runtime flag to enable Lilliput In-Reply-To: References: Message-ID: On Wed, 8 Feb 2023 15:27:26 GMT, Thomas Stuefe wrote: >> This change introduces an experimental runtime flag -XX:[+/-]UseCompactObjectHeaders which can be used to disable Lilliput. The flag guards all the relevant places that directly affect the object layout and the accesses to Klass* etc. The change also restores the previous behaviour when -UseCompactObjectHeaders is selected. >> >> Testing: >> - [x] tier1 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders >> - [x] tier2 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders >> - [x] tier1 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders >> - [x] tier2 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders > > Hi Roman, > > Some fixes from my side, see branch https://github.com/tstuefe/lilliput/commits/fixes-to-usecompactobjectheader > > Suggested changes: > > 1) https://github.com/tstuefe/lilliput/commit/38dcba1d06a56b01cf7c9a593656f1ae5109b9b0 > > this makes KlassAlignmentInBytes and friends runtime-controlled. This is really ugly, but the whole ccs- and compressed klass pointer encoding initialization deserves an overhaul, and this is the least intrusive fix possible. > > 2) https://github.com/tstuefe/lilliput/commit/ad929fafbb4f7c5785e5627b53f0de33dafd2501 > > Needed to fix a crash when compact headers are enabled. > > 3) https://github.com/tstuefe/lilliput/commit/e854428c077e596f81e1349107bc37c2b80c5237 > > Expands gtests to also test all permutations of CCS and CompactHeaders > > 4) https://github.com/tstuefe/lilliput/commit/4c01e6a017bda54e6cdee62ef8814756829fb489 > > Needed to move constraint check for CompressedClassPointerSize to after ergo > > Cheers, thomas @tstuefe thanks for you contributions! Unfortunately, I am still getting failures when building on aarch64: Optimizing the exploded image # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/metaspace.cpp:621 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/rkennke/src/openjdk/lilliput/src/hotspot/share/memory/metaspace.cpp:621), pid=10318, tid=10323 # assert(CompressedKlassPointers::is_valid_base(a)) failed: Sanity # # JRE version: (21.0) (fastdebug build ) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-adhoc.rkennke.lilliput, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x12f2050] Metaspace::reserve_address_space_for_compressed_classes(unsigned long)+0x190 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /local/home/rkennke/src/openjdk/lilliput/make/hs_err_pid10318.log # # ------------- PR: https://git.openjdk.org/lilliput/pull/70 From shade at openjdk.org Fri Feb 24 18:53:35 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 24 Feb 2023 18:53:35 GMT Subject: [master] RFR: 8301562: [Lilliput] Runtime flag to enable Lilliput In-Reply-To: References: Message-ID: On Thu, 2 Feb 2023 13:04:27 GMT, Roman Kennke wrote: > This change introduces an experimental runtime flag -XX:[+/-]UseCompactObjectHeaders which can be used to disable Lilliput. The flag guards all the relevant places that directly affect the object layout and the accesses to Klass* etc. The change also restores the previous behaviour when -UseCompactObjectHeaders is selected. > > Testing: > - [x] tier1 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders > - [x] tier2 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders > - [x] tier1 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders > - [x] tier2 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders I can take a look at x86_32 stuff, if you need it. ------------- PR: https://git.openjdk.org/lilliput/pull/70 From rkennke at openjdk.org Fri Feb 24 18:58:53 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 24 Feb 2023 18:58:53 GMT Subject: [master] RFR: 8301562: [Lilliput] Runtime flag to enable Lilliput [v2] In-Reply-To: References: Message-ID: > This change introduces an experimental runtime flag -XX:[+/-]UseCompactObjectHeaders which can be used to disable Lilliput. The flag guards all the relevant places that directly affect the object layout and the accesses to Klass* etc. The change also restores the previous behaviour when -UseCompactObjectHeaders is selected. > > Testing: > - [x] tier1 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders > - [x] tier2 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders > - [x] tier1 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders > - [x] tier2 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix tests for 32bit builds ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/70/files - new: https://git.openjdk.org/lilliput/pull/70/files/becf81c0..d32fc54c Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=70&range=01 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=70&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/lilliput/pull/70.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/70/head:pull/70 PR: https://git.openjdk.org/lilliput/pull/70 From rkennke at openjdk.org Fri Feb 24 20:54:59 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 24 Feb 2023 20:54:59 GMT Subject: [master] RFR: 8301562: [Lilliput] Runtime flag to enable Lilliput [v3] In-Reply-To: References: Message-ID: > This change introduces an experimental runtime flag -XX:[+/-]UseCompactObjectHeaders which can be used to disable Lilliput. The flag guards all the relevant places that directly affect the object layout and the accesses to Klass* etc. The change also restores the previous behaviour when -UseCompactObjectHeaders is selected. > > One special difficulty is that CDS archives that are generated with compact object headers cannot currently be read with old-style headers, and vice versa. I work around this by disabling CDS when UseCompactObjectHeaders is set to non-default. This makes a few tests fail, but should otherwise be harmless. (In theory, we could implement parsing archives and loading objects with the correct header layout, but ... life's too short ;-) ) > > Testing: > - [x] tier1 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders > - [x] tier2 (x86_64, x86_32, aarch64) +UseCompactObjectHeaders > - [x] tier1 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders > - [x] tier2 (x86_64, x86_32, aarch64) -UseCompactObjectHeaders Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix format specifiers to fix Mac builds ------------- Changes: - all: https://git.openjdk.org/lilliput/pull/70/files - new: https://git.openjdk.org/lilliput/pull/70/files/d32fc54c..f254ea01 Webrevs: - full: https://webrevs.openjdk.org/?repo=lilliput&pr=70&range=02 - incr: https://webrevs.openjdk.org/?repo=lilliput&pr=70&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/lilliput/pull/70.diff Fetch: git fetch https://git.openjdk.org/lilliput pull/70/head:pull/70 PR: https://git.openjdk.org/lilliput/pull/70 From evan.saulpaugh at gmail.com Sun Feb 26 06:56:49 2023 From: evan.saulpaugh at gmail.com (Evan Saulpaugh) Date: Sun, 26 Feb 2023 00:56:49 -0600 Subject: Fwd: bad Repository link on wiki In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: Evan Saulpaugh Date: Wed, Jan 11, 2023 at 5:26?PM Subject: bad Repository link on wiki To: I noticed that the link to the github page at the bottom of the wiki page for Project Lilliput is misspelled and so does not work. "Repository" links to https://github.com/openjdk/liliput instead of https://github.com/openjdk/lilliput See https://wiki.openjdk.org/display/lilliput -Evan Saulpaugh