From vromero at openjdk.org Fri Feb 2 14:18:24 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 Feb 2024 14:18:24 GMT Subject: RFR: 8324873: [lworld] implementation of value classes construction Message-ID: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> implementing value classes construction approach as per JEP-401. There is also a bit of an off-road incursion into jdeps removing references to Q-descriptors, probably should have gone in another patch but the changes are kind of small anyways ------------- Commit messages: - changes to jdeps - allowing assignment to fields before super - Merge branch 'jep_401_javac' into JDK-8324873 - Merge branch 'jep_401_javac' into JDK-8324873 - Merge branch 'jep_401_javac' into JDK-8324873 - 8324873: [lworld] implementation of value classes construction Changes: https://git.openjdk.org/valhalla/pull/990/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=990&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324873 Stats: 161 lines in 21 files changed: 38 ins; 86 del; 37 mod Patch: https://git.openjdk.org/valhalla/pull/990.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/990/head:pull/990 PR: https://git.openjdk.org/valhalla/pull/990 From thartmann at openjdk.org Tue Feb 6 08:30:34 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 08:30:34 GMT Subject: [lworld] RFR: 8324949: [lworld] Migrate compiler tests to new internal API Message-ID: Similar to [JDK-8321293](https://bugs.openjdk.org/browse/JDK-8321293) for runtime, this PR converts all compiler tests to the new internal API. **VM changes:** - Missing null checks in the interpreter, C1 and C2 for field access and withfield - Added C2 intrinsic for newNullRestrictedArray - Disabled some optimizations in C2, will be fixed by [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106) - Improve constant buffer oop detection in C2 - Removed `InlineTypeNode::Identity` which interfered with other optimizations **Test changes:** - Converted all primitive classes to value class using the `@ImplicitlyConstructible` and `@LooselyConsistentValue` annotations - Removed `.ref`, `.val`, `.default`, `_withfield` - Converted all null-free fields to using the `@NullRestricted` annotation - Converted all null-free array allocations to using `ValueClass.newNullRestrictedArray` - Removed `-XX:+EnablePrimitiveClasses` - Removed `PrimitiveClass.asValueType`/`.asPrimaryType` - Removed final keywords where they are implicit - Removed "inline type", "inline class" - Adjusted IR rules and code that expects NPEs - Disabled some test and/or IR verification Code marked with `TODO 8325106` will be addressed by follow-up change [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106). Thanks, Tobias ------------- Commit messages: - Removed trailing whitespace - Copyrights - Reverted classFileParser changes - More fixes - More fixes - Fixed TestJNICalls - Adjusted ToDos - Removed useless tests - Removed -XX:+EnablePrimitiveClasses, jcod test fixes - Removed obsolete tests - ... and 11 more: https://git.openjdk.org/valhalla/compare/16fa7709...9f3928a8 Changes: https://git.openjdk.org/valhalla/pull/991/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=991&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324949 Stats: 5953 lines in 96 files changed: 1671 ins; 1628 del; 2654 mod Patch: https://git.openjdk.org/valhalla/pull/991.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/991/head:pull/991 PR: https://git.openjdk.org/valhalla/pull/991 From thartmann at openjdk.org Tue Feb 6 12:34:10 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 12:34:10 GMT Subject: [lworld] Integrated: 8324949: [lworld] Migrate compiler tests to new internal API In-Reply-To: References: Message-ID: <-i-VnHR_4ARQhnmyix07iYJE6SxnYe-fHOQJl8VW8zM=.7728c116-b296-4e1c-a5df-300d6ed9f4f7@github.com> On Tue, 6 Feb 2024 07:56:57 GMT, Tobias Hartmann wrote: > Similar to [JDK-8321293](https://bugs.openjdk.org/browse/JDK-8321293) for runtime, this PR converts all compiler tests to the new internal API. > > **VM changes:** > - Missing null checks in the interpreter, C1 and C2 for field access and withfield > - Added C2 intrinsic for newNullRestrictedArray > - Disabled some optimizations in C2, will be fixed by [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106) > - Improve constant buffer oop detection in C2 > - Removed `InlineTypeNode::Identity` which interfered with other optimizations > > **Test changes:** > - Converted all primitive classes to value class using the `@ImplicitlyConstructible` and `@LooselyConsistentValue` annotations > - Removed `.ref`, `.val`, `.default`, `_withfield` > - Converted all null-free fields to using the `@NullRestricted` annotation > - Converted all null-free array allocations to using `ValueClass.newNullRestrictedArray` > - Removed `-XX:+EnablePrimitiveClasses` > - Removed `PrimitiveClass.asValueType`/`.asPrimaryType` > - Removed final keywords where they are implicit > - Removed "inline type", "inline class" > - Adjusted IR rules and code that expects NPEs > - Disabled some test and/or IR verification > > Code marked with `TODO 8325106` will be addressed by follow-up change [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106). > > Thanks, > Tobias This pull request has now been integrated. Changeset: a234de99 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/a234de99934f87da22185fb716996df5877c360f Stats: 5953 lines in 96 files changed: 1671 ins; 1628 del; 2654 mod 8324949: [lworld] Migrate compiler tests to new internal API ------------- PR: https://git.openjdk.org/valhalla/pull/991 From thartmann at openjdk.org Tue Feb 6 12:55:36 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 12:55:36 GMT Subject: [lworld] Integrated: [lworld] Problem listing failing javac tests Message-ID: See [JDK-8325322](https://bugs.openjdk.org/browse/JDK-8325322). Best regards, Tobias ------------- Commit messages: - [lworld] Problem listing failing javac tests Changes: https://git.openjdk.org/valhalla/pull/992/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=992&range=00 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/992.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/992/head:pull/992 PR: https://git.openjdk.org/valhalla/pull/992 From thartmann at openjdk.org Tue Feb 6 12:55:36 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 12:55:36 GMT Subject: [lworld] Integrated: [lworld] Problem listing failing javac tests In-Reply-To: References: Message-ID: <8lb6_y1-zHVM8A65nhEWaNUbhtCXl7DxFlq8BKj1Tzc=.b94783be-65c3-4800-9ff4-be7c6bda4ff5@github.com> On Tue, 6 Feb 2024 12:50:29 GMT, Tobias Hartmann wrote: > See [JDK-8325322](https://bugs.openjdk.org/browse/JDK-8325322). > > Best regards, > Tobias This pull request has now been integrated. Changeset: 76d0026f Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/76d0026ffd07588ea0de7ca4201283ca20cfcc8c Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod [lworld] Problem listing failing javac tests ------------- PR: https://git.openjdk.org/valhalla/pull/992 From thartmann at openjdk.org Tue Feb 6 14:12:21 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 14:12:21 GMT Subject: [lworld] Integrated: [lworld] Problem listing ctw test triggering 8321734 Message-ID: See [JDK-8321734](https://bugs.openjdk.org/browse/JDK-8321734). Thanks, Tobias ------------- Commit messages: - [lworld] Problem listing ctw test triggering 8321734 Changes: https://git.openjdk.org/valhalla/pull/993/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=993&range=00 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/993.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/993/head:pull/993 PR: https://git.openjdk.org/valhalla/pull/993 From thartmann at openjdk.org Tue Feb 6 14:12:21 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 14:12:21 GMT Subject: [lworld] Integrated: [lworld] Problem listing ctw test triggering 8321734 In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 14:07:03 GMT, Tobias Hartmann wrote: > See [JDK-8321734](https://bugs.openjdk.org/browse/JDK-8321734). > > Thanks, > Tobias This pull request has now been integrated. Changeset: da697a0b Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/da697a0bfb26285ae845b09200afdc941fe51dfc Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod [lworld] Problem listing ctw test triggering 8321734 ------------- PR: https://git.openjdk.org/valhalla/pull/993 From thartmann at openjdk.org Tue Feb 6 16:13:27 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 16:13:27 GMT Subject: [lworld] RFR: 8324117: [lworld] C1 hits "Can not patch access to flat field" assert after JDK-8320437 Message-ID: <4VC1y-ofhjK-Sehc2wFs3U5GECTV57HxdXm5eDfeN-I=.8e6f9c5f-3db0-4ce3-9bb1-f04979424f33@github.com> Current code assumes that even if the holder is not loaded, we always know at compile time if a field type is an inline type. That's not guaranteed after the removal of Q-types and as a result we hit an assert when trying to patch a flat field at runtime. I don't remember why we had this complicated code before but we can simply deopt at runtime when we detect the flat field during patching. The code will then be re-compiled. Thanks, Tobias ------------- Commit messages: - 8324117: [lworld] C1 hits "Can not patch access to flat field" assert after JDK-8320437 Changes: https://git.openjdk.org/valhalla/pull/994/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=994&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324117 Stats: 48 lines in 3 files changed: 9 ins; 38 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/994.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/994/head:pull/994 PR: https://git.openjdk.org/valhalla/pull/994 From thartmann at openjdk.org Tue Feb 6 17:36:09 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 17:36:09 GMT Subject: [lworld] Integrated: [lworld] More problem listing Message-ID: See [JDK-8325343](https://bugs.openjdk.org/browse/JDK-8325343) and [JDK-8325344](https://bugs.openjdk.org/browse/JDK-8325344). Best regards, Tobias ------------- Commit messages: - [lworld] More problem listing Changes: https://git.openjdk.org/valhalla/pull/995/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=995&range=00 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/995.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/995/head:pull/995 PR: https://git.openjdk.org/valhalla/pull/995 From thartmann at openjdk.org Tue Feb 6 17:36:10 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 17:36:10 GMT Subject: [lworld] Integrated: [lworld] More problem listing In-Reply-To: References: Message-ID: <4GaBKba-wj771WjlEp4C8QTmVYvdWRDp7GF_vkbQxhA=.3f60da53-2080-4db0-a0f4-914b375f75fb@github.com> On Tue, 6 Feb 2024 17:28:00 GMT, Tobias Hartmann wrote: > See [JDK-8325343](https://bugs.openjdk.org/browse/JDK-8325343) and [JDK-8325344](https://bugs.openjdk.org/browse/JDK-8325344). > > Best regards, > Tobias This pull request has now been integrated. Changeset: be6ae354 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/be6ae3549893cfd67e706d54e23ca414d66084b4 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod [lworld] More problem listing ------------- PR: https://git.openjdk.org/valhalla/pull/995 From thartmann at openjdk.org Tue Feb 6 17:40:12 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 17:40:12 GMT Subject: [lworld] Integrated: 8324117: [lworld] C1 hits "Can not patch access to flat field" assert after JDK-8320437 In-Reply-To: <4VC1y-ofhjK-Sehc2wFs3U5GECTV57HxdXm5eDfeN-I=.8e6f9c5f-3db0-4ce3-9bb1-f04979424f33@github.com> References: <4VC1y-ofhjK-Sehc2wFs3U5GECTV57HxdXm5eDfeN-I=.8e6f9c5f-3db0-4ce3-9bb1-f04979424f33@github.com> Message-ID: On Tue, 6 Feb 2024 16:08:34 GMT, Tobias Hartmann wrote: > Current code assumes that even if the holder is not loaded, we always know at compile time if a field type is an inline type. That's not guaranteed after the removal of Q-types and as a result we hit an assert when trying to patch a flat field at runtime. > > I don't remember why we had this complicated code before but we can simply deopt at runtime when we detect the flat field during patching. The code will then be re-compiled. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 02b59630 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/02b5963020e5f81db85d231a911672960bf72c00 Stats: 48 lines in 3 files changed: 9 ins; 38 del; 1 mod 8324117: [lworld] C1 hits "Can not patch access to flat field" assert after JDK-8320437 ------------- PR: https://git.openjdk.org/valhalla/pull/994 From mchung at openjdk.org Tue Feb 6 18:17:11 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 6 Feb 2024 18:17:11 GMT Subject: [lworld] RFR: 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE Message-ID: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> Trivial 1-line fix is to check if the type is found or not before calling `PrimitiveClass::asPrimaryType`. ------------- Commit messages: - 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE Changes: https://git.openjdk.org/valhalla/pull/996/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325343 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/996.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/996/head:pull/996 PR: https://git.openjdk.org/valhalla/pull/996 From thartmann at openjdk.org Tue Feb 6 18:23:59 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Feb 2024 18:23:59 GMT Subject: [lworld] RFR: 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE In-Reply-To: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> References: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> Message-ID: <4DrxMO9T3MkGdGjtg3bK5Jfxp3_qnwqgqMV4HajLYfs=.ad5c2053-f00a-4471-8ee3-b72f6c78e287@github.com> On Tue, 6 Feb 2024 18:12:44 GMT, Mandy Chung wrote: > Trivial 1-line fix is to check if the type is found or not before calling `PrimitiveClass::asPrimaryType`. You need to remove the test from the problem list. See https://github.com/openjdk/valhalla/commit/be6ae3549893cfd67e706d54e23ca414d66084b4 ------------- PR Comment: https://git.openjdk.org/valhalla/pull/996#issuecomment-1930514009 PR Comment: https://git.openjdk.org/valhalla/pull/996#issuecomment-1930514651 From mchung at openjdk.org Tue Feb 6 18:32:21 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 6 Feb 2024 18:32:21 GMT Subject: [lworld] RFR: 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE [v2] In-Reply-To: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> References: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> Message-ID: > Trivial 1-line fix is to check if the type is found or not before calling `PrimitiveClass::asPrimaryType`. Mandy Chung 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: - Remove from problem list - 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/996/files - new: https://git.openjdk.org/valhalla/pull/996/files/8852511a..debb26df Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=996&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=996&range=00-01 Stats: 50 lines in 4 files changed: 11 ins; 38 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/996.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/996/head:pull/996 PR: https://git.openjdk.org/valhalla/pull/996 From mchung at openjdk.org Tue Feb 6 18:32:21 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 6 Feb 2024 18:32:21 GMT Subject: [lworld] RFR: 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE In-Reply-To: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> References: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> Message-ID: On Tue, 6 Feb 2024 18:12:44 GMT, Mandy Chung wrote: > Trivial 1-line fix is to check if the type is found or not before calling `PrimitiveClass::asPrimaryType`. Fixed. Thanks. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/996#issuecomment-1930526224 From vromero at openjdk.org Wed Feb 7 00:02:29 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Feb 2024 00:02:29 GMT Subject: RFR: 8324873: [lworld] implementation of value classes construction [v2] In-Reply-To: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> References: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> Message-ID: > implementing value classes construction approach as per JEP-401. There is also a bit of an off-road incursion into jdeps removing references to Q-descriptors, probably should have gone in another patch but the changes are kind of small anyways Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: regression tests ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/990/files - new: https://git.openjdk.org/valhalla/pull/990/files/eaee4aa1..50c6c15f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=990&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=990&range=00-01 Stats: 808 lines in 7 files changed: 802 ins; 0 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/990.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/990/head:pull/990 PR: https://git.openjdk.org/valhalla/pull/990 From thartmann at openjdk.org Wed Feb 7 06:36:08 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 7 Feb 2024 06:36:08 GMT Subject: [lworld] RFR: 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE [v2] In-Reply-To: References: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> Message-ID: On Tue, 6 Feb 2024 18:32:21 GMT, Mandy Chung wrote: >> Trivial 1-line fix is to check if the type is found or not before calling `PrimitiveClass::asPrimaryType`. > > Mandy Chung 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: > > - Remove from problem list > - 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE Looks reasonable to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/996#pullrequestreview-1866996574 From thartmann at openjdk.org Wed Feb 7 11:42:17 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 7 Feb 2024 11:42:17 GMT Subject: [lworld] RFR: 8325398: [lworld] C1 should not patch null restricted field stores Message-ID: Follow-up from https://git.openjdk.org/valhalla/pull/994: We also need to deopt when patching a null-free field store because the compiled code is missing the null check. Thanks, Tobias ------------- Commit messages: - 8325398: [lworld] C1 should not patch null restricted field stores Changes: https://git.openjdk.org/valhalla/pull/997/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=997&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325398 Stats: 34 lines in 2 files changed: 33 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/997.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/997/head:pull/997 PR: https://git.openjdk.org/valhalla/pull/997 From thartmann at openjdk.org Wed Feb 7 11:54:06 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 7 Feb 2024 11:54:06 GMT Subject: [lworld] Integrated: 8325398: [lworld] C1 should not patch null restricted field stores In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 11:38:17 GMT, Tobias Hartmann wrote: > Follow-up from https://git.openjdk.org/valhalla/pull/994: We also need to deopt when patching a null-free field store because the compiled code is missing the null check. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 5d1d69d6 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/5d1d69d6fe19aa16f9367955c5bd2191b0eba2e0 Stats: 34 lines in 2 files changed: 33 ins; 0 del; 1 mod 8325398: [lworld] C1 should not patch null restricted field stores ------------- PR: https://git.openjdk.org/valhalla/pull/997 From mchung at openjdk.org Wed Feb 7 17:07:22 2024 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 7 Feb 2024 17:07:22 GMT Subject: [lworld] Integrated: 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE In-Reply-To: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> References: <0PFGXOFZQodyyn1ixO3mU_hvDv_cPBd57NE-orhw8hU=.7546d73f-5c68-4669-aaf9-b8098d2882f7@github.com> Message-ID: On Tue, 6 Feb 2024 18:12:44 GMT, Mandy Chung wrote: > Trivial 1-line fix is to check if the type is found or not before calling `PrimitiveClass::asPrimaryType`. This pull request has now been integrated. Changeset: 80979ce3 Author: Mandy Chung URL: https://git.openjdk.org/valhalla/commit/80979ce38165821ecd7a107dd5804b6ced7a7f89 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/996 From acobbs at openjdk.org Wed Feb 7 17:17:19 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 7 Feb 2024 17:17:19 GMT Subject: RFR: 8324873: [lworld] implementation of value classes construction [v2] In-Reply-To: References: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> Message-ID: On Wed, 7 Feb 2024 00:02:29 GMT, Vicente Romero wrote: >> implementing value classes construction approach as per JEP-401. There is also a bit of an off-road incursion into jdeps removing references to Q-descriptors, probably should have gone in another patch but the changes are kind of small anyways > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > regression tests src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 535: > 533: for (var accessFlag : LocationToFlags.locationToFlags.get(location)) { > 534: int accessMask = accessFlag.mask(); > 535: if ((mask & accessMask) != 0) { Extra whitespace glitch here. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4171: > 4169: > 4170: // If super()/this() isn't first, require "statements before super()" feature > 4171: if (!firstStatement && !classSym.isValueClass()) // let's wave value classes for now wave ? waive src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1518: > 1516: if (env1.info.ctorPrologue && (sym.flags_field & SYNTHETIC) == 0) { > 1517: if (sym.owner.isValueClass()) { > 1518: if (!env.tree.hasTag(ASSIGN) || !TreeInfo.isIdentOrThisDotIdent(((JCAssign)env.tree).lhs)) { Wondering if this would catch an unqualified assignment to a superclass field? (Apologies if this doesn't make sense as I'm not completely familiar with value classes). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/990#discussion_r1481823461 PR Review Comment: https://git.openjdk.org/valhalla/pull/990#discussion_r1481823368 PR Review Comment: https://git.openjdk.org/valhalla/pull/990#discussion_r1481823230 From vromero at openjdk.org Wed Feb 7 18:10:03 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 7 Feb 2024 18:10:03 GMT Subject: RFR: 8324873: [lworld] implementation of value classes construction [v2] In-Reply-To: References: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> Message-ID: On Wed, 7 Feb 2024 17:14:00 GMT, Archie Cobbs wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> regression tests > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4171: > >> 4169: >> 4170: // If super()/this() isn't first, require "statements before super()" feature >> 4171: if (!firstStatement && !classSym.isValueClass()) // let's wave value classes for now > > wave ? waive oops ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/990#discussion_r1481891788 From rriggs at openjdk.org Wed Feb 7 19:27:09 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 7 Feb 2024 19:27:09 GMT Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits Message-ID: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> Update the substitutability implementation to match the new JLS for JEP 401. Float and double values should be compared for equality using the raw bits. ------------- Commit messages: - 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits Changes: https://git.openjdk.org/valhalla/pull/998/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=998&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298659 Stats: 54 lines in 3 files changed: 38 ins; 4 del; 12 mod Patch: https://git.openjdk.org/valhalla/pull/998.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/998/head:pull/998 PR: https://git.openjdk.org/valhalla/pull/998 From mchung at openjdk.org Wed Feb 7 22:35:05 2024 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 7 Feb 2024 22:35:05 GMT Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits In-Reply-To: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> References: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> Message-ID: <-DSsTV2r1EpjC1kRO5N6EJVPfIzNrTritSh_AGp2GPc=.aaad54a7-3dab-4543-a4a9-5e84e7ffd2f0@github.com> On Wed, 7 Feb 2024 19:22:32 GMT, Roger Riggs wrote: > Update the substitutability implementation to match the new JLS for JEP 401. > Float and double values should be compared for equality using the raw bits. src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 183: > 181: private static boolean eq(long a, long b) { return a == b; } > 182: private static boolean eq(float a, float b) { > 183: return Float.floatToRawIntBits(a) == Float.floatToRawIntBits(b); `ObjectMethods` are used for records as well and so these methods should not be modified. Instead I suggest to add new methods in `ValueObjectMethods` class for value object substutitability comparison of float/double. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/998#discussion_r1482176440 From dsimms at openjdk.org Thu Feb 8 08:38:09 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 8 Feb 2024 08:38:09 GMT Subject: [lworld] RFR: 8324114: [lworld] GTestWrapper.java fails with "assert(LockingMode == LM_LEGACY) failed: should only be called with legacy stack locking" In-Reply-To: References: Message-ID: <7QWdQIG4QA5dt6MTRgRCORjdT-FHPmO89hhSjOxd_jg=.9275490f-f515-43d7-a342-b4d7fe54bd5e@github.com> On Fri, 19 Jan 2024 08:11:03 GMT, Christian Hagedorn wrote: > This patch fixes the gtests which fail with the lightweight locking mode (`-XX:LockingMode=2`) but also with heavy monitors (`-XX:LockingMode=0`). I've only noticed while working on this bug that in the meantime, we temporary enforce legacy stack-locking (`-XX:LockingMode=1`) since merging jdk-22+17: > https://github.com/openjdk/valhalla/blob/16fa7709f15465e736dd3a83707ffe88d7bc61bd/src/hotspot/share/runtime/arguments.cpp#L1922-L1925 > > Nevertheless, I think it's still worth to propose these test fixes now since we probably want to support lightweight locking at some point. > > The gtest used `markWork::has_locker()` which only works with `LM_LEGACY`. For `LM_LIGHTWEIGHT`, we need to call `markWord::is_fast_locked()`. Additionally, when running with `LM_MONITOR`, the test to match some things in the mark word fails because we only use heavy monitors and do not use the mark word bits. > > Thanks, > Christian Looks good ------------- Marked as reviewed by dsimms (Committer). PR Review: https://git.openjdk.org/valhalla/pull/973#pullrequestreview-1869545422 From thartmann at openjdk.org Thu Feb 8 09:01:05 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 8 Feb 2024 09:01:05 GMT Subject: [lworld] RFR: 8324114: [lworld] GTestWrapper.java fails with "assert(LockingMode == LM_LEGACY) failed: should only be called with legacy stack locking" In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 08:11:03 GMT, Christian Hagedorn wrote: > This patch fixes the gtests which fail with the lightweight locking mode (`-XX:LockingMode=2`) but also with heavy monitors (`-XX:LockingMode=0`). I've only noticed while working on this bug that in the meantime, we temporary enforce legacy stack-locking (`-XX:LockingMode=1`) since merging jdk-22+17: > https://github.com/openjdk/valhalla/blob/16fa7709f15465e736dd3a83707ffe88d7bc61bd/src/hotspot/share/runtime/arguments.cpp#L1922-L1925 > > Nevertheless, I think it's still worth to propose these test fixes now since we probably want to support lightweight locking at some point. > > The gtest used `markWork::has_locker()` which only works with `LM_LEGACY`. For `LM_LIGHTWEIGHT`, we need to call `markWord::is_fast_locked()`. Additionally, when running with `LM_MONITOR`, the test to match some things in the mark word fails because we only use heavy monitors and do not use the mark word bits. > > Thanks, > Christian Marked as reviewed by thartmann (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/973#pullrequestreview-1869583304 From chagedorn at openjdk.org Thu Feb 8 09:01:05 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 8 Feb 2024 09:01:05 GMT Subject: [lworld] RFR: 8324114: [lworld] GTestWrapper.java fails with "assert(LockingMode == LM_LEGACY) failed: should only be called with legacy stack locking" In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 08:11:03 GMT, Christian Hagedorn wrote: > This patch fixes the gtests which fail with the lightweight locking mode (`-XX:LockingMode=2`) but also with heavy monitors (`-XX:LockingMode=0`). I've only noticed while working on this bug that in the meantime, we temporary enforce legacy stack-locking (`-XX:LockingMode=1`) since merging jdk-22+17: > https://github.com/openjdk/valhalla/blob/16fa7709f15465e736dd3a83707ffe88d7bc61bd/src/hotspot/share/runtime/arguments.cpp#L1922-L1925 > > Nevertheless, I think it's still worth to propose these test fixes now since we probably want to support lightweight locking at some point. > > The gtest used `markWork::has_locker()` which only works with `LM_LEGACY`. For `LM_LIGHTWEIGHT`, we need to call `markWord::is_fast_locked()`. Additionally, when running with `LM_MONITOR`, the test to match some things in the mark word fails because we only use heavy monitors and do not use the mark word bits. > > Thanks, > Christian Thanks for your reviews! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/973#issuecomment-1933621002 From chagedorn at openjdk.org Thu Feb 8 09:01:05 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 8 Feb 2024 09:01:05 GMT Subject: [lworld] Integrated: 8324114: [lworld] GTestWrapper.java fails with "assert(LockingMode == LM_LEGACY) failed: should only be called with legacy stack locking" In-Reply-To: References: Message-ID: <8YelqSvl-rYqVaquCT44iz4DkIVcvbicQ2Vjggnae_o=.930b5121-cce6-4303-b3ec-46c94aabd109@github.com> On Fri, 19 Jan 2024 08:11:03 GMT, Christian Hagedorn wrote: > This patch fixes the gtests which fail with the lightweight locking mode (`-XX:LockingMode=2`) but also with heavy monitors (`-XX:LockingMode=0`). I've only noticed while working on this bug that in the meantime, we temporary enforce legacy stack-locking (`-XX:LockingMode=1`) since merging jdk-22+17: > https://github.com/openjdk/valhalla/blob/16fa7709f15465e736dd3a83707ffe88d7bc61bd/src/hotspot/share/runtime/arguments.cpp#L1922-L1925 > > Nevertheless, I think it's still worth to propose these test fixes now since we probably want to support lightweight locking at some point. > > The gtest used `markWork::has_locker()` which only works with `LM_LEGACY`. For `LM_LIGHTWEIGHT`, we need to call `markWord::is_fast_locked()`. Additionally, when running with `LM_MONITOR`, the test to match some things in the mark word fails because we only use heavy monitors and do not use the mark word bits. > > Thanks, > Christian This pull request has now been integrated. Changeset: 170d8c68 Author: Christian Hagedorn Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/170d8c68c7a15ca3e7419b3cc435237658a83d10 Stats: 18 lines in 1 file changed: 14 ins; 0 del; 4 mod 8324114: [lworld] GTestWrapper.java fails with "assert(LockingMode == LM_LEGACY) failed: should only be called with legacy stack locking" Reviewed-by: dsimms, thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/973 From thartmann at openjdk.org Thu Feb 8 15:13:19 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 8 Feb 2024 15:13:19 GMT Subject: [lworld] RFR: 8325417: [lworld] Incorrect re-execution state at uncommon traps emitted by acmp Message-ID: <6xpX7Xp29f9fjQaNfNMXLoqBJnJjFm6IlT1RHTQ7yk8=.6b72406b-0355-4df2-81a3-351fa61100e5@github.com> The `acmp` implementation in C2 uses `Parse::do_if` for pointer comparison and other checks. That method then adds traps to (unstable) if branches that are never taken based on profiling. `OptimizeUnstableIf` would set an incorrect re-execution state because it assumes that there is a 1-1 mapping between the if and the acmp branches and that hitting a trap means that we will take the corresponding acmp branch on re-execution. That is not correct and will lead to pruning of supposedly dead locals and thus incorrect re-execution. I also had to adjust some tests that incorrectly assumed that we should skip the substitutability test if acmp profiling suggested that the operands are always equal and only keep the pointer comparison. That's not correct because two value objects can be equal/substitutable even if the pointer comparison is false. Thanks, Tobias ------------- Commit messages: - Test fixes - Test - 8325417: [lworld] Incorrect re-execution state at uncommon traps emitted by acmp Changes: https://git.openjdk.org/valhalla/pull/1000/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1000&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325417 Stats: 179 lines in 6 files changed: 157 ins; 5 del; 17 mod Patch: https://git.openjdk.org/valhalla/pull/1000.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1000/head:pull/1000 PR: https://git.openjdk.org/valhalla/pull/1000 From rriggs at openjdk.org Thu Feb 8 15:36:09 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 8 Feb 2024 15:36:09 GMT Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits In-Reply-To: <-DSsTV2r1EpjC1kRO5N6EJVPfIzNrTritSh_AGp2GPc=.aaad54a7-3dab-4543-a4a9-5e84e7ffd2f0@github.com> References: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> <-DSsTV2r1EpjC1kRO5N6EJVPfIzNrTritSh_AGp2GPc=.aaad54a7-3dab-4543-a4a9-5e84e7ffd2f0@github.com> Message-ID: On Wed, 7 Feb 2024 22:32:28 GMT, Mandy Chung wrote: >> Update the substitutability implementation to match the new JLS for JEP 401. >> Float and double values should be compared for equality using the raw bits. > > src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 183: > >> 181: private static boolean eq(long a, long b) { return a == b; } >> 182: private static boolean eq(float a, float b) { >> 183: return Float.floatToRawIntBits(a) == Float.floatToRawIntBits(b); > > `ObjectMethods` are used for records as well and so these methods should not be modified. Instead I suggest to add new methods in `ValueObjectMethods` class for value object substutitability comparison of float/double. I'm beginning to doubt the wisdom of a difference in field comparisons between value objects and records (and the `==` operator). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/998#discussion_r1483174418 From thartmann at openjdk.org Thu Feb 8 15:38:11 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 8 Feb 2024 15:38:11 GMT Subject: [lworld] Integrated: 8325417: [lworld] Incorrect re-execution state at uncommon traps emitted by acmp In-Reply-To: <6xpX7Xp29f9fjQaNfNMXLoqBJnJjFm6IlT1RHTQ7yk8=.6b72406b-0355-4df2-81a3-351fa61100e5@github.com> References: <6xpX7Xp29f9fjQaNfNMXLoqBJnJjFm6IlT1RHTQ7yk8=.6b72406b-0355-4df2-81a3-351fa61100e5@github.com> Message-ID: <1TjlvdDiGa7wzg89GGGUC-hIPKLCx7i7jQ1Qz3twWKQ=.bd40be68-6319-49ca-ac0c-8f97c9dd7d55@github.com> On Thu, 8 Feb 2024 13:29:10 GMT, Tobias Hartmann wrote: > The `acmp` implementation in C2 uses `Parse::do_if` for pointer comparison and other checks. That method then adds traps to (unstable) if branches that are never taken based on profiling. `OptimizeUnstableIf` would set an incorrect re-execution state because it assumes that there is a 1-1 mapping between the if and the acmp branches and that hitting a trap means that we will take the corresponding acmp branch on re-execution. That is not correct and will lead to pruning of supposedly dead locals and thus incorrect re-execution. > > I also had to adjust some tests that incorrectly assumed that we should skip the substitutability test if acmp profiling suggested that the operands are always equal and only keep the pointer comparison. That's not correct because two value objects can be equal/substitutable even if the pointer comparison is false. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 2298d933 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/2298d9339eb332a2053bf633d8e710194cacbb06 Stats: 179 lines in 6 files changed: 157 ins; 5 del; 17 mod 8325417: [lworld] Incorrect re-execution state at uncommon traps emitted by acmp ------------- PR: https://git.openjdk.org/valhalla/pull/1000 From amenkov at openjdk.org Thu Feb 8 22:32:23 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 8 Feb 2024 22:32:23 GMT Subject: [lworld] RFR: JDK-8325344: [lworld] RedefinePrimitive.java fails javac compilation Message-ID: Fixed the test after changes in library ------------- Commit messages: - Merge branch 'lworld' into RedefinePrimitive_test - test fix Changes: https://git.openjdk.org/valhalla/pull/1001/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1001&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325344 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1001.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1001/head:pull/1001 PR: https://git.openjdk.org/valhalla/pull/1001 From mchung at openjdk.org Thu Feb 8 22:46:08 2024 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 8 Feb 2024 22:46:08 GMT Subject: [lworld] RFR: JDK-8325344: [lworld] RedefinePrimitive.java fails javac compilation In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 22:26:21 GMT, Alex Menkov wrote: > Fixed the test after changes in library This change is fine in fixing the compilation error. We are migrating tests that use primitive value class to use the internal APIs (you can reference #991). Can you repurpose this issue to update the test? The test should be renamed too like `RedefineNullRestrictedValues.java` something like that. ------------- PR Review: https://git.openjdk.org/valhalla/pull/1001#pullrequestreview-1871391591 From thartmann at openjdk.org Fri Feb 9 10:32:14 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 9 Feb 2024 10:32:14 GMT Subject: [lworld] RFR: 8325546: [lworld] Missing barrier in C1 compiled code on AArch64 Message-ID: <3XdGHkPMfs_VyDwi7Pse7lVaD4tap8pYisGjh2BsxaE=.42c84549-ffee-426e-9e19-ca3d9456bbd5@github.com> Similar to [JDK-8264414](https://bugs.openjdk.org/browse/JDK-8264414), a membar is required after loading from a flat array to prevent a store that publishes the buffer reference to be executed before the initializing stores have completed. Thanks, Tobias ------------- Commit messages: - 8325546: [lworld] Missing barrier in C1 compiled code on AArch64 Changes: https://git.openjdk.org/valhalla/pull/1002/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1002&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325546 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1002.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1002/head:pull/1002 PR: https://git.openjdk.org/valhalla/pull/1002 From thartmann at openjdk.org Fri Feb 9 10:40:08 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 9 Feb 2024 10:40:08 GMT Subject: [lworld] Integrated: 8325546: [lworld] Missing barrier in C1 compiled code on AArch64 In-Reply-To: <3XdGHkPMfs_VyDwi7Pse7lVaD4tap8pYisGjh2BsxaE=.42c84549-ffee-426e-9e19-ca3d9456bbd5@github.com> References: <3XdGHkPMfs_VyDwi7Pse7lVaD4tap8pYisGjh2BsxaE=.42c84549-ffee-426e-9e19-ca3d9456bbd5@github.com> Message-ID: <81mEEycRla5XlyyJmGvhuexDA-TStUnkla8Sb6a9jac=.a338d1f6-85c8-419d-a443-c3c65753cfb6@github.com> On Fri, 9 Feb 2024 10:28:23 GMT, Tobias Hartmann wrote: > Similar to [JDK-8264414](https://bugs.openjdk.org/browse/JDK-8264414), a membar is required after loading from a flat array to prevent a store that publishes the buffer reference to be executed before the initializing stores have completed. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 8b709379 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/8b709379d4c8b6cbfe004eafdd21c243faa738b1 Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod 8325546: [lworld] Missing barrier in C1 compiled code on AArch64 ------------- PR: https://git.openjdk.org/valhalla/pull/1002 From vromero at openjdk.org Fri Feb 9 15:44:27 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Feb 2024 15:44:27 GMT Subject: RFR: 8324873: [lworld] implementation of value classes construction [v3] In-Reply-To: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> References: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> Message-ID: <4sunDTNDKbXPEkx3yFL_QfJMRQ0gA74-ZHGOXHoA6lc=.1e77fbf4-e7b9-4d1c-b0e6-2261ecd3e4b6@github.com> > implementing value classes construction approach as per JEP-401. There is also a bit of an off-road incursion into jdeps removing references to Q-descriptors, probably should have gone in another patch but the changes are kind of small anyways Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments, adding more regression tests ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/990/files - new: https://git.openjdk.org/valhalla/pull/990/files/50c6c15f..f93903b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=990&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=990&range=01-02 Stats: 116 lines in 11 files changed: 100 ins; 11 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/990.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/990/head:pull/990 PR: https://git.openjdk.org/valhalla/pull/990 From liach at openjdk.org Fri Feb 9 16:25:09 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 Feb 2024 16:25:09 GMT Subject: RFR: 8324873: [lworld] implementation of value classes construction [v3] In-Reply-To: <4sunDTNDKbXPEkx3yFL_QfJMRQ0gA74-ZHGOXHoA6lc=.1e77fbf4-e7b9-4d1c-b0e6-2261ecd3e4b6@github.com> References: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> <4sunDTNDKbXPEkx3yFL_QfJMRQ0gA74-ZHGOXHoA6lc=.1e77fbf4-e7b9-4d1c-b0e6-2261ecd3e4b6@github.com> Message-ID: On Fri, 9 Feb 2024 15:44:27 GMT, Vicente Romero wrote: >> implementing value classes construction approach as per JEP-401. There is also a bit of an off-road incursion into jdeps removing references to Q-descriptors, probably should have gone in another patch but the changes are kind of small anyways > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review comments, adding more regression tests src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 371: > 369: } else { > 370: return (cffv.compareTo(ClassFileFormatVersion.RELEASE_2) >= 0 && > 371: cffv.compareTo(ClassFileFormatVersion.RELEASE_16) <= 0) ? We can probably change this ternary operator to be part of the if-else chain to make it clearer. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/990#discussion_r1484540887 From rriggs at openjdk.org Fri Feb 9 16:48:35 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Feb 2024 16:48:35 GMT Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits [v2] In-Reply-To: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> References: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> Message-ID: > Update the substitutability implementation to match the new JLS for JEP 401. > Float and double values should be compared for equality using the raw bits. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revert change to ObjectMethods to avoid changing behavior of equals for floats in records. Create a separate cache of method pointers for substitutablity test for primitives in ValueObjectMethods. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/998/files - new: https://git.openjdk.org/valhalla/pull/998/files/b7a9e0f2..c951d154 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=998&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=998&range=00-01 Stats: 42 lines in 2 files changed: 32 ins; 4 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/998.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/998/head:pull/998 PR: https://git.openjdk.org/valhalla/pull/998 From liach at openjdk.org Fri Feb 9 16:58:04 2024 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 Feb 2024 16:58:04 GMT Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits [v2] In-Reply-To: References: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> <-DSsTV2r1EpjC1kRO5N6EJVPfIzNrTritSh_AGp2GPc=.aaad54a7-3dab-4543-a4a9-5e84e7ffd2f0@github.com> Message-ID: On Thu, 8 Feb 2024 15:33:29 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 183: >> >>> 181: private static boolean eq(long a, long b) { return a == b; } >>> 182: private static boolean eq(float a, float b) { >>> 183: return Float.floatToRawIntBits(a) == Float.floatToRawIntBits(b); >> >> `ObjectMethods` are used for records as well and so these methods should not be modified. Instead I suggest to add new methods in `ValueObjectMethods` class for value object substutitability comparison of float/double. > > I'm beginning to doubt the wisdom of a difference in field comparisons between value objects and records (and the `==` operator). I believe the discrepancy in `equals` and `==` is valid; value objects may contain reference pointers too, thus they still should be compared by `equals` instead of `==`. Having double fields act like reference fields is fine. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/998#discussion_r1484577660 From duke at openjdk.org Fri Feb 9 17:08:10 2024 From: duke at openjdk.org (Jens Lidestrom) Date: Fri, 9 Feb 2024 17:08:10 GMT Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits [v2] In-Reply-To: References: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> Message-ID: On Fri, 9 Feb 2024 16:48:35 GMT, Roger Riggs wrote: >> Update the substitutability implementation to match the new JLS for JEP 401. >> Float and double values should be compared for equality using the raw bits. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert change to ObjectMethods to avoid changing behavior of equals for floats in records. > Create a separate cache of method pointers for substitutablity test for primitives in ValueObjectMethods. src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java line 697: > 695: * this method returns {@code a == b} with the following exception: > 696: *
    > 697: *
  • For primitive types {@code float} and {@code double} the I'm not sure if this is public documentation for users or internal documentation for implementers. If this is for users then it might be helpful with a description of what the new equality semantics actually implies for NaNs and the various zeros and infinities. Having to look up `toRawBits` and figure it out will be hard for most people. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/998#discussion_r1484587637 From vromero at openjdk.org Fri Feb 9 17:30:33 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Feb 2024 17:30:33 GMT Subject: RFR: 8324873: [lworld] implementation of value classes construction [v4] In-Reply-To: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> References: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> Message-ID: > implementing value classes construction approach as per JEP-401. There is also a bit of an off-road incursion into jdeps removing references to Q-descriptors, probably should have gone in another patch but the changes are kind of small anyways Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: minor fixes ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/990/files - new: https://git.openjdk.org/valhalla/pull/990/files/f93903b9..57249179 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=990&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=990&range=02-03 Stats: 11 lines in 4 files changed: 3 ins; 5 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/990.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/990/head:pull/990 PR: https://git.openjdk.org/valhalla/pull/990 From vromero at openjdk.org Fri Feb 9 17:30:35 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Feb 2024 17:30:35 GMT Subject: Integrated: 8324873: [lworld] implementation of value classes construction In-Reply-To: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> References: <7NVfAV0XZO_CK950ctgmC4ZlxQBsB_fwjMERho2H-bA=.8e1bbf6d-aa68-4ee6-a9b9-14fa41c36cd0@github.com> Message-ID: On Fri, 2 Feb 2024 14:12:35 GMT, Vicente Romero wrote: > implementing value classes construction approach as per JEP-401. There is also a bit of an off-road incursion into jdeps removing references to Q-descriptors, probably should have gone in another patch but the changes are kind of small anyways This pull request has now been integrated. Changeset: c518a142 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/c518a14209638fb15391cbe774ebd29a3e658565 Stats: 1068 lines in 31 files changed: 934 ins; 93 del; 41 mod 8324873: [lworld] implementation of value classes construction ------------- PR: https://git.openjdk.org/valhalla/pull/990 From rriggs at openjdk.org Fri Feb 9 17:38:03 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Feb 2024 17:38:03 GMT Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits [v2] In-Reply-To: References: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com> Message-ID: On Fri, 9 Feb 2024 17:04:53 GMT, Jens Lidestrom wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change to ObjectMethods to avoid changing behavior of equals for floats in records. >> Create a separate cache of method pointers for substitutablity test for primitives in ValueObjectMethods. > > src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java line 697: > >> 695: * this method returns {@code a == b} with the following exception: >> 696: *
      >> 697: *
    • For primitive types {@code float} and {@code double} the > > I'm not sure if this is public documentation for users or internal documentation for implementers. > > If this is for users then it might be helpful with a description of what the new equality semantics actually implies for NaNs and the various zeros and infinities. > > Having to look up `toRawBits` and figure it out will be hard for most people. These are implementation notes; the JLS specifies the behavior of value classes, operations of values, and the details of what it means for a value to be substitutable. Its still open as to how/where the semantics would appear in javadoc. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/998#discussion_r1484619048 From vromero at openjdk.org Fri Feb 9 17:52:07 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Feb 2024 17:52:07 GMT Subject: RFR: Merge lworld Message-ID: Merge branch 'lworld' into jep_401_javac_merge_lworld ------------- Commit messages: - Merge branch 'lworld' into jep_401_javac_merge_lworld - 8325546: [lworld] Missing barrier in C1 compiled code on AArch64 - 8325417: [lworld] Incorrect re-execution state at uncommon traps emitted by acmp - 8324114: [lworld] GTestWrapper.java fails with "assert(LockingMode == LM_LEGACY) failed: should only be called with legacy stack locking" - 8325343: [lworld] java/lang/reflect/Proxy/ClassRestrictions.java fails with NPE - 8325398: [lworld] C1 should not patch null restricted field stores - 8324117: [lworld] C1 hits "Can not patch access to flat field" assert after JDK-8320437 - [lworld] More problem listing - [lworld] Problem listing ctw test triggering 8321734 - [lworld] Problem listing failing javac tests - ... and 2 more: https://git.openjdk.org/valhalla/compare/c518a142...c5856021 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/1003/files Stats: 12999 lines in 146 files changed: 1916 ins; 6081 del; 5002 mod Patch: https://git.openjdk.org/valhalla/pull/1003.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1003/head:pull/1003 PR: https://git.openjdk.org/valhalla/pull/1003 From vromero at openjdk.org Fri Feb 9 18:06:06 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 9 Feb 2024 18:06:06 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 17:47:46 GMT, Vicente Romero wrote: > Merge branch 'lworld' into jep_401_javac_merge_lworld This pull request has now been integrated. Changeset: 70c34aab Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/70c34aab8d8e7776e0b263f1cc46c5c9db6a623c Stats: 12999 lines in 146 files changed: 1916 ins; 6081 del; 5002 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1003 From fparain at openjdk.org Fri Feb 9 20:13:09 2024 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 9 Feb 2024 20:13:09 GMT Subject: [lworld] Integrated: 8325560: [lworld] Aarch64 interpreter is missing a membar on flat array access Message-ID: Add missing membar in the aarch64 interpreter when reading a value from a flat array. ------------- Commit messages: - Adding missing membar on flat array reads Changes: https://git.openjdk.org/valhalla/pull/1004/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1004&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325560 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1004.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1004/head:pull/1004 PR: https://git.openjdk.org/valhalla/pull/1004 From fparain at openjdk.org Fri Feb 9 20:13:10 2024 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 9 Feb 2024 20:13:10 GMT Subject: [lworld] Integrated: 8325560: [lworld] Aarch64 interpreter is missing a membar on flat array access In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 20:06:12 GMT, Frederic Parain wrote: > Add missing membar in the aarch64 interpreter when reading a value from a flat array. This pull request has now been integrated. Changeset: 34366578 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/343665781f056dc75cfcd053fa67ecc80bdaa9ce Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8325560: [lworld] Aarch64 interpreter is missing a membar on flat array access ------------- PR: https://git.openjdk.org/valhalla/pull/1004 From amenkov at openjdk.org Fri Feb 9 21:47:07 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 9 Feb 2024 21:47:07 GMT Subject: [lworld] RFR: JDK-8325344: [lworld] RedefinePrimitive.java fails javac compilation In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 22:43:24 GMT, Mandy Chung wrote: > This change is fine in fixing the compilation error. > > We are migrating tests that use primitive value class to use the internal APIs (you can reference #991). Can you repurpose this issue to update the test? The test should be renamed too like `RedefineNullRestrictedValues.java` something like that. Thank you for the comment. Tried to update the test to use internal API and realized that testing for NullRestricted value classes are completely different. Also this test does not actually works with the current code (even for primitive classes). I think it would be better to drop this test and develop test scenarios for NullRestricted value classes (will create a separate CR for this) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1001#issuecomment-1936645224 From mchung at openjdk.org Sat Feb 10 00:06:12 2024 From: mchung at openjdk.org (Mandy Chung) Date: Sat, 10 Feb 2024 00:06:12 GMT Subject: [lworld] RFR: JDK-8325344: [lworld] RedefinePrimitive.java fails javac compilation In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 21:44:43 GMT, Alex Menkov wrote: > I think it would be better to drop this test and develop test scenarios for NullRestricted value classes (will create a separate CR for this) This is fine. Please create a CR to add a new test `redefineClass` on value classes. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1001#issuecomment-1936755370 From amenkov at openjdk.org Sat Feb 10 01:18:21 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 10 Feb 2024 01:18:21 GMT Subject: [lworld] RFR: JDK-8325344: [lworld] RedefinePrimitive.java fails javac compilation [v2] In-Reply-To: References: Message-ID: > Fixed the test after changes in library Alex Menkov has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'RedefinePrimitive_test' of github.com:alexmenkov/valhalla into RedefinePrimitive_test - updated jdk_valhalla test group - deleted the test ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1001/files - new: https://git.openjdk.org/valhalla/pull/1001/files/5d920df6..1a8ee3b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1001&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1001&range=00-01 Stats: 540 lines in 2 files changed: 0 ins; 539 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1001.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1001/head:pull/1001 PR: https://git.openjdk.org/valhalla/pull/1001 From amenkov at openjdk.org Sat Feb 10 01:30:03 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 10 Feb 2024 01:30:03 GMT Subject: [lworld] RFR: JDK-8325344: [lworld] RedefinePrimitive.java fails javac compilation [v2] In-Reply-To: References: Message-ID: On Sat, 10 Feb 2024 00:03:21 GMT, Mandy Chung wrote: > > I think it would be better to drop this test and develop test scenarios for NullRestricted value classes (will create a separate CR for this) > > This is fine. Please create a CR to add a new test `redefineClass` on value classes. Filed https://bugs.openjdk.org/browse/JDK-8325583 ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1001#issuecomment-1936794953 From amenkov at openjdk.org Sat Feb 10 01:30:03 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Sat, 10 Feb 2024 01:30:03 GMT Subject: [lworld] Integrated: JDK-8325344: [lworld] RedefinePrimitive.java fails javac compilation In-Reply-To: References: Message-ID: <9vZSNehaszgU9gbiz-DOjoSJVejxXrZlB4_2HqC5Sbc=.410b9227-fd4a-49e5-b9fc-ab8288d1e9fb@github.com> On Thu, 8 Feb 2024 22:26:21 GMT, Alex Menkov wrote: > Fixed the test after changes in library This pull request has now been integrated. Changeset: d8c630c1 Author: Alex Menkov URL: https://git.openjdk.org/valhalla/commit/d8c630c1011567c92b43e84475093eca4ffeb607 Stats: 541 lines in 3 files changed: 0 ins; 540 del; 1 mod 8325344: [lworld] RedefinePrimitive.java fails javac compilation ------------- PR: https://git.openjdk.org/valhalla/pull/1001 From vromero at openjdk.org Mon Feb 12 18:50:21 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Feb 2024 18:50:21 GMT Subject: Integrated: 8325578: [lworld] removing references to primitive, vnew in javax.lang.model Message-ID: removing references to primitive and vnew ------------- Commit messages: - 8325578: [lworld] removing references to primitive, vnew in javax.lang.model Changes: https://git.openjdk.org/valhalla/pull/1005/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1005&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325578 Stats: 13 lines in 2 files changed: 0 ins; 9 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1005.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1005/head:pull/1005 PR: https://git.openjdk.org/valhalla/pull/1005 From vromero at openjdk.org Mon Feb 12 18:50:21 2024 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 12 Feb 2024 18:50:21 GMT Subject: Integrated: 8325578: [lworld] removing references to primitive, vnew in javax.lang.model In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 18:45:17 GMT, Vicente Romero wrote: > removing references to primitive and vnew This pull request has now been integrated. Changeset: d79fc4d7 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/d79fc4d79fec1f522043b6d05a78e5044933be2d Stats: 13 lines in 2 files changed: 0 ins; 9 del; 4 mod 8325578: [lworld] removing references to primitive, vnew in javax.lang.model ------------- PR: https://git.openjdk.org/valhalla/pull/1005 From vadavidsw at gmail.com Tue Feb 13 21:01:45 2024 From: vadavidsw at gmail.com (David Witten) Date: Tue, 13 Feb 2024 16:01:45 -0500 Subject: Performance of array of non-nullable value objects Message-ID: First I'd like to thank everyone working on valhalla, it is very exciting! I was playing around with different hash Map implementations using Build 20-valhalla+20-75 . I was surprised that get() performance when bins were arrays of primitive classes containing (int hash, K key, V value) performed worse than the normal non-primitive linked-list bins of (int hash, K key, V value, Node next) even when bins were rather large. Is this expected to be the case for this old early release? Is this expected to be the case when non-nullable, not-atomicly-updated value objects are officially released? Is there any guess about when another early release will be available? The initial size and load factor of the Maps guaranteed that the bins were largish. The random seed was the same for array-bin vs list-bin so that the bins sizes are always same for both. Here is a typical histogram for bin sizes (again same for list vs array bins): histogram: max: 16, [589, *2436*, 4805, 6396, 6342, 5173, 3413, 1889, 1017, 437, 187, 55, 21, 6, 1, 0, 1] So, for example, there were *2436* bins of size 1. Here are some results (I started with the jmh tests in https://hg.openjdk.org/valhalla/valhalla/rev/71ba79398dd9 ) but the Map implementations and random seed approach are different. *Benchmark (mapType) (size) Mode Cnt Score Error Units* GetX.getHit mapprotos.ArrayBinHashMapJustPutGet 131072 avgt 10 4784.596 ? 649.247 us/op GetX.getHit mapprotos.HashMapJustPutGet 131072 avgt 10 3053.680 ? 427.430 us/op GetX.getMix mapprotos.ArrayBinHashMapJustPutGet 131072 avgt 10 4991.512 ? 292.345 us/op GetX.getMix mapprotos.HashMapJustPutGet 131072 avgt 10 4291.636 ? 543.059 us/op If this sort of behavior is not expected, and someone would like to look into it, I can clean up and supply my test. -thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.kuksenko at oracle.com Tue Feb 13 22:01:58 2024 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Tue, 13 Feb 2024 22:01:58 +0000 Subject: Performance of array of non-nullable value objects In-Reply-To: References: Message-ID: HashMaps on Valhalla were analyzed some time ago: https://cr.openjdk.org/~skuksenko/valhalla/hashmaps/hash.html ________________________________________ From: valhalla-dev on behalf of David Witten Sent: Tuesday, February 13, 2024 1:01 PM To: valhalla-dev at openjdk.org Subject: Performance of array of non-nullable value objects First I'd like to thank everyone working on valhalla, it is very exciting! I was playing around with different hash Map implementations using Build 20-valhalla+20-75. I was surprised that get() performance when bins were arrays of primitive classes containing (int hash, K key, V value) performed worse than the normal non-primitive linked-list bins of (int hash, K key, V value, Node next) even when bins were rather large. Is this expected to be the case for this old early release? Is this expected to be the case when non-nullable, not-atomicly-updated value objects are officially released? Is there any guess about when another early release will be available? The initial size and load factor of the Maps guaranteed that the bins were largish. The random seed was the same for array-bin vs list-bin so that the bins sizes are always same for both. Here is a typical histogram for bin sizes (again same for list vs array bins): histogram: max: 16, [589, 2436, 4805, 6396, 6342, 5173, 3413, 1889, 1017, 437, 187, 55, 21, 6, 1, 0, 1] So, for example, there were 2436 bins of size 1. Here are some results (I started with the jmh tests in https://hg.openjdk.org/valhalla/valhalla/rev/71ba79398dd9 ) but the Map implementations and random seed approach are different. Benchmark (mapType) (size) Mode Cnt Score Error Units GetX.getHit mapprotos.ArrayBinHashMapJustPutGet 131072 avgt 10 4784.596 ? 649.247 us/op GetX.getHit mapprotos.HashMapJustPutGet 131072 avgt 10 3053.680 ? 427.430 us/op GetX.getMix mapprotos.ArrayBinHashMapJustPutGet 131072 avgt 10 4991.512 ? 292.345 us/op GetX.getMix mapprotos.HashMapJustPutGet 131072 avgt 10 4291.636 ? 543.059 us/op If this sort of behavior is not expected, and someone would like to look into it, I can clean up and supply my test. -thanks, David From dsimms at openjdk.org Thu Feb 15 10:31:05 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 15 Feb 2024 10:31:05 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge tag 'jdk-22+24' into lworld_merge_jdk_22_24 ------------- Commit messages: - Merge branch 'lworld' into lworld_merge_jdk_22_24 - Merge tag 'jdk-22+24' into lworld_merge_jdk_22_24 - 8301997: Move method resolution information out of the cpCache - Less than trivial conflict in headDumper.cpp and 8319650 - Merge commit '891d8cfaf2fc0636bfe8f864cd010fb71266d723' into lworld_merge_jdk_22_24 - 8319986: Invalid/inconsistent description and example for DateFormat - 8320130: Problemlist 2 vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt tests with Xcomp - 8319187: Add three eMudhra emSign roots - 8318219: RISC-V: C2 ExpandBits - 8320053: GHA: Cross-compile gtest code - ... and 85 more: https://git.openjdk.org/valhalla/compare/d8c630c1...b2fb8160 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1006&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1006&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1006/files Stats: 612899 lines in 960 files changed: 82839 ins; 469010 del; 61050 mod Patch: https://git.openjdk.org/valhalla/pull/1006.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1006/head:pull/1006 PR: https://git.openjdk.org/valhalla/pull/1006 From dsimms at openjdk.org Thu Feb 15 10:31:05 2024 From: dsimms at openjdk.org (David Simms) Date: Thu, 15 Feb 2024 10:31:05 GMT Subject: [lworld] RFR: Merge jdk In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 10:19:38 GMT, David Simms wrote: > Merge tag 'jdk-22+24' into lworld_merge_jdk_22_24 Note: commit 6d9b8c56f168ab7c16d616483ba862c7213533f4 reinstates the experimental class file API until [JDK-8308778](https://bugs.openjdk.org/browse/JDK-8308778) is resolved ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1006#issuecomment-1945784120 From vromero at openjdk.org Thu Feb 15 17:36:19 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 Feb 2024 17:36:19 GMT Subject: RFR: 8325952: [lworld] tests refactoring, clean-up Message-ID: test refactoring, removing a bunch of primitive classes tests. Minor bug fix related to interaction of `value` with other modifiers ------------- Commit messages: - removing white space - 8325952: [lworld] tests refactoring, clean-up Changes: https://git.openjdk.org/valhalla/pull/1007/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1007&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325952 Stats: 6629 lines in 120 files changed: 144 ins; 6471 del; 14 mod Patch: https://git.openjdk.org/valhalla/pull/1007.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1007/head:pull/1007 PR: https://git.openjdk.org/valhalla/pull/1007 From vromero at openjdk.org Thu Feb 15 18:31:44 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 Feb 2024 18:31:44 GMT Subject: RFR: 8325952: [lworld] tests refactoring, clean-up [v2] In-Reply-To: References: Message-ID: <7eFPeYXMyChimOd-nJfuO3wfUuTivvM6ZgzHNyV2U3I=.346f0bd7-54ed-440b-87f3-18c6c871e4cc@github.com> > test refactoring, removing a bunch of primitive classes tests. Minor bug fix related to interaction of `value` with other modifiers Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: moving test ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1007/files - new: https://git.openjdk.org/valhalla/pull/1007/files/37045133..df2d4f20 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1007&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1007&range=00-01 Stats: 88 lines in 3 files changed: 44 ins; 44 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1007.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1007/head:pull/1007 PR: https://git.openjdk.org/valhalla/pull/1007 From vromero at openjdk.org Thu Feb 15 18:31:45 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 15 Feb 2024 18:31:45 GMT Subject: Integrated: 8325952: [lworld] tests refactoring, clean-up In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 17:27:55 GMT, Vicente Romero wrote: > test refactoring, removing a bunch of primitive classes tests. Minor bug fix related to interaction of `value` with other modifiers This pull request has now been integrated. Changeset: 916c8e39 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/916c8e390550f4949b51c75e914c43b7bcf1c814 Stats: 6717 lines in 123 files changed: 188 ins; 6515 del; 14 mod 8325952: [lworld] tests refactoring, clean-up ------------- PR: https://git.openjdk.org/valhalla/pull/1007 From vromero at openjdk.org Fri Feb 16 02:31:25 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Feb 2024 02:31:25 GMT Subject: RFR: 8317415: [lworld] Preload_attribute needs moving to jdk.internal.classfile.attribute Message-ID: mostly a merge issue ------------- Commit messages: - 8317415: [lworld] Preload_attribute needs moving to jdk.internal.classfile.attribute Changes: https://git.openjdk.org/valhalla/pull/1008/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317415 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1008.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1008/head:pull/1008 PR: https://git.openjdk.org/valhalla/pull/1008 From vromero at openjdk.org Fri Feb 16 02:43:02 2024 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 Feb 2024 02:43:02 GMT Subject: Integrated: 8317415: [lworld] Preload_attribute needs moving to jdk.internal.classfile.attribute In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 02:26:53 GMT, Vicente Romero wrote: > mostly a merge issue This pull request has now been integrated. Changeset: a2ec46c1 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/a2ec46c1ea4ed4716588c50724bee4ad1b42d7c6 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod 8317415: [lworld] Preload_attribute needs moving to jdk.internal.classfile.attribute ------------- PR: https://git.openjdk.org/valhalla/pull/1008 From dsimms at openjdk.org Fri Feb 16 08:58:10 2024 From: dsimms at openjdk.org (David Simms) Date: Fri, 16 Feb 2024 08:58:10 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 10:19:38 GMT, David Simms wrote: > Merge tag 'jdk-22+24' into lworld_merge_jdk_22_24 This pull request has now been integrated. Changeset: 20915591 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/209155913ec1ae1d42a5294a1046ecc0ffea601c Stats: 612899 lines in 960 files changed: 82839 ins; 469010 del; 61050 mod Merge jdk Merge jdk-22+24 ------------- PR: https://git.openjdk.org/valhalla/pull/1006 From thartmann at openjdk.org Fri Feb 16 14:07:17 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Feb 2024 14:07:17 GMT Subject: [lworld] RFR: 8326048: [lworld] LibraryCallKit::arraycopy_restore_alloc_state needs to handle _newNullRestrictedArray intrinsic Message-ID: Follow-up from [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106): We hit an assert because we create a wrong JVMState in `LibraryCallKit::arraycopy_restore_alloc_state` for re-executing the `newNullRestrictedArray` intrinsic because the code does not account for the class argument on stack in addition to the size. I also fixed an independent issue with handling circularity. Best regards, Tobias ------------- Commit messages: - 8326048: [lworld] LibraryCallKit::arraycopy_restore_alloc_state needs to handle _newNullRestrictedArray intrinsic Changes: https://git.openjdk.org/valhalla/pull/1009/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1009&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326048 Stats: 84 lines in 11 files changed: 49 ins; 17 del; 18 mod Patch: https://git.openjdk.org/valhalla/pull/1009.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1009/head:pull/1009 PR: https://git.openjdk.org/valhalla/pull/1009 From thartmann at openjdk.org Fri Feb 16 14:35:04 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Feb 2024 14:35:04 GMT Subject: [lworld] Integrated: 8326048: [lworld] LibraryCallKit::arraycopy_restore_alloc_state needs to handle _newNullRestrictedArray intrinsic In-Reply-To: References: Message-ID: On Fri, 16 Feb 2024 14:01:31 GMT, Tobias Hartmann wrote: > Follow-up from [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106): We hit an assert because we create a wrong JVMState in `LibraryCallKit::arraycopy_restore_alloc_state` for re-executing the `newNullRestrictedArray` intrinsic because the code does not account for the class argument on stack in addition to the size. > > I also fixed an independent issue with handling circularity. > > Best regards, > Tobias This pull request has now been integrated. Changeset: d52f3fd1 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/d52f3fd1e966339e82e5e4a924ceb005f77fafdd Stats: 84 lines in 11 files changed: 49 ins; 17 del; 18 mod 8326048: [lworld] LibraryCallKit::arraycopy_restore_alloc_state needs to handle _newNullRestrictedArray intrinsic ------------- PR: https://git.openjdk.org/valhalla/pull/1009 From vromero at openjdk.org Tue Feb 20 17:12:19 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Feb 2024 17:12:19 GMT Subject: Integrated: 8323790: [lworld] TestSuperclass.java failed after merging jdk-22+16, due to flag bugs Message-ID: <37pabc21kVdgLhq-qaGbs_40tCPXQ4qgfoejhHCkGTM=.d296ec40-5d45-4ad5-9dc6-7ea876f33a6a@github.com> the merge uncovered bugs related to the handling of the IDENTITY flag ------------- Commit messages: - 8323790: [lworld] TestSuperclass.java failed after merging jdk-22+16, due to flag bugs Changes: https://git.openjdk.org/valhalla/pull/1010/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1010&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323790 Stats: 11 lines in 7 files changed: 4 ins; 2 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1010.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1010/head:pull/1010 PR: https://git.openjdk.org/valhalla/pull/1010 From vromero at openjdk.org Tue Feb 20 17:12:20 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Feb 2024 17:12:20 GMT Subject: Integrated: 8323790: [lworld] TestSuperclass.java failed after merging jdk-22+16, due to flag bugs In-Reply-To: <37pabc21kVdgLhq-qaGbs_40tCPXQ4qgfoejhHCkGTM=.d296ec40-5d45-4ad5-9dc6-7ea876f33a6a@github.com> References: <37pabc21kVdgLhq-qaGbs_40tCPXQ4qgfoejhHCkGTM=.d296ec40-5d45-4ad5-9dc6-7ea876f33a6a@github.com> Message-ID: On Tue, 20 Feb 2024 17:00:17 GMT, Vicente Romero wrote: > the merge uncovered bugs related to the handling of the IDENTITY flag This pull request has now been integrated. Changeset: 33721c4d Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/33721c4d4b8ff28dfa112e966e18a1f54d08d981 Stats: 11 lines in 7 files changed: 4 ins; 2 del; 5 mod 8323790: [lworld] TestSuperclass.java failed after merging jdk-22+16, due to flag bugs ------------- PR: https://git.openjdk.org/valhalla/pull/1010 From dsimms at openjdk.org Tue Feb 20 19:10:48 2024 From: dsimms at openjdk.org (David Simms) Date: Tue, 20 Feb 2024 19:10:48 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge tag 'jdk-22+25' into lworld_merge_jdk_22_25 Added tag jdk-22+25 for changeset e47cf611 ------------- Commit messages: - Merge jdk - 8074211: javax.sound.midi: Error with send System Exclusive messages of different length - 8320278: ARM32 build is broken after JDK-8301997 - 8318364: Add an FFM-based implementation of harfbuzz OpenType layout - 8319124: Update XML Security for Java to 3.0.3 - 8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format - 8320272: Make method_entry_barrier address shared - 8320526: Use title case in building.md - 8315969: compiler/rangechecks/TestRangeCheckHoistingScaledIV.java: make flagless - 8187591: -Werror turns incubator module warning to an error - ... and 67 more: https://git.openjdk.org/valhalla/compare/d52f3fd1...e4094ed7 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1011&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1011&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1011/files Stats: 15974 lines in 484 files changed: 8958 ins; 3485 del; 3531 mod Patch: https://git.openjdk.org/valhalla/pull/1011.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1011/head:pull/1011 PR: https://git.openjdk.org/valhalla/pull/1011 From vromero at openjdk.org Tue Feb 20 20:17:26 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Feb 2024 20:17:26 GMT Subject: RFR: Merge lworld Message-ID: <3dQYJxQR_yLS9DlQSFzYaoWoQ6CtefqtaQ5Z03uKH2I=.7fc978b5-f818-4451-ad3e-c817a1a692ad@github.com> Merge branch 'lworld' into jep_401_javac_merge_lworld ------------- Commit messages: - Merge branch 'lworld' into jep_401_javac_merge_lworld - 8326048: [lworld] LibraryCallKit::arraycopy_restore_alloc_state needs to handle _newNullRestrictedArray intrinsic - Merge jdk - 8301997: Move method resolution information out of the cpCache - 8319986: Invalid/inconsistent description and example for DateFormat - 8320130: Problemlist 2 vmTestbase/nsk/jdi/StepRequest/addClassFilter_rt tests with Xcomp - 8319187: Add three eMudhra emSign roots - 8318219: RISC-V: C2 ExpandBits - 8320053: GHA: Cross-compile gtest code - 8319966: AIX: expected [[0:i4]] but found [[0:I4]] after JDK-8319882 - ... and 84 more: https://git.openjdk.org/valhalla/compare/33721c4d...b1e61251 The webrevs contain the adjustments done while merging with regards to each parent branch: - jep_401_javac: https://webrevs.openjdk.org/?repo=valhalla&pr=1012&range=00.0 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1012&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1012/files Stats: 613527 lines in 972 files changed: 82891 ins; 469567 del; 61069 mod Patch: https://git.openjdk.org/valhalla/pull/1012.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1012/head:pull/1012 PR: https://git.openjdk.org/valhalla/pull/1012 From vromero at openjdk.org Tue Feb 20 20:56:06 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 Feb 2024 20:56:06 GMT Subject: Integrated: Merge lworld In-Reply-To: <3dQYJxQR_yLS9DlQSFzYaoWoQ6CtefqtaQ5Z03uKH2I=.7fc978b5-f818-4451-ad3e-c817a1a692ad@github.com> References: <3dQYJxQR_yLS9DlQSFzYaoWoQ6CtefqtaQ5Z03uKH2I=.7fc978b5-f818-4451-ad3e-c817a1a692ad@github.com> Message-ID: <_QHoPOxOYkj40YmJU5i1TYfDJpPes7_8iKdgCH7o9MU=.0a39d853-5c3f-46e3-9a0e-12c6e5c43d4e@github.com> On Tue, 20 Feb 2024 20:11:09 GMT, Vicente Romero wrote: > Merge branch 'lworld' into jep_401_javac_merge_lworld This pull request has now been integrated. Changeset: b60813c6 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/b60813c6766e37bd13127cf4399e86d8da9055c7 Stats: 613527 lines in 972 files changed: 82891 ins; 469567 del; 61069 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1012 From dsimms at openjdk.org Wed Feb 21 11:43:09 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 21 Feb 2024 11:43:09 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Tue, 20 Feb 2024 19:02:08 GMT, David Simms wrote: > Merge tag 'jdk-22+25' into lworld_merge_jdk_22_25 > > Added tag jdk-22+25 for changeset e47cf611 This pull request has now been integrated. Changeset: bfd68916 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/bfd689160c67449ea601dd7bfa9c5b1114b25558 Stats: 15974 lines in 484 files changed: 8958 ins; 3485 del; 3531 mod Merge jdk Merge jdk-22+25 ------------- PR: https://git.openjdk.org/valhalla/pull/1011 From thartmann at openjdk.org Wed Feb 21 15:02:16 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 Feb 2024 15:02:16 GMT Subject: [lworld] Integrated: [lworld] Disable IR rule for TestLWorld::test113_sharp Message-ID: <05MZDV4Q634XWn8x1lGVoMdZhZfaI8GS9n0BPtr3fH8=.4f993347-f3fd-4210-9fdb-343b96699c36@github.com> Disable the IR rule due to [JDK-8326401](https://bugs.openjdk.org/browse/JDK-8326401). Best regards, Tobias ------------- Commit messages: - [lworld] Disable IR rule for TestLWorld::test113_sharp Changes: https://git.openjdk.org/valhalla/pull/1013/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1013&range=00 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1013.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1013/head:pull/1013 PR: https://git.openjdk.org/valhalla/pull/1013 From thartmann at openjdk.org Wed Feb 21 15:02:16 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 21 Feb 2024 15:02:16 GMT Subject: [lworld] Integrated: [lworld] Disable IR rule for TestLWorld::test113_sharp In-Reply-To: <05MZDV4Q634XWn8x1lGVoMdZhZfaI8GS9n0BPtr3fH8=.4f993347-f3fd-4210-9fdb-343b96699c36@github.com> References: <05MZDV4Q634XWn8x1lGVoMdZhZfaI8GS9n0BPtr3fH8=.4f993347-f3fd-4210-9fdb-343b96699c36@github.com> Message-ID: <-_epVFapqSVfPAaXHe1jaUJk5uxAKUlh0LwdVRVoSlo=.02d8f33c-88bc-4a3f-996e-0cc6d24869da@github.com> On Wed, 21 Feb 2024 14:57:50 GMT, Tobias Hartmann wrote: > Disable the IR rule due to [JDK-8326401](https://bugs.openjdk.org/browse/JDK-8326401). > > Best regards, > Tobias This pull request has now been integrated. Changeset: 1d120f32 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/1d120f32389332fdcfcd3213300a73447ad26e4d Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod [lworld] Disable IR rule for TestLWorld::test113_sharp ------------- PR: https://git.openjdk.org/valhalla/pull/1013 From vromero at openjdk.org Wed Feb 21 18:30:11 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Feb 2024 18:30:11 GMT Subject: Integrated: Merge lworld Message-ID: Merge branch 'lworld' into jep_401_javac_merge_lworld # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ------------- Commit messages: - Merge branch 'lworld' into jep_401_javac_merge_lworld - Merge lworld - 8323790: [lworld] TestSuperclass.java failed after merging jdk-22+16, due to flag bugs - 8317415: [lworld] Preload_attribute needs moving to jdk.internal.classfile.attribute - 8325952: [lworld] tests refactoring, clean-up - 8325578: [lworld] removing references to primitive, vnew in javax.lang.model - Merge lworld - 8324873: [lworld] implementation of value classes construction - Merge lworld - Merge lworld - ... and 7 more: https://git.openjdk.org/valhalla/compare/1d120f32...571e3681 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/1014/files Stats: 14752 lines in 300 files changed: 2779 ins; 11181 del; 792 mod Patch: https://git.openjdk.org/valhalla/pull/1014.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1014/head:pull/1014 PR: https://git.openjdk.org/valhalla/pull/1014 From vromero at openjdk.org Wed Feb 21 18:30:11 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Feb 2024 18:30:11 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 18:23:04 GMT, Vicente Romero wrote: > Merge branch 'lworld' into jep_401_javac_merge_lworld > # Conflicts: > # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java This pull request has now been integrated. Changeset: db737f30 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/db737f30bd02a2a71c53bf6ba7506dac3b68db1b Stats: 15976 lines in 485 files changed: 8959 ins; 3484 del; 3533 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1014 From vromero at openjdk.org Wed Feb 21 20:34:06 2024 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 Feb 2024 20:34:06 GMT Subject: [lworld] RFR: 8326429: [lworld] Java language implementation of value classes and objects, phase 1 Message-ID: This PR is a first phase of the implementation of [1] and thus of [2]. The code in this PR should unblock other teams waiting on javac support for JEP 401. TIA [1] https://bugs.openjdk.org/browse/JDK-8317277 [2] https://cr.openjdk.org/~dlsmith/jep401/jep401-20240131/specs/value-objects-jls.html ------------- Commit messages: - 8326429: [lworld] Java language implementation of value classes and objects, phase 1 Changes: https://git.openjdk.org/valhalla/pull/1015/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1015&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326429 Stats: 14752 lines in 300 files changed: 2779 ins; 11181 del; 792 mod Patch: https://git.openjdk.org/valhalla/pull/1015.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1015/head:pull/1015 PR: https://git.openjdk.org/valhalla/pull/1015 From vromero at openjdk.org Thu Feb 22 04:01:11 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 22 Feb 2024 04:01:11 GMT Subject: Integrated: Merge lworld Message-ID: <9K1oyk_EI2biBYJYvXWTSnEabVk6HY_PmJIDBRYFSrA=.27ca4e2b-2352-4c62-9650-c1c0848e9e96@github.com> Merge branch 'lworld' into lw5_merge_lworld # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ------------- Commit messages: - Merge branch 'lworld' into lw5_merge_lworld - Merge lworld - Merge lworld - Merge lworld - Merge lworld - Merge lworld - Merge lworld - Merge lworld - 8318117: [lw5] create a switch for null-restricted types - 8316628: [lw5] remove vnew, aconst_init, and withfield - ... and 31 more: https://git.openjdk.org/valhalla/compare/1d120f32...e5d80220 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/1016/files Stats: 8225 lines in 292 files changed: 4456 ins; 2611 del; 1158 mod Patch: https://git.openjdk.org/valhalla/pull/1016.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1016/head:pull/1016 PR: https://git.openjdk.org/valhalla/pull/1016 From vromero at openjdk.org Thu Feb 22 04:01:14 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 22 Feb 2024 04:01:14 GMT Subject: Integrated: Merge lworld In-Reply-To: <9K1oyk_EI2biBYJYvXWTSnEabVk6HY_PmJIDBRYFSrA=.27ca4e2b-2352-4c62-9650-c1c0848e9e96@github.com> References: <9K1oyk_EI2biBYJYvXWTSnEabVk6HY_PmJIDBRYFSrA=.27ca4e2b-2352-4c62-9650-c1c0848e9e96@github.com> Message-ID: <6jaLa1ZkDmnLSDTcJMxb5dE1fkmd5uo1hU7dNe3y59c=.adda5fc5-2123-46c7-b758-7a51331dbf4f@github.com> On Thu, 22 Feb 2024 03:54:29 GMT, Vicente Romero wrote: > Merge branch 'lworld' into lw5_merge_lworld > # Conflicts: > # src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java This pull request has now been integrated. Changeset: f47a9e26 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/f47a9e263ecc887114b6641c2b5490e45835ed4d Stats: 642423 lines in 1533 files changed: 93735 ins; 479100 del; 69588 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/1016 From vromero at openjdk.org Thu Feb 22 16:17:12 2024 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 22 Feb 2024 16:17:12 GMT Subject: [lworld] Integrated: 8326429: [lworld] Java language implementation of value classes and objects, phase 1 In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 20:29:41 GMT, Vicente Romero wrote: > This PR is a first phase of the implementation of [1] and thus of [2]. The code in this PR should unblock other teams waiting on javac support for JEP 401. After pushed the `lworld` repo could be unusable for a short time until the corresponding VM support is pushed too. > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8317277 > [2] https://cr.openjdk.org/~dlsmith/jep401/jep401-20240131/specs/value-objects-jls.html This pull request has now been integrated. Changeset: 1b99b5cf Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf Stats: 14752 lines in 300 files changed: 2779 ins; 11181 del; 792 mod 8326429: [lworld] Java language implementation of value classes and objects, phase 1 ------------- PR: https://git.openjdk.org/valhalla/pull/1015 From fparain at openjdk.org Fri Feb 23 19:06:15 2024 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 23 Feb 2024 19:06:15 GMT Subject: [lworld] RFR: 8326595: [lworld] Bootstrap VM transition to JEP 401 model Message-ID: Bootstrapping transition to JEP 401 model. A lot of things are broken, but at least the build works on most platforms, the VM can boot and execute some JEP 401 class files in interpreted mode. The ability to run code with value classes is still limited because the VM depends on some JDK core classes that need to be updated too (reflection and substitutability test). Transition changes include: - Accepting new class file format (not rejecting correct JEP 401 class files), changes class hierarchy rules, class flags meaning, changes verifier rules - Update new and putfield bytecodes in interpreter to support new construction sequence - Runtime tests fixes Cleanup changes include: - Removal of support of Q-descriptors (and Q-desc bit in constant pool) - Removal of support of old class flags (ACC_VALUE) - Removal of aconst_init and withfield bytecodes from the interpreter and C1 - Removal of support for secondary mirror - Removal of support for primitive classes - Removal of support for value factories () - Partial removal of T_PRIMITIVE_OBJECT ------------- Commit messages: - Bootstrap transition to JEP 401 model Changes: https://git.openjdk.org/valhalla/pull/1017/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1017&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326595 Stats: 2101 lines in 161 files changed: 95 ins; 1647 del; 359 mod Patch: https://git.openjdk.org/valhalla/pull/1017.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1017/head:pull/1017 PR: https://git.openjdk.org/valhalla/pull/1017 From mchung at openjdk.org Fri Feb 23 19:47:18 2024 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 23 Feb 2024 19:47:18 GMT Subject: [lworld] RFR: 8326602: [lworld] substitutabillity test does not support cyclic membership properly Message-ID: `test/jdk/valhalla/valuetypes/RecursiveValueClass.java` test fails when the primitive value class is migrated to null-restricted value types. It uncovers a bug in supporting mutual recursive types. The recursive method handle should be created with the base functions of mutual recursive types so that it can call the recursive method handle for another type properly. ------------- Commit messages: - minor cleanup - 8326602: [lworld] substitutabillity test does not support cyclic membership properly Changes: https://git.openjdk.org/valhalla/pull/1018/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1018&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326602 Stats: 1180 lines in 3 files changed: 766 ins; 348 del; 66 mod Patch: https://git.openjdk.org/valhalla/pull/1018.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1018/head:pull/1018 PR: https://git.openjdk.org/valhalla/pull/1018 From mchung at openjdk.org Fri Feb 23 22:21:47 2024 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 23 Feb 2024 22:21:47 GMT Subject: [lworld] RFR: 8326602: [lworld] substitutabillity test does not support cyclic membership properly [v2] In-Reply-To: References: Message-ID: > `test/jdk/valhalla/valuetypes/RecursiveValueClass.java` test fails when the primitive value class is migrated to null-restricted value types. It uncovers a bug in supporting mutual recursive types. The recursive method handle should be created with the base functions of mutual recursive types so that it can call the recursive method handle for another type properly. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: ignore one test ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1018/files - new: https://git.openjdk.org/valhalla/pull/1018/files/b6be1a7b..13f03260 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1018&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1018&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1018.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1018/head:pull/1018 PR: https://git.openjdk.org/valhalla/pull/1018 From thartmann at openjdk.org Mon Feb 26 11:48:07 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 Feb 2024 11:48:07 GMT Subject: [lworld] RFR: 8326595: [lworld] Bootstrap VM transition to JEP 401 model In-Reply-To: References: Message-ID: <4Hc6KxiDQg1fQG7grpqgjHOcyjZpQ-tTlU5R1b0dH-4=.6b7d62e6-efde-41d0-a79a-c09613a86f30@github.com> On Thu, 22 Feb 2024 20:24:15 GMT, Frederic Parain wrote: > Bootstrapping transition to JEP 401 model. > A lot of things are broken, but at least the build works on most platforms, the VM can boot and execute some JEP 401 class files in interpreted mode. The ability to run code with value classes is still limited because the VM depends on some JDK core classes that need to be updated too (reflection and substitutability test). > > Transition changes include: > - Accepting new class file format (not rejecting correct JEP 401 class files), changes class hierarchy rules, class flags meaning, changes verifier rules > - Update new and putfield bytecodes in interpreter to support new construction sequence > - Runtime tests fixes > > Cleanup changes include: > - Removal of support of Q-descriptors (and Q-desc bit in constant pool) > - Removal of support of old class flags (ACC_VALUE) > - Removal of aconst_init and withfield bytecodes from the interpreter and C1 > - Removal of support for secondary mirror > - Removal of support for primitive classes > - Removal of support for value factories () > - Partial removal of T_PRIMITIVE_OBJECT src/hotspot/share/opto/graphKit.cpp line 3664: > 3662: Node* GraphKit::is_val_mirror(Node* mirror) { > 3663: // JDK-8325660: notion of secondary mirror / val_mirror is gone one JEP 401 > 3664: Node* p = basic_plus_adr(mirror, (int)0 /* java_lang_Class::secondary_mirror_offset() */); This will break Escape Analysis because such an access with zero offset is unexpected: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/oracle/valhalla/open/src/hotspot/share/opto/escape.cpp:896), pid=600228, tid=600242 # assert(_igvn->type(adr)->isa_rawptr()) failed: sanity # # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2024-02-06-1232159.tobias...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2024-02-06-1232159.tobias..., compiled mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xbe2ec4] ConnectionGraph::add_objload_to_connection_graph(Node*, Unique_Node_List*)+0x284 Please add this to disable the check properly: diff --git a/src/hotspot/share/opto/library_call.cpp b/src/hotspot/share/opto/library_call.cpp index 92425fecf11..bd3ed61744b 100644 --- a/src/hotspot/share/opto/library_call.cpp +++ b/src/hotspot/share/opto/library_call.cpp @@ -4310,7 +4310,8 @@ bool LibraryCallKit::inline_native_subtype_check() { region->set_req(_both_ref_path, gen_subtype_check(subk, superk)); // If superc is an inline mirror, we also need to check if superc == subc because LMyValue // is not a subtype of QMyValue but due to subk == superk the subtype check will pass. - generate_fair_guard(is_val_mirror(args[0]), prim_region); + // TODO JDK-8325660 + // generate_fair_guard(is_val_mirror(args[0]), prim_region); // now we have a successful reference subtype check region->set_req(_ref_subtype_path, control()); } ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1017#discussion_r1502485604 From thartmann at openjdk.org Mon Feb 26 12:10:05 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 Feb 2024 12:10:05 GMT Subject: [lworld] RFR: 8326595: [lworld] Bootstrap VM transition to JEP 401 model In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 20:24:15 GMT, Frederic Parain wrote: > Bootstrapping transition to JEP 401 model. > A lot of things are broken, but at least the build works on most platforms, the VM can boot and execute some JEP 401 class files in interpreted mode. The ability to run code with value classes is still limited because the VM depends on some JDK core classes that need to be updated too (reflection and substitutability test). > > Transition changes include: > - Accepting new class file format (not rejecting correct JEP 401 class files), changes class hierarchy rules, class flags meaning, changes verifier rules > - Update new and putfield bytecodes in interpreter to support new construction sequence > - Runtime tests fixes > > Cleanup changes include: > - Removal of support of Q-descriptors (and Q-desc bit in constant pool) > - Removal of support of old class flags (ACC_VALUE) > - Removal of aconst_init and withfield bytecodes from the interpreter and C1 > - Removal of support for secondary mirror > - Removal of support for primitive classes > - Removal of support for value factories () > - Partial removal of T_PRIMITIVE_OBJECT The ci, C1 and C2 changes look good to me. Thanks a lot for the first cleanup here, Frederic! src/hotspot/share/opto/library_call.cpp line 4118: > 4116: } > 4117: > 4118: // // JDK-8325660: Code has been modified because secondary mirror are gone in JEP 401 Suggestion: // JDK-8325660: Code has been modified because secondary mirror are gone in JEP 401 src/hotspot/share/opto/parse2.cpp line 3510: > 3508: break; > 3509: case Bytecodes::_withfield: > 3510: do_withfield(); Could you add a `// TODO JDK-8325660` to both methods so we don't forget removing them (or simply remove them right away)? ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1017#pullrequestreview-1900714224 PR Review Comment: https://git.openjdk.org/valhalla/pull/1017#discussion_r1502506617 PR Review Comment: https://git.openjdk.org/valhalla/pull/1017#discussion_r1502509510 From frederic.parain at oracle.com Mon Feb 26 15:14:50 2024 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 26 Feb 2024 10:14:50 -0500 Subject: Current and near future state of the Valhalla git repository Message-ID: You might have noticed that the HEAD of the lworld branch in the Valhalla git repository on GitHub is currently broken. We are in the process of transitioning from the previous value classes model to the new model described in JEP 401 (https://openjdk.org/jeps/401). This transition requires significant changes in both the JVM and some core-libraries classes: removal of bytecodes, new class file format, etc. Unfortunately, all those changes are too big to be done in a single changeset. So, changes will be integrated incrementally, and in the mean time, things might? be broken. We have considered doing the changes in a separate branch, but trying to maintain two branches in relative sync with JDK mainline would have doubled the merge workload. And anyway, the old value class model in the lworld branch will not be maintained anymore, so it doesn't make sense to continue keeping it working. If you still need a buildable and functioning version of the Valhalla prototype, even if it implements the old value class model, the last good state of the lworld branch is commit 1d120f32389332fdcfcd3213300a73447ad26e4d If you are working on your own branch created from the lworld branch, we recommend to wait until the end of the transition before pulling changes from lworld to your branch. Fred From fparain at openjdk.org Mon Feb 26 15:42:48 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 26 Feb 2024 15:42:48 GMT Subject: [lworld] RFR: 8326595: [lworld] Bootstrap VM transition to JEP 401 model [v2] In-Reply-To: References: Message-ID: > Bootstrapping transition to JEP 401 model. > A lot of things are broken, but at least the build works on most platforms, the VM can boot and execute some JEP 401 class files in interpreted mode. The ability to run code with value classes is still limited because the VM depends on some JDK core classes that need to be updated too (reflection and substitutability test). > > Transition changes include: > - Accepting new class file format (not rejecting correct JEP 401 class files), changes class hierarchy rules, class flags meaning, changes verifier rules > - Update new and putfield bytecodes in interpreter to support new construction sequence > - Runtime tests fixes > > Cleanup changes include: > - Removal of support of Q-descriptors (and Q-desc bit in constant pool) > - Removal of support of old class flags (ACC_VALUE) > - Removal of aconst_init and withfield bytecodes from the interpreter and C1 > - Removal of support for secondary mirror > - Removal of support for primitive classes > - Removal of support for value factories () > - Partial removal of T_PRIMITIVE_OBJECT Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: More C2 fixes and cleanup ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1017/files - new: https://git.openjdk.org/valhalla/pull/1017/files/8fcf0ed1..4593b456 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1017&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1017&range=00-01 Stats: 105 lines in 5 files changed: 1 ins; 102 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1017.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1017/head:pull/1017 PR: https://git.openjdk.org/valhalla/pull/1017 From fparain at openjdk.org Mon Feb 26 15:42:50 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 26 Feb 2024 15:42:50 GMT Subject: [lworld] RFR: 8326595: [lworld] Bootstrap VM transition to JEP 401 model [v2] In-Reply-To: <4Hc6KxiDQg1fQG7grpqgjHOcyjZpQ-tTlU5R1b0dH-4=.6b7d62e6-efde-41d0-a79a-c09613a86f30@github.com> References: <4Hc6KxiDQg1fQG7grpqgjHOcyjZpQ-tTlU5R1b0dH-4=.6b7d62e6-efde-41d0-a79a-c09613a86f30@github.com> Message-ID: On Mon, 26 Feb 2024 11:45:18 GMT, Tobias Hartmann wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> More C2 fixes and cleanup > > src/hotspot/share/opto/graphKit.cpp line 3664: > >> 3662: Node* GraphKit::is_val_mirror(Node* mirror) { >> 3663: // JDK-8325660: notion of secondary mirror / val_mirror is gone one JEP 401 >> 3664: Node* p = basic_plus_adr(mirror, (int)0 /* java_lang_Class::secondary_mirror_offset() */); > > This will break Escape Analysis because such an access with zero offset is unexpected: > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/oracle/valhalla/open/src/hotspot/share/opto/escape.cpp:896), pid=600228, tid=600242 > # assert(_igvn->type(adr)->isa_rawptr()) failed: sanity > # > # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2024-02-06-1232159.tobias...) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2024-02-06-1232159.tobias..., compiled mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0xbe2ec4] ConnectionGraph::add_objload_to_connection_graph(Node*, Unique_Node_List*)+0x284 > > > Please add this to disable the check properly: > > > diff --git a/src/hotspot/share/opto/library_call.cpp b/src/hotspot/share/opto/library_call.cpp > index 92425fecf11..bd3ed61744b 100644 > --- a/src/hotspot/share/opto/library_call.cpp > +++ b/src/hotspot/share/opto/library_call.cpp > @@ -4310,7 +4310,8 @@ bool LibraryCallKit::inline_native_subtype_check() { > region->set_req(_both_ref_path, gen_subtype_check(subk, superk)); > // If superc is an inline mirror, we also need to check if superc == subc because LMyValue > // is not a subtype of QMyValue but due to subk == superk the subtype check will pass. > - generate_fair_guard(is_val_mirror(args[0]), prim_region); > + // TODO JDK-8325660 > + // generate_fair_guard(is_val_mirror(args[0]), prim_region); > // now we have a successful reference subtype check > region->set_req(_ref_subtype_path, control()); > } Thank you for the quick fix. > src/hotspot/share/opto/parse2.cpp line 3510: > >> 3508: break; >> 3509: case Bytecodes::_withfield: >> 3510: do_withfield(); > > Could you add a `// TODO JDK-8325660` to both methods so we don't forget removing them (or simply remove them right away)? do_withfield() and do_aconst_init() methods have been removed from C2 parse* code. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1017#discussion_r1502818469 PR Review Comment: https://git.openjdk.org/valhalla/pull/1017#discussion_r1502819315 From thartmann at openjdk.org Mon Feb 26 15:58:05 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 26 Feb 2024 15:58:05 GMT Subject: [lworld] RFR: 8326595: [lworld] Bootstrap VM transition to JEP 401 model [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 15:42:48 GMT, Frederic Parain wrote: >> Bootstrapping transition to JEP 401 model. >> A lot of things are broken, but at least the build works on most platforms, the VM can boot and execute some JEP 401 class files in interpreted mode. The ability to run code with value classes is still limited because the VM depends on some JDK core classes that need to be updated too (reflection and substitutability test). >> >> Transition changes include: >> - Accepting new class file format (not rejecting correct JEP 401 class files), changes class hierarchy rules, class flags meaning, changes verifier rules >> - Update new and putfield bytecodes in interpreter to support new construction sequence >> - Runtime tests fixes >> >> Cleanup changes include: >> - Removal of support of Q-descriptors (and Q-desc bit in constant pool) >> - Removal of support of old class flags (ACC_VALUE) >> - Removal of aconst_init and withfield bytecodes from the interpreter and C1 >> - Removal of support for secondary mirror >> - Removal of support for primitive classes >> - Removal of support for value factories () >> - Partial removal of T_PRIMITIVE_OBJECT > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > More C2 fixes and cleanup Thanks, looks good! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1017#pullrequestreview-1901273848 From rriggs at openjdk.org Mon Feb 26 16:02:02 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Feb 2024 16:02:02 GMT Subject: [lworld] RFR: 8326602: [lworld] substitutabillity test does not support cyclic membership properly [v2] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 22:21:47 GMT, Mandy Chung wrote: >> `test/jdk/valhalla/valuetypes/RecursiveValueClass.java` test fails when the primitive value class is migrated to null-restricted value types. It uncovers a bug in supporting mutual recursive types. The recursive method handle should be created with the base functions of mutual recursive types so that it can call the recursive method handle for another type properly. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > ignore one test The approach looks good, but I didn't double-check every line of code. ------------- Marked as reviewed by rriggs (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1018#pullrequestreview-1901304692 From fparain at openjdk.org Mon Feb 26 16:07:16 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 26 Feb 2024 16:07:16 GMT Subject: [lworld] RFR: 8326595: [lworld] Bootstrap VM transition to JEP 401 model [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 12:03:17 GMT, Tobias Hartmann wrote: >> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: >> >> More C2 fixes and cleanup > > src/hotspot/share/opto/library_call.cpp line 4118: > >> 4116: } >> 4117: >> 4118: // // JDK-8325660: Code has been modified because secondary mirror are gone in JEP 401 > > Suggestion: > > // JDK-8325660: Code has been modified because secondary mirror are gone in JEP 401 Fixed ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1017#discussion_r1502886760 From fparain at openjdk.org Mon Feb 26 16:07:17 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 26 Feb 2024 16:07:17 GMT Subject: [lworld] Integrated: 8326595: [lworld] Bootstrap VM transition to JEP 401 model In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 20:24:15 GMT, Frederic Parain wrote: > Bootstrapping transition to JEP 401 model. > A lot of things are broken, but at least the build works on most platforms, the VM can boot and execute some JEP 401 class files in interpreted mode. The ability to run code with value classes is still limited because the VM depends on some JDK core classes that need to be updated too (reflection and substitutability test). > > Transition changes include: > - Accepting new class file format (not rejecting correct JEP 401 class files), changes class hierarchy rules, class flags meaning, changes verifier rules > - Update new and putfield bytecodes in interpreter to support new construction sequence > - Runtime tests fixes > > Cleanup changes include: > - Removal of support of Q-descriptors (and Q-desc bit in constant pool) > - Removal of support of old class flags (ACC_VALUE) > - Removal of aconst_init and withfield bytecodes from the interpreter and C1 > - Removal of support for secondary mirror > - Removal of support for primitive classes > - Removal of support for value factories () > - Partial removal of T_PRIMITIVE_OBJECT This pull request has now been integrated. Changeset: d6e5c8e8 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/d6e5c8e81a248218ccdfe06825c446d022cf2186 Stats: 2205 lines in 163 files changed: 96 ins; 1749 del; 360 mod 8326595: [lworld] Bootstrap VM transition to JEP 401 model Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1017 From fparain at openjdk.org Mon Feb 26 16:07:16 2024 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 26 Feb 2024 16:07:16 GMT Subject: [lworld] RFR: 8326595: [lworld] Bootstrap VM transition to JEP 401 model [v2] In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 15:42:48 GMT, Frederic Parain wrote: >> Bootstrapping transition to JEP 401 model. >> A lot of things are broken, but at least the build works on most platforms, the VM can boot and execute some JEP 401 class files in interpreted mode. The ability to run code with value classes is still limited because the VM depends on some JDK core classes that need to be updated too (reflection and substitutability test). >> >> Transition changes include: >> - Accepting new class file format (not rejecting correct JEP 401 class files), changes class hierarchy rules, class flags meaning, changes verifier rules >> - Update new and putfield bytecodes in interpreter to support new construction sequence >> - Runtime tests fixes >> >> Cleanup changes include: >> - Removal of support of Q-descriptors (and Q-desc bit in constant pool) >> - Removal of support of old class flags (ACC_VALUE) >> - Removal of aconst_init and withfield bytecodes from the interpreter and C1 >> - Removal of support for secondary mirror >> - Removal of support for primitive classes >> - Removal of support for value factories () >> - Partial removal of T_PRIMITIVE_OBJECT > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > More C2 fixes and cleanup Thanks Tobias for the review and the fix. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1017#issuecomment-1964511718 From forax at univ-mlv.fr Mon Feb 26 17:41:01 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 26 Feb 2024 18:41:01 +0100 (CET) Subject: Current and near future state of the Valhalla git repository In-Reply-To: References: Message-ID: <865955450.15273836.1708969261922.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Frederic Parain" > To: "valhalla-dev" > Sent: Monday, February 26, 2024 4:14:50 PM > Subject: Current and near future state of the Valhalla git repository > You might have noticed that the HEAD of the lworld branch in the > Valhalla git repository on GitHub is currently broken. > We are in the process of transitioning from the previous value classes > model to the new model described in JEP 401 > (https://openjdk.org/jeps/401). This transition requires significant > changes in both the JVM and some core-libraries classes: removal of > bytecodes, new class file format, etc. Unfortunately, all those changes > are too big to be done in a single changeset. So, changes will be > integrated incrementally, and in the mean time, things might? be broken. > > We have considered doing the changes in a separate branch, but trying to > maintain two branches in relative sync with JDK mainline would have > doubled the merge workload. And anyway, the old value class model in the > lworld branch will not be maintained anymore, so it doesn't make sense > to continue keeping it working. > > If you still need a buildable and functioning version of the Valhalla > prototype, even if it implements the old value class model, the last > good state of the lworld branch is commit > 1d120f32389332fdcfcd3213300a73447ad26e4d > > If you are working on your own branch created from the lworld branch, we > recommend to wait until the end of the transition before pulling changes > from lworld to your branch. Thanks for the update Frederic. > > Fred R?mi From rriggs at openjdk.org Mon Feb 26 21:24:53 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Feb 2024 21:24:53 GMT Subject: [lworld] RFR: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag Message-ID: Remove the VALUE modifier in Modifier.java and AccessFlag.java. Map the Class.isValue() method to `!Class.isIdentity()`. ------------- Commit messages: - 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag Changes: https://git.openjdk.org/valhalla/pull/1019/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1019&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326707 Stats: 34 lines in 4 files changed: 0 ins; 23 del; 11 mod Patch: https://git.openjdk.org/valhalla/pull/1019.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1019/head:pull/1019 PR: https://git.openjdk.org/valhalla/pull/1019 From mchung at openjdk.org Mon Feb 26 21:34:51 2024 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 26 Feb 2024 21:34:51 GMT Subject: [lworld] Integrated: 8326602: [lworld] substitutabillity test does not support cyclic membership properly In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 19:43:11 GMT, Mandy Chung wrote: > `test/jdk/valhalla/valuetypes/RecursiveValueClass.java` test fails when the primitive value class is migrated to null-restricted value types. It uncovers a bug in supporting mutual recursive types. The recursive method handle should be created with the base functions of mutual recursive types so that it can call the recursive method handle for another type properly. This pull request has now been integrated. Changeset: d6c5daad Author: Mandy Chung URL: https://git.openjdk.org/valhalla/commit/d6c5daad3cc5eb046151566da5a3ffd40fa08b66 Stats: 1180 lines in 3 files changed: 766 ins; 347 del; 67 mod 8326602: [lworld] substitutabillity test does not support cyclic membership properly Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/valhalla/pull/1018 From mchung at openjdk.org Mon Feb 26 23:01:04 2024 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 26 Feb 2024 23:01:04 GMT Subject: [lworld] RFR: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 21:19:12 GMT, Roger Riggs wrote: > Remove the VALUE modifier in Modifier.java and AccessFlag.java. > Map the Class.isValue() method to `!Class.isIdentity()`. src/java.base/share/classes/java/lang/Class.java line 709: > 707: @PreviewFeature(feature = PreviewFeature.Feature.VALUE_OBJECTS) > 708: public boolean isValue() { > 709: return (this.getModifiers() & Modifier.IDENTITY) == 0; This needs to test if it's a primitive type, `void`, and an array type which do not have `IDENTITY` modifier set. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1019#discussion_r1503416241 From mchung at openjdk.org Tue Feb 27 00:26:03 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 27 Feb 2024 00:26:03 GMT Subject: [lworld] RFR: 8326719: [lworld] Migrate core-libs support to JEP 401 (part 1) Message-ID: This patch includes: - Removal of support for secondary mirror - Removal of support for primitive classes - Removal of support for value factories - Removal of the intrinsic methods `Class::asPrimitiveType` and `asValueType` This patch includes a temporary fix of `Class::isValue` which will be replaced by #1019. ------------- Commit messages: - 8326719: [lworld] Migrate core-libs support to JEP 401 (part 1) Changes: https://git.openjdk.org/valhalla/pull/1020/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1020&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326719 Stats: 818 lines in 42 files changed: 3 ins; 738 del; 77 mod Patch: https://git.openjdk.org/valhalla/pull/1020.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1020/head:pull/1020 PR: https://git.openjdk.org/valhalla/pull/1020 From dsimms at openjdk.org Tue Feb 27 12:04:58 2024 From: dsimms at openjdk.org (David Simms) Date: Tue, 27 Feb 2024 12:04:58 GMT Subject: [lworld] RFR: 8326719: [lworld] Migrate core-libs support to JEP 401 (part 1) In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 00:21:27 GMT, Mandy Chung wrote: > This patch includes: > - Removal of support for secondary mirror > - Removal of support for primitive classes > - Removal of support for value factories > - Removal of the intrinsic methods `Class::asPrimitiveType` and `asValueType` > > This patch includes a temporary fix of `Class::isValue` which will be replaced by #1019. VM code removals look fine ------------- Marked as reviewed by dsimms (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1020#pullrequestreview-1903311587 From pedro.lamarao at prodist.com.br Tue Feb 27 14:49:00 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Tue, 27 Feb 2024 11:49:00 -0300 Subject: Recursively comparing Message-ID: Hello all! In reviewing the latest edition of JEP 401, I came into language that made me a little confused. In section "Identity-sensitive operations" we read: "Fields with primitive types are compared by their bit patterns. Other field values?both identity and value objects?are recursively compared with ==." Later, we read: "Also note that the == operator does not perform a "deep equals" comparison on identity objects stored in fields (...)" My understanding of value classes so far has been that value objects are compared as-if by &&-ing the ==s of its fields. This seems to me the meaning of identity object fields not being compared by some deep equals algorithm. However, earlier, the text says that identity objects are recursively compared with ==. But recursively means to me something similar to deep: one would "recurse into" the object`s own fields. I am not a native english speaker. Am I reading this incorrectly? What is the intention of saying that other field values, including identity object fields, are recursively compared with ==? -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Feb 27 15:07:13 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 27 Feb 2024 16:07:13 +0100 (CET) Subject: Recursively comparing In-Reply-To: References: Message-ID: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> > From: "Pedro Lamar?o" > To: "valhalla-dev" > Sent: Tuesday, February 27, 2024 3:49:00 PM > Subject: Recursively comparing > Hello all! Hello, > In reviewing the latest edition of JEP 401, I came into language that made me a > little confused. > In section "Identity-sensitive operations" we read: > "Fields with primitive types are compared by their bit patterns. Other field > values?both identity and value objects?are recursively compared with ==." > Later, we read: > "Also note that the == operator does not perform a "deep equals" comparison on > identity objects stored in fields (...)" > My understanding of value classes so far has been that value objects are > compared as-if by &&-ing the ==s of its fields. This seems to me the meaning of > identity object fields not being compared by some deep equals algorithm. > However, earlier, the text says that identity objects are recursively compared > with ==. But recursively means to me something similar to deep: one would > "recurse into" the object`s own fields. > I am not a native english speaker. Am I reading this incorrectly? What is the > intention of saying that other field values, including identity object fields, > are recursively compared with ==? I do not think the spec is not clear but let's take an example value record Foo(int i, float f) { } var foo1 = new Foo(); var foo2 = new Foo(); foo1 == foo2 is equivalent to bitpattern(foo1.i) == bitpattern((foo2.i) && bitpattern(foo1.f) == bitpattern(foo2.f) All primitives are compared using their bitpattern, for an int, bitpattern is equivalent to ==, but for a float, bit pattern is Float. floatToRawIntBits (). Now, let say, there is a third component of type Object value record Foo(int i, float f, Object o) { } In that case, foo1 == foo2 is equivalent to bitpattern(foo1.i) == bitpattern((foo2.i) && bitpattern(foo1.f) == bitpattern(foo2.f) && foo1.o == foo2.o So if 'o' is an identity object, like String, the address will be used and if 'o' is itself a value type, like Foo, then == becomes a recursive call. Is it more clear ? > -- > Pedro Lamar?o R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From fparain at openjdk.org Tue Feb 27 15:30:23 2024 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 27 Feb 2024 15:30:23 GMT Subject: [lworld] RFR: 8326839: [lworld] Aarch64 interpreter still prevents new bytecode to be used with value classes Message-ID: Small fix on aarch64 template interpreter: bytecode `new` was still rejecting value classes but this behavior is now allowed by JEP 401. The issue occurred only when `new` operates on a resolved constant pool entry. ------------- Commit messages: - Allow bytecode new to operate on value classes on aarch64 Changes: https://git.openjdk.org/valhalla/pull/1021/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326839 Stats: 25 lines in 2 files changed: 16 ins; 9 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1021.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1021/head:pull/1021 PR: https://git.openjdk.org/valhalla/pull/1021 From archie.cobbs at gmail.com Tue Feb 27 15:31:55 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 27 Feb 2024 09:31:55 -0600 Subject: Recursively comparing In-Reply-To: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> Message-ID: I am a native English speaker but I also found this slightly confusing :) The problem is, for better or worse, the word "recursive" is too closely associated with the phrase "deep equals" in people's minds. Maybe it could be clarified a bit: "Other field values?both identity and value objects? are compared using the == operator. Note that this definition is recursive in the case of value object fields". -Archie On Tue, Feb 27, 2024 at 9:08?AM Remi Forax wrote: > So if 'o' is an identity object, like String, the address will be used and > if 'o' is itself a value type, like Foo, then == becomes a recursive call. > > Is it more clear ? > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsimms at openjdk.org Tue Feb 27 15:56:58 2024 From: dsimms at openjdk.org (David Simms) Date: Tue, 27 Feb 2024 15:56:58 GMT Subject: [lworld] RFR: 8326839: [lworld] Aarch64 interpreter still prevents new bytecode to be used with value classes In-Reply-To: References: Message-ID: <-pZe-8L31n271DOSxqMJi4JYxVsTTgBn1fHOaGBAxPM=.a378ebf5-f96c-43eb-b609-076d46a2cd95@github.com> On Tue, 27 Feb 2024 15:26:18 GMT, Frederic Parain wrote: > Small fix on aarch64 template interpreter: bytecode `new` was still rejecting value classes but this behavior is now allowed by JEP 401. The issue occurred only when `new` operates on a resolved constant pool entry. LGTM ------------- Marked as reviewed by dsimms (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1021#pullrequestreview-1903962210 From fparain at openjdk.org Tue Feb 27 16:03:57 2024 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 27 Feb 2024 16:03:57 GMT Subject: [lworld] RFR: 8326839: [lworld] Aarch64 interpreter still prevents new bytecode to be used with value classes In-Reply-To: References: Message-ID: <2pTPPlApMc2o5wgb46rUOIvoBws1nw_TbwAthmkY4YM=.bdaea547-d4ae-401e-bc39-73eda70260e9@github.com> On Tue, 27 Feb 2024 15:26:18 GMT, Frederic Parain wrote: > Small fix on aarch64 template interpreter: bytecode `new` was still rejecting value classes but this behavior is now allowed by JEP 401. The issue occurred only when `new` operates on a resolved constant pool entry. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1021#issuecomment-1966890401 From fparain at openjdk.org Tue Feb 27 16:03:57 2024 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 27 Feb 2024 16:03:57 GMT Subject: [lworld] Integrated: 8326839: [lworld] Aarch64 interpreter still prevents new bytecode to be used with value classes In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 15:26:18 GMT, Frederic Parain wrote: > Small fix on aarch64 template interpreter: bytecode `new` was still rejecting value classes but this behavior is now allowed by JEP 401. The issue occurred only when `new` operates on a resolved constant pool entry. This pull request has now been integrated. Changeset: 7357a48f Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/7357a48fb68792fb893e6ea3a392051ce71ca55d Stats: 25 lines in 2 files changed: 16 ins; 9 del; 0 mod 8326839: [lworld] Aarch64 interpreter still prevents new bytecode to be used with value classes Reviewed-by: dsimms ------------- PR: https://git.openjdk.org/valhalla/pull/1021 From jbossons at gmail.com Tue Feb 27 16:48:41 2024 From: jbossons at gmail.com (John Bossons) Date: Tue, 27 Feb 2024 11:48:41 -0500 Subject: Recursively comparing In-Reply-To: References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> Message-ID: I would suggest "Note that this definition is recursive in the case of value object fields, *meaning that the value tested by == in that case is the set of field values stored for such fields*" -- if this is correct. Where the set of field values stored for a value object field contains a field that is in turn a value object, this recursive definition would imply a recursive application of == to the set of field values stored for that object, would it not? Which sounds awfully close to a deep equals test for value object fields (but not identity fields). On Tue, Feb 27, 2024 at 11:24?AM Archie Cobbs wrote: > I am a native English speaker but I also found this slightly confusing :) > > The problem is, for better or worse, the word "recursive" is too closely > associated with the phrase "deep equals" in people's minds. > > Maybe it could be clarified a bit: "Other field values?both identity and > value objects? are compared using the == operator. Note that this > definition is recursive in the case of value object fields". > > -Archie > > On Tue, Feb 27, 2024 at 9:08?AM Remi Forax wrote: > >> So if 'o' is an identity object, like String, the address will be used >> and if 'o' is itself a value type, like Foo, then == becomes a recursive >> call. >> >> Is it more clear ? >> > > -- > Archie L. Cobbs > -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Tue Feb 27 17:08:59 2024 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 27 Feb 2024 11:08:59 -0600 Subject: Recursively comparing In-Reply-To: References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On Tue, Feb 27, 2024 at 10:48?AM John Bossons wrote: > Where the set of field values stored for a value object field contains a > field that is in turn a value object, this recursive definition would imply > a recursive application of == to the set of field values stored for that > object, would it not? Which sounds awfully close to a deep equals test for > value object fields (but not identity fields). > That's a good point... so a simple (for Java developers) way to explain the behavior might be: "Deep equals" for value objects and "== equals" for non-value objects. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.org Tue Feb 27 18:05:32 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 27 Feb 2024 18:05:32 GMT Subject: [lworld] RFR: 8326719: [lworld] Migrate core-libs support to JEP 401 (part 1) [v2] In-Reply-To: References: Message-ID: > This patch includes: > - Removal of support for secondary mirror > - Removal of support for primitive classes > - Removal of support for value factories > - Removal of the intrinsic methods `Class::asPrimitiveType` and `asValueType` > > This patch includes a temporary fix of `Class::isValue` which will be replaced by #1019. Mandy Chung 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: - Unsafe::getReference no need to handle zero instance - Merge branch 'lworld' of https://github.com/openjdk/valhalla into dual-mirror - 8326719: [lworld] Migrate core-libs support to JEP 401 (part 1) ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1020/files - new: https://git.openjdk.org/valhalla/pull/1020/files/7a87e78c..d601ef26 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1020&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1020&range=00-01 Stats: 58 lines in 5 files changed: 25 ins; 31 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1020.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1020/head:pull/1020 PR: https://git.openjdk.org/valhalla/pull/1020 From mchung at openjdk.org Tue Feb 27 18:23:09 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 27 Feb 2024 18:23:09 GMT Subject: [lworld] Integrated: 8326719: [lworld] Migrate core-libs support to JEP 401 (part 1) In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 00:21:27 GMT, Mandy Chung wrote: > This patch includes: > - Removal of support for secondary mirror > - Removal of support for primitive classes > - Removal of support for value factories > - Removal of the intrinsic methods `Class::asPrimitiveType` and `asValueType` > > This patch includes a temporary fix of `Class::isValue` which will be replaced by #1019. This pull request has now been integrated. Changeset: bf218506 Author: Mandy Chung URL: https://git.openjdk.org/valhalla/commit/bf21850694d0291bc8552004611e9958b69e7dda Stats: 845 lines in 42 files changed: 9 ins; 759 del; 77 mod 8326719: [lworld] Migrate core-libs support to JEP 401 (part 1) Reviewed-by: dsimms ------------- PR: https://git.openjdk.org/valhalla/pull/1020 From mchung at openjdk.org Tue Feb 27 18:23:09 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 27 Feb 2024 18:23:09 GMT Subject: [lworld] RFR: 8326719: [lworld] Migrate core-libs support to JEP 401 (part 1) [v3] In-Reply-To: References: Message-ID: > This patch includes: > - Removal of support for secondary mirror > - Removal of support for primitive classes > - Removal of support for value factories > - Removal of the intrinsic methods `Class::asPrimitiveType` and `asValueType` > > This patch includes a temporary fix of `Class::isValue` which will be replaced by #1019. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: update comment ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1020/files - new: https://git.openjdk.org/valhalla/pull/1020/files/d601ef26..ffae4420 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1020&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1020&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1020.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1020/head:pull/1020 PR: https://git.openjdk.org/valhalla/pull/1020 From vromero at openjdk.org Tue Feb 27 18:45:07 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 27 Feb 2024 18:45:07 GMT Subject: [lworld] Integrated: 8326862: [lworld] javac is rejecting value records In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 18:40:45 GMT, Vicente Romero wrote: > code like: > > value record Point(int x, int y) {} > > > is being rejected by javac. `java.lang.Record` should be considered a value class. > > TIA This pull request has now been integrated. Changeset: b883f80f Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/b883f80f4253c0bc3fd2734595f8f25311bc22a1 Stats: 6 lines in 3 files changed: 5 ins; 0 del; 1 mod 8326862: [lworld] javac is rejecting value records ------------- PR: https://git.openjdk.org/valhalla/pull/1022 From vromero at openjdk.org Tue Feb 27 18:45:07 2024 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 27 Feb 2024 18:45:07 GMT Subject: [lworld] Integrated: 8326862: [lworld] javac is rejecting value records Message-ID: code like: value record Point(int x, int y) {} is being rejected by javac. `java.lang.Record` should be considered a value class. TIA ------------- Commit messages: - 8326862: [lworld] javac is rejecting value records Changes: https://git.openjdk.org/valhalla/pull/1022/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1022&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326862 Stats: 6 lines in 3 files changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1022.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1022/head:pull/1022 PR: https://git.openjdk.org/valhalla/pull/1022 From jbossons at gmail.com Tue Feb 27 19:36:13 2024 From: jbossons at gmail.com (John Bossons) Date: Tue, 27 Feb 2024 14:36:13 -0500 Subject: Recursively comparing In-Reply-To: References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Yes, but 'deep' only for (small) value objects that are stored by value. On Tue, Feb 27, 2024 at 12:09?PM Archie Cobbs wrote: > On Tue, Feb 27, 2024 at 10:48?AM John Bossons wrote: > >> Where the set of field values stored for a value object field contains a >> field that is in turn a value object, this recursive definition would imply >> a recursive application of == to the set of field values stored for that >> object, would it not? Which sounds awfully close to a deep equals test for >> value object fields (but not identity fields). >> > > That's a good point... so a simple (for Java developers) way to explain > the behavior might be: "Deep equals" for value objects and "== equals" for > non-value objects. > > -Archie > > -- > Archie L. Cobbs > -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.org Tue Feb 27 19:59:12 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 27 Feb 2024 19:59:12 GMT Subject: [lworld] RFR: 8326867: [lworld] remove Q-descriptor support from jdk.experimental.bytecode test library Message-ID: <0q8kmPLL8-6gTa8WISJImU1npgf0_xko1i9X4jRm5hM=.e91db30d-ebdd-4591-bebd-f52d1398b4c5@github.com> VM valhalla tests are using `jdk.experimental.bytecode` test library. These tests should be converted to use the new ClassFile API. This PR removes Q-descriptor support from `jdk.experimental.bytecode` test library as an interim fix. The test library is not updated to support JEP 401 properly and instead JDK-8308778 will ClassFile API to support Valhalla. With this patch, 31 `hotspot_valhalla_runtime` tests pass when running with -Xint. 2 test failures remain to be investigated. ------------- Commit messages: - 8326867: [lworld] remove Q-descriptor support from jdk.experimental.bytecode test library Changes: https://git.openjdk.org/valhalla/pull/1023/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1023&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326867 Stats: 47 lines in 4 files changed: 0 ins; 42 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1023.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1023/head:pull/1023 PR: https://git.openjdk.org/valhalla/pull/1023 From forax at univ-mlv.fr Tue Feb 27 20:03:06 2024 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 27 Feb 2024 21:03:06 +0100 (CET) Subject: Recursively comparing In-Reply-To: References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <2085888689.16337119.1709064186161.JavaMail.zimbra@univ-eiffel.fr> > From: "John Bossons" > To: "Archie Cobbs" > Cc: "Remi Forax" , "Pedro Lamar?o" > , "valhalla-dev" > Sent: Tuesday, February 27, 2024 8:36:13 PM > Subject: Re: Recursively comparing > Yes, but 'deep' only for (small) value objects that are stored by value. No, the semantics of a value class instance is independant of the storage, calling == on a value object always behave the same way. R?mi > On Tue, Feb 27, 2024 at 12:09 PM Archie Cobbs < [ mailto:archie.cobbs at gmail.com > | archie.cobbs at gmail.com ] > wrote: >> On Tue, Feb 27, 2024 at 10:48 AM John Bossons < [ mailto:jbossons at gmail.com | >> jbossons at gmail.com ] > wrote: >>> Where the set of field values stored for a value object field contains a field >>> that is in turn a value object, this recursive definition would imply a >>> recursive application of == to the set of field values stored for that object, >>> would it not? Which sounds awfully close to a deep equals test for value object >>> fields (but not identity fields). >> That's a good point... so a simple (for Java developers) way to explain the >> behavior might be: "Deep equals" for value objects and "== equals" for >> non-value objects. >> -Archie >> -- >> Archie L. Cobbs > -- > Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.org Tue Feb 27 20:03:59 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 27 Feb 2024 20:03:59 GMT Subject: [lworld] Integrated: 8326867: [lworld] remove Q-descriptor support from jdk.experimental.bytecode test library In-Reply-To: <0q8kmPLL8-6gTa8WISJImU1npgf0_xko1i9X4jRm5hM=.e91db30d-ebdd-4591-bebd-f52d1398b4c5@github.com> References: <0q8kmPLL8-6gTa8WISJImU1npgf0_xko1i9X4jRm5hM=.e91db30d-ebdd-4591-bebd-f52d1398b4c5@github.com> Message-ID: On Tue, 27 Feb 2024 19:53:57 GMT, Mandy Chung wrote: > VM valhalla tests are using `jdk.experimental.bytecode` test library. These tests should be converted to use the new ClassFile API. > > This PR removes Q-descriptor support from `jdk.experimental.bytecode` test library as an interim fix. The test library is not updated to support JEP 401 properly and instead JDK-8308778 will ClassFile API to support Valhalla. > > With this patch, 31 `hotspot_valhalla_runtime` tests pass when running with -Xint. 2 test failures remain to be investigated. This pull request has now been integrated. Changeset: 7c344270 Author: Mandy Chung URL: https://git.openjdk.org/valhalla/commit/7c34427035591d00cc073e5d4eb498e85448c2e6 Stats: 47 lines in 4 files changed: 0 ins; 42 del; 5 mod 8326867: [lworld] remove Q-descriptor support from jdk.experimental.bytecode test library ------------- PR: https://git.openjdk.org/valhalla/pull/1023 From rriggs at openjdk.org Tue Feb 27 21:38:55 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Feb 2024 21:38:55 GMT Subject: [lworld] Withdrawn: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 21:19:12 GMT, Roger Riggs wrote: > Remove the VALUE modifier in Modifier.java and AccessFlag.java. > Map the Class.isValue() method to `!Class.isIdentity()`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1019 From rriggs at openjdk.org Tue Feb 27 21:50:10 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Feb 2024 21:50:10 GMT Subject: [lworld] RFR: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag Message-ID: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> Remove the VALUE modifier in Modifier.java and AccessFlag.java. Update Class.isValue() to be false for primitive, array, and interface classes and otherwise be ~ACC_IDENTITY in the modifiers. ------------- Commit messages: - Cleanup Class.isValue and isIdentity methods - 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag Changes: https://git.openjdk.org/valhalla/pull/1024/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1024&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326707 Stats: 38 lines in 5 files changed: 0 ins; 22 del; 16 mod Patch: https://git.openjdk.org/valhalla/pull/1024.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1024/head:pull/1024 PR: https://git.openjdk.org/valhalla/pull/1024 From mchung at openjdk.org Tue Feb 27 23:01:52 2024 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 27 Feb 2024 23:01:52 GMT Subject: [lworld] RFR: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag In-Reply-To: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> References: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> Message-ID: On Tue, 27 Feb 2024 21:45:27 GMT, Roger Riggs wrote: > Remove the VALUE modifier in Modifier.java and AccessFlag.java. > Update Class.isValue() to be false for primitive, array, and interface classes and otherwise be ~ACC_IDENTITY in the modifiers. src/java.base/share/classes/java/lang/reflect/Modifier.java line 169: > 167: * {@code identity} modifier; {@code false} otherwise. > 168: */ > 169: public static boolean isValue(int mod) { I think we should remove this as there is no longer such a modifier. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1024#discussion_r1505116991 From jbossons at gmail.com Wed Feb 28 00:04:03 2024 From: jbossons at gmail.com (John Bossons) Date: Tue, 27 Feb 2024 19:04:03 -0500 Subject: Recursively comparing In-Reply-To: <2085888689.16337119.1709064186161.JavaMail.zimbra@univ-eiffel.fr> References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> <2085888689.16337119.1709064186161.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hi Remy, Even for a value object field in which the stored VO value is a reference? As I understand the spec, it's up to the JVM to choose how to handle a value object (even a null-restricted VO), depending on its size. If a VO field value is a VO, it's optional as to whether the JVM stores that field value as a reference or as a value. What the JVM does will depend on the VO size, right? If a VO field value is stored as a reference, calling == on that reference will behave the same way as calling == on an identity object reference. If the VO is stored as a value (a set of values which could include another VO. field), then the == will be recursive. Am I incorrect? John On Tue, Feb 27, 2024 at 3:03?PM wrote: > > > ------------------------------ > > *From: *"John Bossons" > *To: *"Archie Cobbs" > *Cc: *"Remi Forax" , "Pedro Lamar?o" < > pedro.lamarao at prodist.com.br>, "valhalla-dev" > *Sent: *Tuesday, February 27, 2024 8:36:13 PM > *Subject: *Re: Recursively comparing > > Yes, but 'deep' only for (small) value objects that are stored by value. > > > No, the semantics of a value class instance is independant of the storage, > calling == on a value object always behave the same way. > > R?mi > > > On Tue, Feb 27, 2024 at 12:09?PM Archie Cobbs > wrote: > >> On Tue, Feb 27, 2024 at 10:48?AM John Bossons wrote: >> >>> Where the set of field values stored for a value object field contains a >>> field that is in turn a value object, this recursive definition would imply >>> a recursive application of == to the set of field values stored for that >>> object, would it not? Which sounds awfully close to a deep equals test for >>> value object fields (but not identity fields). >>> >> >> That's a good point... so a simple (for Java developers) way to explain >> the behavior might be: "Deep equals" for value objects and "== equals" for >> non-value objects. >> >> -Archie >> >> -- >> Archie L. Cobbs >> > > > -- > Phone: (416) 450-3584 (cell) > > -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.org Wed Feb 28 01:48:02 2024 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 28 Feb 2024 01:48:02 GMT Subject: [lworld] RFR: 8326893: [lworld] update HiddenInlineClassTest and HiddenValueClass tests per JEP 401 Message-ID: `HiddenPoint.jcod` and `ValueImpl.jcod` are no longer needed. The class bytes of a compiled value class can be used to defined as a hidden class. `HiddenInlineClassTest` and `HiddenValueClass` tests are updated accordingly. ------------- Commit messages: - fix comment - 8326893: [lworld] update HiddenInlineClassTest and HiddenValueClass tests per JEP 401 Changes: https://git.openjdk.org/valhalla/pull/1025/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326893 Stats: 387 lines in 4 files changed: 19 ins; 363 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1025.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1025/head:pull/1025 PR: https://git.openjdk.org/valhalla/pull/1025 From john.r.rose at oracle.com Wed Feb 28 06:28:22 2024 From: john.r.rose at oracle.com (John Rose) Date: Tue, 27 Feb 2024 23:28:22 -0700 Subject: Recursively comparing In-Reply-To: References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> <2085888689.16337119.1709064186161.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <2BE86A4E-54A6-4BB7-AE94-14A77081F056@oracle.com> This is an interesting discussion. I?m not surprised that people are surprised by ==/acmp semantics. We surprised ourselves, at first. On 27 Feb 2024, at 17:04, John Bossons wrote: > Hi Remy, > > Even for a value object field in which the stored VO value is a reference? Yes, that is Remy?s point. It doesn?t matter how the virtual machine concretely stores the value. The semantics are derived from virtual data, not physical data. The VM makes optimization decisions below the ?virtual metal?. Users should expect that these decisions have no effect on program semantics (and so program outputs), other than perhaps speed or footprint. How would users like it if their methods with floating point computations got slightly different results, after the JIT kicked in? Answer: It would be a bug, and they wouldn?t. It?s the same with the VM?s choice of how to implement the virtual semantics of values, using a variety of techniques, including ?buffering? as a separate node in the heap. ?Buffering? is like what we have called ?boxing? in the past. But it?s different: The identity of a ?box? is sadly exposed in VM semantics, while a ?buffer??s identity is suppressed. If a value is not flattened in its container, it may instead be buffered on the heap, with a pointer left behind in the container. (It might also be lifted to registers after inlining and escape analysis; this is a different kind of flattening we call ?scalarization?.) But the meaning of ==/acmp is the same regardless of details of physical representation of its operands. > As I understand the spec, it's up to the JVM to choose how to handle a > value object (even a null-restricted VO), depending on its size. If a VO > field value is a VO, it's optional as to whether the JVM stores that field > value as a reference or as a value. What the JVM does will depend on the VO > size, right? Sort of right, but also an oversimplification. There are many factors besides size. Another factor can be whether the container is final or not, and yet another is whether it is volatile or not. As a rule of thumb, users should always expect the VM to surprise them, if they decide to open the hood and peek below the virtual metal. > If a VO field value is stored as a reference, calling == on > that reference will behave the same way as calling == on an identity object > reference. I am at a loss to understand the grounds of your confident assertion here. In any case, it is false. Consider the consequences of such a design: A. The VM will unpredictably choose to buffer, flatten, or scalarize values. B. These decisions are partially dependent on heap layout policy, which is stable over time (at this current date) but also dependent on JIT activity, which varies over time. C. Therefore, from run to run, or even within one run, a value which compares equal to itself at one point will compare unequal to itself later on, or vice versa. We think users would not welcome this kind of uncertainty in Java code. Full disclosure: About 10 years ago, I thought we could get away with it. We?d have to tell users not to fully trust the results of ==/acmp. Instead they must learn to always follow up == with a call to Object::equals. I thought this might be tolerable because users already do this as a matter of habit. The basic rule would have been, if two values compare ==, you know they must be the same value, but if they don?t, they still might be the same value. You must call equals if you need the accurate result. So doing the extra call restores predictability, of the expression as a whole. I called this the Heisenbox Model, because you would always have a kind of ?uncertainty principle? about whether a given value would be equal to itself, or whether it would suddenly turn into two separately buffered copies, whose pointers would be suddenly different. This can happen, for example, if JIT code deoptimizes to the interpreter, and the two copies of the same value are buffered separately, perhaps because they are in two stack frames related by inlining. Reminder: You will be surprised if you peek inside the VM. It is the VM?s responsibility to keep an evenhanded pretense of consistent behavior, whatever its internal gymnastics. So, changing execution paths to looking at values from a new angle might cause a deopt, and change the result of your comparison. Observation collapses the configuration to a random outcome? voil? Heisenboxes. (Apologies to the real physicists.) FTR, my first public writing on value classes in 2012 despaired of assigning any kind of predictable value to ==/acmp, which anticipated Heisenboxes as well: https://cr.openjdk.org/~jrose/oblog/value-types-in-the-vm.html I am glad most of it has proven wrong, including the bit about ==. My colleagues finally beat it out of me. The last gasp was in 2016: https://bugs.openjdk.org/browse/JDK-8163133 One reason I thought we could get away with Heisenboxes is there is a similar behavior, historically, in Common Lisp. The EQ predicate distinguishes certain numeric values that are numerically indistinguishable, if they happen to be buffered separately. The EQV predicate fixes that, at a higher cost. (And EQ and EQV are the same on Lisp?s version of identity objects, which is basically all objects except numbers.) So, relative to Lisp, our decision is that values are always compared by value, like EQV, and never by buffer identity like EQ. Dropping EQ from the model takes out a bunch of shifty uncertain behavior; now you can trust ==/acmp to do the same thing all the time for the same inputs. > If the VO is stored as a value (a set of values which could > include another VO. field), then the == will be recursive. Am I incorrect? Regardless of how the VM stores the VO, the == will be recursive. Some find the following corollary to this principle surprising: Neither the type nor the implementation of the variable containing the value affects the equality comparison. Therefore, if you have two Object pointers compared with ==/acmp, and they are both values (of the same class), there will be a recursive descent. It doesn?t matter that you thought you have mere Object pointers. The VM does the same work for value comparison regardless of context. This also means that if a value contains an Object field, then the recursive ==/acmp on a pair of such values will, in fact, test the corresponding Object references (as if by ==/acmp) and recurse if and only if the two objects are both values of the same class. Finally, this also means that if one has a value with two Object fields, an ==/acmp operation might possibly perform an unbounded recursive descent of a tree. At this point, a class designer might have to think hard about what is the desired behavior. One way to break the recursive descent is to use an intermediate heap node that is an identity object, such as an array. That is in fact how recursive structures are often written. But for a pure immutable fixed-arity tree class, refactoring to a value will involve consideration of the cost of ==/acmp. The design of such classes (such as HAMTs) is rarely attempted, and by experts when done at all. I am not worried about such experts being overwhelmed by the odd scaling of recursive descent in their exquisitely tuned classes. So we have been thinking about all this diligently and carefully for a decade, and JEP 401 is the result. Some might think it mandates too much recursion for ==/acmp. Users should prepare, however, to be surprised by what the VM will do to make such things fast. Remember the old conventional wisdom about bytecode-based VMs and pervasive virtual calls: Java was supposed to be slow because of such things? until it wasn?t slow anymore. One promising idea (IMO) for reducing ==/acmp costs is folding them with equivalent tests in Object::equals: https://bugs.openjdk.org/browse/JDK-8255024 So VM internals are surprising. That?s why (a) we are required, and (b) we are able, to design high-level VM semantics, with no uncertainties. Even if they might seem ?too expensive? at first blush. I hope these perspectives will be useful. They have been hard-won. ? John From dsimms at openjdk.org Wed Feb 28 09:51:56 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 28 Feb 2024 09:51:56 GMT Subject: [lworld] RFR: 8326893: [lworld] update HiddenInlineClassTest and HiddenValueClass tests per JEP 401 In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 01:42:46 GMT, Mandy Chung wrote: > `HiddenPoint.jcod` and `ValueImpl.jcod` are no longer needed. The class bytes of a compiled value class can be used to defined as a hidden class. `HiddenInlineClassTest` and `HiddenValueClass` tests are updated accordingly. Thanks ! ------------- Marked as reviewed by dsimms (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1025#pullrequestreview-1905792450 From adinn at redhat.com Wed Feb 28 10:56:24 2024 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 28 Feb 2024 10:56:24 +0000 Subject: Recursively comparing In-Reply-To: <2BE86A4E-54A6-4BB7-AE94-14A77081F056@oracle.com> References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> <2085888689.16337119.1709064186161.JavaMail.zimbra@univ-eiffel.fr> <2BE86A4E-54A6-4BB7-AE94-14A77081F056@oracle.com> Message-ID: <59784649-ddf2-7e91-8bb2-84760cc5444d@redhat.com> Thanks, John, for the usual clear, precise and informative exegesis. I have been lurking on valhalla-dev for over 5 years now precisely so I can catch 'public service announcements' like this one that pop up every now and again from John, Brian and others. Likewise on other lists. I am tempted to propose a new OpenJDK mail list, oracle.openjdk.org (note that the 'oracle' component implies revelation not company affiliation) where the rules of engagement specify a single weekly post from a suitably knowledgeable JDK or JVM contributor explaining the rationale and accompanying history for why some specific aspect of OpenJDK works the way it does/is the way it is. Probably not workable. Nevertheless it is immensely valuable for knowledge & understanding like this to be shared. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 28/02/2024 06:28, John Rose wrote: > This is an interesting discussion. I?m not surprised > that people are surprised by ==/acmp semantics. > We surprised ourselves, at first. > > On 27 Feb 2024, at 17:04, John Bossons wrote: > >> Hi Remy, >> >> Even for a value object field in which the stored VO value is a reference? > > Yes, that is Remy?s point. It doesn?t matter how the virtual > machine concretely stores the value. The semantics are derived > from virtual data, not physical data. > > The VM makes optimization decisions below the ?virtual metal?. > Users should expect that these decisions have no effect on program > semantics (and so program outputs), other than perhaps speed > or footprint. How would users like it if their methods with > floating point computations got slightly different results, > after the JIT kicked in? Answer: It would be a bug, and they > wouldn?t. > > It?s the same with the VM?s choice of how to implement the > virtual semantics of values, using a variety of techniques, > including ?buffering? as a separate node in the heap. > ?Buffering? is like what we have called ?boxing? in the past. > But it?s different: The identity of a ?box? is sadly exposed > in VM semantics, while a ?buffer??s identity is suppressed. > > If a value is not flattened in its container, it may instead > be buffered on the heap, with a pointer left behind in the > container. (It might also be lifted to registers after > inlining and escape analysis; this is a different kind of > flattening we call ?scalarization?.) But the meaning of > ==/acmp is the same regardless of details of physical > representation of its operands. > >> As I understand the spec, it's up to the JVM to choose how to handle a >> value object (even a null-restricted VO), depending on its size. If a VO >> field value is a VO, it's optional as to whether the JVM stores that field >> value as a reference or as a value. What the JVM does will depend on the VO >> size, right? > > Sort of right, but also an oversimplification. There are many > factors besides size. Another factor can be whether the container > is final or not, and yet another is whether it is volatile or not. > As a rule of thumb, users should always expect the VM to surprise them, > if they decide to open the hood and peek below the virtual metal. > >> If a VO field value is stored as a reference, calling == on >> that reference will behave the same way as calling == on an identity object >> reference. > > I am at a loss to understand the grounds of your confident assertion > here. In any case, it is false. Consider the consequences of such > a design: > > A. The VM will unpredictably choose to buffer, flatten, or scalarize > values. > > B. These decisions are partially dependent on heap layout policy, which > is stable over time (at this current date) but also dependent on JIT > activity, which varies over time. > > C. Therefore, from run to run, or even within one run, a value which > compares equal to itself at one point will compare unequal to > itself later on, or vice versa. We think users would not welcome > this kind of uncertainty in Java code. > > > > Full disclosure: About 10 years ago, I thought we could get away > with it. We?d have to tell users not to fully trust the results > of ==/acmp. Instead they must learn to always follow up == with > a call to Object::equals. I thought this might be tolerable > because users already do this as a matter of habit. > > The basic rule would have been, if two values compare ==, > you know they must be the same value, but if they don?t, > they still might be the same value. You must call equals > if you need the accurate result. So doing the extra call > restores predictability, of the expression as a whole. > > I called this the Heisenbox Model, because you would always > have a kind of ?uncertainty principle? about whether a given > value would be equal to itself, or whether it would suddenly > turn into two separately buffered copies, whose pointers would > be suddenly different. > > This can happen, for example, if JIT code deoptimizes to the > interpreter, and the two copies of the same value are buffered > separately, perhaps because they are in two stack frames > related by inlining. Reminder: You will be surprised if > you peek inside the VM. It is the VM?s responsibility to > keep an evenhanded pretense of consistent behavior, whatever > its internal gymnastics. > > So, changing execution paths to looking at values from > a new angle might cause a deopt, and change the result > of your comparison. Observation collapses the > configuration to a random outcome? voil? Heisenboxes. > (Apologies to the real physicists.) > > FTR, my first public writing on value classes in 2012 > despaired of assigning any kind of predictable value > to ==/acmp, which anticipated Heisenboxes as well: > https://cr.openjdk.org/~jrose/oblog/value-types-in-the-vm.html > I am glad most of it has proven wrong, including > the bit about ==. My colleagues finally beat it > out of me. The last gasp was in 2016: > https://bugs.openjdk.org/browse/JDK-8163133 > > One reason I thought we could get away with Heisenboxes is > there is a similar behavior, historically, in Common Lisp. > The EQ predicate distinguishes certain numeric values that > are numerically indistinguishable, if they happen to be > buffered separately. The EQV predicate fixes that, at a > higher cost. (And EQ and EQV are the same on Lisp?s version > of identity objects, which is basically all objects except > numbers.) So, relative to Lisp, our decision is that values > are always compared by value, like EQV, and never by buffer > identity like EQ. Dropping EQ from the model takes out a > bunch of shifty uncertain behavior; now you can trust ==/acmp > to do the same thing all the time for the same inputs. > > > >> If the VO is stored as a value (a set of values which could >> include another VO. field), then the == will be recursive. Am I incorrect? > > Regardless of how the VM stores the VO, the == will be recursive. > > Some find the following corollary to this principle surprising: > > Neither the type nor the implementation of the variable containing > the value affects the equality comparison. Therefore, if you have > two Object pointers compared with ==/acmp, and they are both values > (of the same class), there will be a recursive descent. It doesn?t > matter that you thought you have mere Object pointers. The VM > does the same work for value comparison regardless of context. > > This also means that if a value contains an Object field, then > the recursive ==/acmp on a pair of such values will, in fact, > test the corresponding Object references (as if by ==/acmp) > and recurse if and only if the two objects are both values > of the same class. > > Finally, this also means that if one has a value with two > Object fields, an ==/acmp operation might possibly perform > an unbounded recursive descent of a tree. At this point, > a class designer might have to think hard about what is > the desired behavior. One way to break the recursive > descent is to use an intermediate heap node that is an > identity object, such as an array. That is in fact how > recursive structures are often written. But for a pure > immutable fixed-arity tree class, refactoring to a value > will involve consideration of the cost of ==/acmp. The > design of such classes (such as HAMTs) is rarely attempted, > and by experts when done at all. I am not worried about > such experts being overwhelmed by the odd scaling of > recursive descent in their exquisitely tuned classes. > > So we have been thinking about all this diligently and > carefully for a decade, and JEP 401 is the result. > > Some might think it mandates too much recursion for ==/acmp. > Users should prepare, however, to be surprised by what the VM > will do to make such things fast. Remember the old > conventional wisdom about bytecode-based VMs and pervasive > virtual calls: Java was supposed to be slow because of > such things? until it wasn?t slow anymore. One promising > idea (IMO) for reducing ==/acmp costs is folding them with > equivalent tests in Object::equals: > https://bugs.openjdk.org/browse/JDK-8255024 > > So VM internals are surprising. That?s why (a) we are > required, and (b) we are able, to design high-level VM > semantics, with no uncertainties. Even if they might > seem ?too expensive? at first blush. > > I hope these perspectives will be useful. They have > been hard-won. > > ? John From dsimms at openjdk.org Wed Feb 28 12:20:13 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 28 Feb 2024 12:20:13 GMT Subject: [lworld] RFR: 8326950: [lworld] InlineTypeArray: avoid using Arrays.copyOf() until API discussed Message-ID: <9_7yzYV2XyIWvBm7X7hAZPQGEh1pr01m1F338rmIngk=.a71289ab-3f78-49d6-9dc7-20d428658f58@github.com> testUtilArrays: manual array copy instead ------------- Commit messages: - 8326950: [lworld] InlineTypeArray: avoid using Arrays.copyOf() until API discussed Changes: https://git.openjdk.org/valhalla/pull/1026/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1026&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326950 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1026.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1026/head:pull/1026 PR: https://git.openjdk.org/valhalla/pull/1026 From dsimms at openjdk.org Wed Feb 28 12:26:53 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 28 Feb 2024 12:26:53 GMT Subject: [lworld] RFR: 8326950: [lworld] InlineTypeArray: avoid using Arrays.copyOf() until API discussed In-Reply-To: <9_7yzYV2XyIWvBm7X7hAZPQGEh1pr01m1F338rmIngk=.a71289ab-3f78-49d6-9dc7-20d428658f58@github.com> References: <9_7yzYV2XyIWvBm7X7hAZPQGEh1pr01m1F338rmIngk=.a71289ab-3f78-49d6-9dc7-20d428658f58@github.com> Message-ID: On Wed, 28 Feb 2024 12:15:10 GMT, David Simms wrote: > testUtilArrays: manual array copy instead Trivial test only issue ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1026#issuecomment-1968871527 From dsimms at openjdk.org Wed Feb 28 12:26:53 2024 From: dsimms at openjdk.org (David Simms) Date: Wed, 28 Feb 2024 12:26:53 GMT Subject: [lworld] Integrated: 8326950: [lworld] InlineTypeArray: avoid using Arrays.copyOf() until API discussed In-Reply-To: <9_7yzYV2XyIWvBm7X7hAZPQGEh1pr01m1F338rmIngk=.a71289ab-3f78-49d6-9dc7-20d428658f58@github.com> References: <9_7yzYV2XyIWvBm7X7hAZPQGEh1pr01m1F338rmIngk=.a71289ab-3f78-49d6-9dc7-20d428658f58@github.com> Message-ID: On Wed, 28 Feb 2024 12:15:10 GMT, David Simms wrote: > testUtilArrays: manual array copy instead This pull request has now been integrated. Changeset: b093b577 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/b093b5775934a64c017c86267fbb2d14a4891fcf Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod 8326950: [lworld] InlineTypeArray: avoid using Arrays.copyOf() until API discussed ------------- PR: https://git.openjdk.org/valhalla/pull/1026 From mchung at openjdk.org Wed Feb 28 17:07:55 2024 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 28 Feb 2024 17:07:55 GMT Subject: [lworld] Integrated: 8326893: [lworld] update HiddenInlineClassTest and HiddenValueClass tests per JEP 401 In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 01:42:46 GMT, Mandy Chung wrote: > `HiddenPoint.jcod` and `ValueImpl.jcod` are no longer needed. The class bytes of a compiled value class can be used to defined as a hidden class. `HiddenInlineClassTest` and `HiddenValueClass` tests are updated accordingly. This pull request has now been integrated. Changeset: 96e1db11 Author: Mandy Chung URL: https://git.openjdk.org/valhalla/commit/96e1db117f827a669d46a8349d38359a4b48b4cd Stats: 387 lines in 4 files changed: 19 ins; 363 del; 5 mod 8326893: [lworld] update HiddenInlineClassTest and HiddenValueClass tests per JEP 401 Reviewed-by: dsimms ------------- PR: https://git.openjdk.org/valhalla/pull/1025 From rriggs at openjdk.org Wed Feb 28 17:18:09 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Feb 2024 17:18:09 GMT Subject: [lworld] RFR: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag [v2] In-Reply-To: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> References: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> Message-ID: > Remove the VALUE modifier in Modifier.java and AccessFlag.java. > Update Class.isValue() to be false for primitive, array, and interface classes and otherwise be ~ACC_IDENTITY in the modifiers. Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: - 8326895: [lworld] Update AccessFlag and ClassAccessFlagTest Remove VALUE. Interfaces no longer have identity or value modifier bits, cleanup tests. - Remove Modifier.isValue(), the ACC_VALUE is not specified ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1024/files - new: https://git.openjdk.org/valhalla/pull/1024/files/eb97cfff..3883e043 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1024&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1024&range=00-01 Stats: 69 lines in 4 files changed: 16 ins; 48 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1024.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1024/head:pull/1024 PR: https://git.openjdk.org/valhalla/pull/1024 From rriggs at openjdk.org Wed Feb 28 18:20:07 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Feb 2024 18:20:07 GMT Subject: [lworld] RFR: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag [v3] In-Reply-To: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> References: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> Message-ID: > Remove the VALUE modifier in Modifier.java and AccessFlag.java. > Update Class.isValue() to be false for primitive, array, and interface classes and otherwise be ~ACC_IDENTITY in the modifiers. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Tweek to use || consistent with other uses in Class ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1024/files - new: https://git.openjdk.org/valhalla/pull/1024/files/3883e043..67c55794 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1024&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1024&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1024.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1024/head:pull/1024 PR: https://git.openjdk.org/valhalla/pull/1024 From mchung at openjdk.org Wed Feb 28 18:29:54 2024 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 28 Feb 2024 18:29:54 GMT Subject: [lworld] RFR: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag [v3] In-Reply-To: References: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> Message-ID: On Wed, 28 Feb 2024 18:20:07 GMT, Roger Riggs wrote: >> Remove the VALUE modifier in Modifier.java and AccessFlag.java. >> Update Class.isValue() to be false for primitive, array, and interface classes and otherwise be ~ACC_IDENTITY in the modifiers. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Tweek to use || consistent with other uses in Class Marked as reviewed by mchung (Committer). test/jdk/java/lang/reflect/AccessFlag/ClassAccessFlagTest.java line 62: > 60: StaticTestInterface.class, > 61: TestMarkerAnnotation.class, > 62: ExpectedClassFlags.class, nit: extra 4-space indentation. ------------- PR Review: https://git.openjdk.org/valhalla/pull/1024#pullrequestreview-1906972879 PR Review Comment: https://git.openjdk.org/valhalla/pull/1024#discussion_r1506398200 From jbossons at gmail.com Wed Feb 28 18:35:43 2024 From: jbossons at gmail.com (John Bossons) Date: Wed, 28 Feb 2024 13:35:43 -0500 Subject: Recursively comparing In-Reply-To: <2BE86A4E-54A6-4BB7-AE94-14A77081F056@oracle.com> References: <1910950733.16099304.1709046433033.JavaMail.zimbra@univ-eiffel.fr> <2085888689.16337119.1709064186161.JavaMail.zimbra@univ-eiffel.fr> <2BE86A4E-54A6-4BB7-AE94-14A77081F056@oracle.com> Message-ID: Thanks, John, for the correction. Much different from what I assumed! Very useful to know. John PS: Thanks for the JDL-8255024 reference. On Wed, Feb 28, 2024 at 1:28?AM John Rose wrote: > This is an interesting discussion. I?m not surprised > that people are surprised by ==/acmp semantics. > We surprised ourselves, at first. > > On 27 Feb 2024, at 17:04, John Bossons wrote: > > > Hi Remy, > > > > Even for a value object field in which the stored VO value is a > reference? > > Yes, that is Remy?s point. It doesn?t matter how the virtual > machine concretely stores the value. The semantics are derived > from virtual data, not physical data. > > The VM makes optimization decisions below the ?virtual metal?. > Users should expect that these decisions have no effect on program > semantics (and so program outputs), other than perhaps speed > or footprint. How would users like it if their methods with > floating point computations got slightly different results, > after the JIT kicked in? Answer: It would be a bug, and they > wouldn?t. > > It?s the same with the VM?s choice of how to implement the > virtual semantics of values, using a variety of techniques, > including ?buffering? as a separate node in the heap. > ?Buffering? is like what we have called ?boxing? in the past. > But it?s different: The identity of a ?box? is sadly exposed > in VM semantics, while a ?buffer??s identity is suppressed. > > If a value is not flattened in its container, it may instead > be buffered on the heap, with a pointer left behind in the > container. (It might also be lifted to registers after > inlining and escape analysis; this is a different kind of > flattening we call ?scalarization?.) But the meaning of > ==/acmp is the same regardless of details of physical > representation of its operands. > > > As I understand the spec, it's up to the JVM to choose how to handle a > > value object (even a null-restricted VO), depending on its size. If a VO > > field value is a VO, it's optional as to whether the JVM stores that > field > > value as a reference or as a value. What the JVM does will depend on the > VO > > size, right? > > Sort of right, but also an oversimplification. There are many > factors besides size. Another factor can be whether the container > is final or not, and yet another is whether it is volatile or not. > As a rule of thumb, users should always expect the VM to surprise them, > if they decide to open the hood and peek below the virtual metal. > > > If a VO field value is stored as a reference, calling == on > > that reference will behave the same way as calling == on an identity > object > > reference. > > I am at a loss to understand the grounds of your confident assertion > here. In any case, it is false. Consider the consequences of such > a design: > > A. The VM will unpredictably choose to buffer, flatten, or scalarize > values. > > B. These decisions are partially dependent on heap layout policy, which > is stable over time (at this current date) but also dependent on JIT > activity, which varies over time. > > C. Therefore, from run to run, or even within one run, a value which > compares equal to itself at one point will compare unequal to > itself later on, or vice versa. We think users would not welcome > this kind of uncertainty in Java code. > > > > Full disclosure: About 10 years ago, I thought we could get away > with it. We?d have to tell users not to fully trust the results > of ==/acmp. Instead they must learn to always follow up == with > a call to Object::equals. I thought this might be tolerable > because users already do this as a matter of habit. > > The basic rule would have been, if two values compare ==, > you know they must be the same value, but if they don?t, > they still might be the same value. You must call equals > if you need the accurate result. So doing the extra call > restores predictability, of the expression as a whole. > > I called this the Heisenbox Model, because you would always > have a kind of ?uncertainty principle? about whether a given > value would be equal to itself, or whether it would suddenly > turn into two separately buffered copies, whose pointers would > be suddenly different. > > This can happen, for example, if JIT code deoptimizes to the > interpreter, and the two copies of the same value are buffered > separately, perhaps because they are in two stack frames > related by inlining. Reminder: You will be surprised if > you peek inside the VM. It is the VM?s responsibility to > keep an evenhanded pretense of consistent behavior, whatever > its internal gymnastics. > > So, changing execution paths to looking at values from > a new angle might cause a deopt, and change the result > of your comparison. Observation collapses the > configuration to a random outcome? voil? Heisenboxes. > (Apologies to the real physicists.) > > FTR, my first public writing on value classes in 2012 > despaired of assigning any kind of predictable value > to ==/acmp, which anticipated Heisenboxes as well: > https://cr.openjdk.org/~jrose/oblog/value-types-in-the-vm.html > I am glad most of it has proven wrong, including > the bit about ==. My colleagues finally beat it > out of me. The last gasp was in 2016: > https://bugs.openjdk.org/browse/JDK-8163133 > > One reason I thought we could get away with Heisenboxes is > there is a similar behavior, historically, in Common Lisp. > The EQ predicate distinguishes certain numeric values that > are numerically indistinguishable, if they happen to be > buffered separately. The EQV predicate fixes that, at a > higher cost. (And EQ and EQV are the same on Lisp?s version > of identity objects, which is basically all objects except > numbers.) So, relative to Lisp, our decision is that values > are always compared by value, like EQV, and never by buffer > identity like EQ. Dropping EQ from the model takes out a > bunch of shifty uncertain behavior; now you can trust ==/acmp > to do the same thing all the time for the same inputs. > > > > > If the VO is stored as a value (a set of values which could > > include another VO. field), then the == will be recursive. Am I > incorrect? > > Regardless of how the VM stores the VO, the == will be recursive. > > Some find the following corollary to this principle surprising: > > Neither the type nor the implementation of the variable containing > the value affects the equality comparison. Therefore, if you have > two Object pointers compared with ==/acmp, and they are both values > (of the same class), there will be a recursive descent. It doesn?t > matter that you thought you have mere Object pointers. The VM > does the same work for value comparison regardless of context. > > This also means that if a value contains an Object field, then > the recursive ==/acmp on a pair of such values will, in fact, > test the corresponding Object references (as if by ==/acmp) > and recurse if and only if the two objects are both values > of the same class. > > Finally, this also means that if one has a value with two > Object fields, an ==/acmp operation might possibly perform > an unbounded recursive descent of a tree. At this point, > a class designer might have to think hard about what is > the desired behavior. One way to break the recursive > descent is to use an intermediate heap node that is an > identity object, such as an array. That is in fact how > recursive structures are often written. But for a pure > immutable fixed-arity tree class, refactoring to a value > will involve consideration of the cost of ==/acmp. The > design of such classes (such as HAMTs) is rarely attempted, > and by experts when done at all. I am not worried about > such experts being overwhelmed by the odd scaling of > recursive descent in their exquisitely tuned classes. > > So we have been thinking about all this diligently and > carefully for a decade, and JEP 401 is the result. > > Some might think it mandates too much recursion for ==/acmp. > Users should prepare, however, to be surprised by what the VM > will do to make such things fast. Remember the old > conventional wisdom about bytecode-based VMs and pervasive > virtual calls: Java was supposed to be slow because of > such things? until it wasn?t slow anymore. One promising > idea (IMO) for reducing ==/acmp costs is folding them with > equivalent tests in Object::equals: > https://bugs.openjdk.org/browse/JDK-8255024 > > So VM internals are surprising. That?s why (a) we are > required, and (b) we are able, to design high-level VM > semantics, with no uncertainties. Even if they might > seem ?too expensive? at first blush. > > I hope these perspectives will be useful. They have > been hard-won. > > ? John > -- Phone: (416) 450-3584 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Wed Feb 28 18:40:59 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Feb 2024 18:40:59 GMT Subject: [lworld] RFR: 8326879: [lworld] IncompatibleClassChangeError on `value record` extending java.lang.Record Message-ID: "value records" implicitly extend the abstract class java.lang.Record. Class loading throws IncompatibleClassChangeError if java.lang.Record is not marked as "abstract value class". The tests affected are: valhalla/valuetypes/ObjectMethods.java: test Object methods on value classes valhalla/valuetypes/ObjectMethodsViaCondy.java: Test ObjectMethods::bootstrap call via condy The solution is to add java.lang.Record to the set of classes that are modified for --enable-preview to be `value` classes. ------------- Commit messages: - Run various tests of Records with -XX:+EnableValhalla - 8326879: [lworld] IncompatibleClassChangeError on `value record` extending java.lang.Record Changes: https://git.openjdk.org/valhalla/pull/1027/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1027&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326879 Stats: 17 lines in 6 files changed: 7 ins; 0 del; 10 mod Patch: https://git.openjdk.org/valhalla/pull/1027.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1027/head:pull/1027 PR: https://git.openjdk.org/valhalla/pull/1027 From mchung at openjdk.org Wed Feb 28 19:05:54 2024 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 28 Feb 2024 19:05:54 GMT Subject: [lworld] RFR: 8326879: [lworld] IncompatibleClassChangeError on `value record` extending java.lang.Record In-Reply-To: References: Message-ID: <_LlNCNSejeNQcOlU1d10bPLD1PBYuCOdMnwsXp96ID0=.49570b8e-de9b-4859-aa29-ff0d480a9e98@github.com> On Wed, 28 Feb 2024 18:37:15 GMT, Roger Riggs wrote: > "value records" implicitly extend the abstract class java.lang.Record. > Class loading throws IncompatibleClassChangeError if java.lang.Record is not marked as "abstract value class". > > The tests affected are: > > valhalla/valuetypes/ObjectMethods.java: test Object methods on value classes > valhalla/valuetypes/ObjectMethodsViaCondy.java: Test ObjectMethods::bootstrap call via condy > > The solution is to add java.lang.Record to the set of classes that are modified for --enable-preview to be `value` classes. Marked as reviewed by mchung (Committer). ------------- PR Review: https://git.openjdk.org/valhalla/pull/1027#pullrequestreview-1907061247 From rriggs at openjdk.org Wed Feb 28 19:52:00 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Feb 2024 19:52:00 GMT Subject: [lworld] Integrated: 8326879: [lworld] IncompatibleClassChangeError on `value record` extending java.lang.Record In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 18:37:15 GMT, Roger Riggs wrote: > "value records" implicitly extend the abstract class java.lang.Record. > Class loading throws IncompatibleClassChangeError if java.lang.Record is not marked as "abstract value class". > > The tests affected are: > > valhalla/valuetypes/ObjectMethods.java: test Object methods on value classes > valhalla/valuetypes/ObjectMethodsViaCondy.java: Test ObjectMethods::bootstrap call via condy > > The solution is to add java.lang.Record to the set of classes that are modified for --enable-preview to be `value` classes. This pull request has now been integrated. Changeset: b04f3a94 Author: Roger Riggs URL: https://git.openjdk.org/valhalla/commit/b04f3a94d7b87d2958baaf7298313fb0c198249b Stats: 17 lines in 6 files changed: 7 ins; 0 del; 10 mod 8326879: [lworld] IncompatibleClassChangeError on `value record` extending java.lang.Record Reviewed-by: mchung ------------- PR: https://git.openjdk.org/valhalla/pull/1027 From rriggs at openjdk.org Wed Feb 28 22:20:03 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Feb 2024 22:20:03 GMT Subject: [lworld] RFR: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag [v4] In-Reply-To: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> References: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> Message-ID: > Remove the VALUE modifier in Modifier.java and AccessFlag.java. > Update Class.isValue() to be false for primitive, array, and interface classes and otherwise be ~ACC_IDENTITY in the modifiers. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct indentation ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1024/files - new: https://git.openjdk.org/valhalla/pull/1024/files/67c55794..965db72d Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1024&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1024&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1024.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1024/head:pull/1024 PR: https://git.openjdk.org/valhalla/pull/1024 From rriggs at openjdk.org Wed Feb 28 22:25:52 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Feb 2024 22:25:52 GMT Subject: [lworld] Integrated: 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag In-Reply-To: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> References: <4f9LC6hAjrNafBBDfEj4YMGeZ-HEj7UpJ7Pc2x38huA=.3e2fe14a-f5c3-432e-bffd-1c3605548d76@github.com> Message-ID: On Tue, 27 Feb 2024 21:45:27 GMT, Roger Riggs wrote: > Remove the VALUE modifier in Modifier.java and AccessFlag.java. > Update Class.isValue() to be false for primitive, array, and interface classes and otherwise be ~ACC_IDENTITY in the modifiers. This pull request has now been integrated. Changeset: 66be2291 Author: Roger Riggs URL: https://git.openjdk.org/valhalla/commit/66be2291ac519c5b33fcb4c036ec959ad16db788 Stats: 101 lines in 8 files changed: 16 ins; 70 del; 15 mod 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag Reviewed-by: mchung ------------- PR: https://git.openjdk.org/valhalla/pull/1024 From rriggs at openjdk.org Thu Feb 29 22:49:11 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 Feb 2024 22:49:11 GMT Subject: [lworld] RFR: 8327080: [lworld] Update Valhalla micros to JEP 401 Message-ID: A bulk update to change "primitive class" to "value class, remove .ref and replace .default with no-arg constructor. Plus other changes to get the benchmarks to compile. No assertions are made beyond compilation. The generated benchmarks.jar is well formed and can list the benchmarks. The makefile rule build-microbenchmark is re-enabled for the `test` target. ------------- Commit messages: - 8327080: [lworld] Update Valhalla micros to JEP 401 Changes: https://git.openjdk.org/valhalla/pull/1028/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1028&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327080 Stats: 707 lines in 116 files changed: 75 ins; 2 del; 630 mod Patch: https://git.openjdk.org/valhalla/pull/1028.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1028/head:pull/1028 PR: https://git.openjdk.org/valhalla/pull/1028