From qamai at openjdk.org Sun Mar 2 07:24:36 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 2 Mar 2025 07:24:36 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value Message-ID: Hi, This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: - `Identity` should not return a new node - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value Please take a look and leave your reviews, thanks a lot. ------------- Commit messages: - Refactor LoadNode::Identity of an InlineTypeNode to can_see_stored_value Changes: https://git.openjdk.org/valhalla/pull/1387/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1387&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351006 Stats: 50 lines in 2 files changed: 33 ins; 17 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1387.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1387/head:pull/1387 PR: https://git.openjdk.org/valhalla/pull/1387 From qamai at openjdk.org Sun Mar 2 18:27:18 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 2 Mar 2025 18:27:18 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: > > - `Identity` should not return a new node > - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value > > Please take a look and leave your reviews, thanks a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: assert non-larval ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1387/files - new: https://git.openjdk.org/valhalla/pull/1387/files/f4b83ce0..e2107287 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1387&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1387&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1387.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1387/head:pull/1387 PR: https://git.openjdk.org/valhalla/pull/1387 From dsimms at openjdk.org Mon Mar 3 13:34:16 2025 From: dsimms at openjdk.org (David Simms) Date: Mon, 3 Mar 2025 13:34:16 GMT Subject: [lworld] RFR: 8351037: [lworld] Crashing in CodeBlob::print_value_on() Message-ID: Trivial, missing array slot ------------- Commit messages: - 8351037: [lworld] Crashing in CodeBlob::print_value_on() Changes: https://git.openjdk.org/valhalla/pull/1388/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351037 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1388.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1388/head:pull/1388 PR: https://git.openjdk.org/valhalla/pull/1388 From dsimms at openjdk.org Mon Mar 3 15:06:18 2025 From: dsimms at openjdk.org (David Simms) Date: Mon, 3 Mar 2025 15:06:18 GMT Subject: [lworld] Integrated: 8351037: [lworld] Crashing in CodeBlob::print_value_on() In-Reply-To: References: Message-ID: On Mon, 3 Mar 2025 13:26:06 GMT, David Simms wrote: > Trivial, missing array slot This pull request has now been integrated. Changeset: ad75b32b Author: David Simms URL: https://git.openjdk.org/valhalla/commit/ad75b32ba8a66586706ee4f8d5fe4ed81654741e Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8351037: [lworld] Crashing in CodeBlob::print_value_on() ------------- PR: https://git.openjdk.org/valhalla/pull/1388 From duke at openjdk.org Mon Mar 3 15:10:24 2025 From: duke at openjdk.org (duke) Date: Mon, 3 Mar 2025 15:10:24 GMT Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack map tables [v3] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 20:12:43 GMT, Matias Saavedra Silva wrote: >> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. >> >> The patch is divided across 3 major commits: >> 1. VM changes for asserting that strict fields are initialized before the super constructor is called >> 2. Javac changes for generating the stack map table entries >> 3. Test >> >> Verified with tier 1-3 tests > > Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision: > > - Changed AssertUnsetFieldsTable to NameAndSig to bool > - Coleen suggestions @matias9927 Your change (at version 728753ba6e14287d486b63b6bafe5f1577f8d1d1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1373#issuecomment-2694707741 From matsaave at openjdk.org Mon Mar 3 15:10:24 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 3 Mar 2025 15:10:24 GMT Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack map tables [v3] In-Reply-To: References: Message-ID: On Fri, 28 Feb 2025 20:50:53 GMT, Coleen Phillimore wrote: >> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision: >> >> - Changed AssertUnsetFieldsTable to NameAndSig to bool >> - Coleen suggestions > > This looks really good, and the design fits very nicely with the work of the verifier in verifying stackmap tables. I reviewed the Hotspot changes. Thank you for the discussions and review @coleenp @fparain and @liach! Also thank you @vicente-romero-oracle for the javac component! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1373#issuecomment-2694705765 From matsaave at openjdk.org Mon Mar 3 15:15:15 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 3 Mar 2025 15:15:15 GMT Subject: [lworld] Integrated: 8343846: [lworld] implement spec changes to stack map tables In-Reply-To: References: Message-ID: On Fri, 21 Feb 2025 20:10:39 GMT, Matias Saavedra Silva wrote: > This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. > > The patch is divided across 3 major commits: > 1. VM changes for asserting that strict fields are initialized before the super constructor is called > 2. Javac changes for generating the stack map table entries > 3. Test > > Verified with tier 1-3 tests This pull request has now been integrated. Changeset: 7a1ff29d Author: Matias Saavedra Silva Committer: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/7a1ff29d9d1205713051720b5b7d21f114c21506 Stats: 1190 lines in 26 files changed: 963 ins; 43 del; 184 mod 8343846: [lworld] implement spec changes to stack map tables Co-authored-by: Vicente Romero Reviewed-by: coleenp, fparain, liach ------------- PR: https://git.openjdk.org/valhalla/pull/1373 From vromero at openjdk.org Wed Mar 5 02:13:40 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 5 Mar 2025 02:13:40 GMT Subject: [lworld] RFR: 8351217: [lworld] instance field initializers should be executed immediately upon entry to a non-this-calling constructor Message-ID: this PR is fixing a bug in javac. For code like: value class V { int i = 1; int y; V() { y = 2; } } javac is generating the constructor as: V() { y = 2; i = 1; super(); } it should be: V() { i = 1; y = 2; super(); } ------------- Commit messages: - 8351217: [lworld] instance field initializers should be executed immediately upon entry to a non-this-calling constructor Changes: https://git.openjdk.org/valhalla/pull/1390/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1390&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351217 Stats: 33 lines in 2 files changed: 32 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1390.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1390/head:pull/1390 PR: https://git.openjdk.org/valhalla/pull/1390 From chagedorn at openjdk.org Wed Mar 5 12:38:08 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 5 Mar 2025 12:38:08 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 18:27:18 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: >> >> - `Identity` should not return a new node >> - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value >> >> Please take a look and leave your reviews, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > assert non-larval Nice refactoring! > LoadUS from a short is not a mismatched access and hence can return a wrong value Do you have a test case where we get a wrong execution? If so, it would be great to add it as well :-) src/hotspot/share/opto/memnode.cpp line 1101: > 1099: } > 1100: > 1101: static Node* see_through_inline_type(PhaseValues* phase, const MemNode* load, Node* base, int offset) { Is there a specific reason that you made this `static` and not a member function of `MemNode` (then you can use `this` instead of `load`)? ------------- PR Review: https://git.openjdk.org/valhalla/pull/1387#pullrequestreview-2660967494 PR Review Comment: https://git.openjdk.org/valhalla/pull/1387#discussion_r1981311529 From vromero at openjdk.org Wed Mar 5 14:08:06 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 5 Mar 2025 14:08:06 GMT Subject: [lworld] Integrated: 8351217: [lworld] instance field initializers should be executed immediately upon entry to a non-this-calling constructor In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 02:08:34 GMT, Vicente Romero wrote: > this PR is fixing a bug in javac. For code like: > > value class V { > int i = 1; > int y; > > V() { > y = 2; > } > } > > javac is generating the constructor as: > > V() { > y = 2; > i = 1; > super(); > } > > it should be: > > V() { > i = 1; > y = 2; > super(); > } This pull request has now been integrated. Changeset: 67d181de Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/67d181de2a5916db4451e1894aca77a8d7b6e1c0 Stats: 33 lines in 2 files changed: 32 ins; 0 del; 1 mod 8351217: [lworld] instance field initializers should be executed immediately upon entry to a non-this-calling constructor ------------- PR: https://git.openjdk.org/valhalla/pull/1390 From qamai at openjdk.org Wed Mar 5 17:06:12 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 5 Mar 2025 17:06:12 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 12:35:38 GMT, Christian Hagedorn wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> assert non-larval > > Nice refactoring! > >> LoadUS from a short is not a mismatched access and hence can return a wrong value > > Do you have a test case where we get a wrong execution? If so, it would be great to add it as well :-) @chhagedorn Thanks for your reviews > Do you have a test case where we get a wrong execution? If so, it would be great to add it as well :-) Unfortunately, I cannot, this pops up when I'm working on another change. > Is there a specific reason that you made this `static` and not a member function of `MemNode` (then you can use `this` instead of `load`)? I think using `static` offers a more local scope, less visibility, and reduce convoluting the class declaration with helper methods. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1387#issuecomment-2701549785 From chagedorn at openjdk.org Thu Mar 6 17:49:09 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 6 Mar 2025 17:49:09 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 12:35:38 GMT, Christian Hagedorn wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> assert non-larval > > Nice refactoring! > >> LoadUS from a short is not a mismatched access and hence can return a wrong value > > Do you have a test case where we get a wrong execution? If so, it would be great to add it as well :-) > @chhagedorn Thanks for your reviews > > > Do you have a test case where we get a wrong execution? If so, it would be great to add it as well :-) > > Unfortunately, I cannot, this pops up when I'm working on another change. Okay, no problem. > > Is there a specific reason that you made this `static` and not a member function of `MemNode` (then you can use `this` instead of `load`)? > > I think using `static` offers a more local scope, less visibility, and reduce convoluting the class declaration with helper methods. I understand. I'm not quite sure about the visibility, though. It's now local to `memnode.cpp` which is huge. Moreover, it's not immediately clear to what class this method belongs to or from where it should be called from. Moving it to `MemNode` makes the intention clearer I think. But of course, it's just a personal opinion :-) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1387#issuecomment-2704537011 From qamai at openjdk.org Thu Mar 6 18:03:00 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 6 Mar 2025 18:03:00 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: On Thu, 6 Mar 2025 17:44:23 GMT, Christian Hagedorn wrote: > It's now local to memnode.cpp which is huge. If it is a method in `MemNode`, it needs to be `protected` since it is used by `LoadNNode`, so it is still effectively visible to the whole `memnode.cpp`, though. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1387#issuecomment-2704571171 From chagedorn at openjdk.org Thu Mar 6 18:49:26 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 6 Mar 2025 18:49:26 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 18:27:18 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: >> >> - `Identity` should not return a new node >> - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value >> >> Please take a look and leave your reviews, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > assert non-larval > > It's now local to memnode.cpp which is huge. > > If it is a method in `MemNode`, it needs to be `protected` since it is used by `LoadNNode` That's true, it would need to be `protected` but I guess that's okay. > so it is still effectively visible to the whole `memnode.cpp`, though. Not entirely, there are other methods of classes in `memnode.cpp` that do not inherit from `MemNode` like `MergeMemNode` or `MemBarNode`. That's why I thought it would be less visible/clearer when moving it to the `MemNode` class instead where the method is called from (or from sub classes). But I don't have a strong opinion and leave it up to you to make the final decision. I'm running some testing, will report the results back tomorrow. ------------- Marked as reviewed by chagedorn (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1387#pullrequestreview-2665343667 PR Comment: https://git.openjdk.org/valhalla/pull/1387#issuecomment-2704672157 From lmesnik at openjdk.org Fri Mar 7 17:43:25 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Mar 2025 17:43:25 GMT Subject: [lworld] RFR: 8351432: [lworld] Update nsk/jvmti/GetObjectMonitorUsage/objmonusage007.java to don't faile with compilation error Message-ID: <_6E8Nqi8T2fT8vp0Vk49qBAtdKOX1yH5rfUPd-VBNGA=.38958d4b-d499-4aec-8a74-85c2b6392920@github.com> The test is fixed to don't build itself code as a library ------------- Commit messages: - 8351432: [lworld] Update nsk/jvmti/GetObjectMonitorUsage/objmonusage007.java to don't faile with compilation error Changes: https://git.openjdk.org/valhalla/pull/1391/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1391&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351432 Stats: 63 lines in 2 files changed: 19 ins; 42 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1391.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1391/head:pull/1391 PR: https://git.openjdk.org/valhalla/pull/1391 From lmesnik at openjdk.org Fri Mar 7 17:48:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Mar 2025 17:48:13 GMT Subject: [lworld] RFR: 8351432: [lworld] Update nsk/jvmti/GetObjectMonitorUsage/objmonusage007.java to don't faile with compilation error [v2] In-Reply-To: <_6E8Nqi8T2fT8vp0Vk49qBAtdKOX1yH5rfUPd-VBNGA=.38958d4b-d499-4aec-8a74-85c2b6392920@github.com> References: <_6E8Nqi8T2fT8vp0Vk49qBAtdKOX1yH5rfUPd-VBNGA=.38958d4b-d499-4aec-8a74-85c2b6392920@github.com> Message-ID: > The test is fixed to don't build itself code as a library Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: space fixed ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1391/files - new: https://git.openjdk.org/valhalla/pull/1391/files/6286887e..c13295f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1391&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1391&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1391.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1391/head:pull/1391 PR: https://git.openjdk.org/valhalla/pull/1391 From rriggs at openjdk.org Fri Mar 7 19:48:00 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Mar 2025 19:48:00 GMT Subject: [lworld] RFR: 8351432: [lworld] Update nsk/jvmti/GetObjectMonitorUsage/objmonusage007.java to don't faile with compilation error [v2] In-Reply-To: References: <_6E8Nqi8T2fT8vp0Vk49qBAtdKOX1yH5rfUPd-VBNGA=.38958d4b-d499-4aec-8a74-85c2b6392920@github.com> Message-ID: On Fri, 7 Mar 2025 17:48:13 GMT, Leonid Mesnik wrote: >> The test is fixed to don't build itself code as a library > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > space fixed For simple change for which you are confident, there's not need to wait for a review. It is useful to allow enough time for people to response or comment. ------------- Marked as reviewed by rriggs (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1391#pullrequestreview-2668171037 From chagedorn at openjdk.org Fri Mar 7 22:37:12 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 7 Mar 2025 22:37:12 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: <4xg1Dr9ArFLxKWupG3JnYDrtuyxOHTl2xNJACTYeh-A=.bf3cadfe-7654-464a-b509-509b75b54d06@github.com> On Sun, 2 Mar 2025 18:27:18 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: >> >> - `Identity` should not return a new node >> - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value >> >> Please take a look and leave your reviews, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > assert non-larval There's been some failures which are probably unrelated - will double check with Tobias on Monday to be sure. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1387#issuecomment-2707620963 From lmesnik at openjdk.org Fri Mar 7 23:33:14 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Mar 2025 23:33:14 GMT Subject: [lworld] RFR: 8351432: [lworld] Update nsk/jvmti/GetObjectMonitorUsage/objmonusage007.java to don't faile with compilation error [v2] In-Reply-To: References: <_6E8Nqi8T2fT8vp0Vk49qBAtdKOX1yH5rfUPd-VBNGA=.38958d4b-d499-4aec-8a74-85c2b6392920@github.com> Message-ID: <9Iby94pJQiyp9HNc53fdBQTcLlbATcT9BpqeqgCCxzE=.229b414a-2c40-4d8c-8dc9-8848d78ad482@github.com> On Fri, 7 Mar 2025 19:45:01 GMT, Roger Riggs wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> space fixed > > For simple change for which you are confident, there's not need to wait for a review. > It is useful to allow enough time for people to response or comment. @RogerRiggs Thanks for explanation and review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1391#issuecomment-2707701618 From duke at openjdk.org Fri Mar 7 23:33:14 2025 From: duke at openjdk.org (duke) Date: Fri, 7 Mar 2025 23:33:14 GMT Subject: [lworld] RFR: 8351432: [lworld] Update nsk/jvmti/GetObjectMonitorUsage/objmonusage007.java to don't faile with compilation error [v2] In-Reply-To: References: <_6E8Nqi8T2fT8vp0Vk49qBAtdKOX1yH5rfUPd-VBNGA=.38958d4b-d499-4aec-8a74-85c2b6392920@github.com> Message-ID: On Fri, 7 Mar 2025 17:48:13 GMT, Leonid Mesnik wrote: >> The test is fixed to don't build itself code as a library > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > space fixed @lmesnik Your change (at version c13295f8ca9e0889d4542c4d5970832bed1c91d1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1391#issuecomment-2707702560 From liach at openjdk.org Mon Mar 10 03:51:44 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 10 Mar 2025 03:51:44 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment Message-ID: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Works for a basic case, running tests, need more tests to ensure other features added in this patch ------------- Commit messages: - Further optimize impl, complete tests - 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment Changes: https://git.openjdk.org/valhalla/pull/1392/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351441 Stats: 405 lines in 9 files changed: 379 ins; 7 del; 19 mod Patch: https://git.openjdk.org/valhalla/pull/1392.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1392/head:pull/1392 PR: https://git.openjdk.org/valhalla/pull/1392 From liach at openjdk.org Mon Mar 10 04:52:50 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 10 Mar 2025 04:52:50 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v2] In-Reply-To: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: > Works for a basic case, running tests, need more tests to ensure other features added in this patch Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix field transformation that add strict flag ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1392/files - new: https://git.openjdk.org/valhalla/pull/1392/files/c5429915..82e997b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=00-01 Stats: 97 lines in 5 files changed: 92 ins; 0 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/1392.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1392/head:pull/1392 PR: https://git.openjdk.org/valhalla/pull/1392 From lmesnik at openjdk.org Mon Mar 10 09:28:08 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 10 Mar 2025 09:28:08 GMT Subject: [lworld] Integrated: 8351432: [lworld] Update nsk/jvmti/GetObjectMonitorUsage/objmonusage007.java to don't faile with compilation error In-Reply-To: <_6E8Nqi8T2fT8vp0Vk49qBAtdKOX1yH5rfUPd-VBNGA=.38958d4b-d499-4aec-8a74-85c2b6392920@github.com> References: <_6E8Nqi8T2fT8vp0Vk49qBAtdKOX1yH5rfUPd-VBNGA=.38958d4b-d499-4aec-8a74-85c2b6392920@github.com> Message-ID: On Fri, 7 Mar 2025 17:39:04 GMT, Leonid Mesnik wrote: > The test is fixed to don't build itself code as a library This pull request has now been integrated. Changeset: 82a5d5d1 Author: Leonid Mesnik Committer: David Simms URL: https://git.openjdk.org/valhalla/commit/82a5d5d1d449e9319b74b0d114ffe97295a1f841 Stats: 62 lines in 2 files changed: 19 ins; 42 del; 1 mod 8351432: [lworld] Update nsk/jvmti/GetObjectMonitorUsage/objmonusage007.java to don't faile with compilation error Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/valhalla/pull/1391 From chagedorn at openjdk.org Mon Mar 10 14:44:12 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 10 Mar 2025 14:44:12 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 18:27:18 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: >> >> - `Identity` should not return a new node >> - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value >> >> Please take a look and leave your reviews, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > assert non-larval Testing looked good! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1387#issuecomment-2710835170 From fparain at openjdk.org Mon Mar 10 14:57:01 2025 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 10 Mar 2025 14:57:01 GMT Subject: [lworld] RFR: 8351483: [lworld] Field offset verification fails Message-ID: Fixing generation of flat layouts, to generate them only if some flattening is enabled. Fixing the wrapper classes offsets verification code. ------------- Commit messages: - Fix layouts generation and offsets verification Changes: https://git.openjdk.org/valhalla/pull/1393/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351483 Stats: 100 lines in 3 files changed: 97 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1393.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1393/head:pull/1393 PR: https://git.openjdk.org/valhalla/pull/1393 From fparain at openjdk.org Mon Mar 10 15:02:16 2025 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 10 Mar 2025 15:02:16 GMT Subject: [lworld] Integrated: 8351483: [lworld] Field offset verification fails In-Reply-To: References: Message-ID: <9wOTdSiO9hNMhmDeHvX0MVsK5629N25ymdNoOHap_es=.92e6bb8d-f47c-43f0-bd8b-19b68ba83671@github.com> On Mon, 10 Mar 2025 14:52:17 GMT, Frederic Parain wrote: > Fixing generation of flat layouts, to generate them only if some flattening is enabled. > Fixing the wrapper classes offsets verification code. This pull request has now been integrated. Changeset: 0ab54947 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/0ab54947ca037d13b653faeef87ed1ba683fad9b Stats: 100 lines in 3 files changed: 97 ins; 0 del; 3 mod 8351483: [lworld] Field offset verification fails ------------- PR: https://git.openjdk.org/valhalla/pull/1393 From liach at openjdk.org Mon Mar 10 15:49:34 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 10 Mar 2025 15:49:34 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v3] In-Reply-To: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: > Works for a basic case, running tests, need more tests to ensure other features added in this patch Chen Liang has updated the pull request incrementally with two additional commits since the last revision: - Years - Add a cache for strict field check ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1392/files - new: https://git.openjdk.org/valhalla/pull/1392/files/82e997b5..0db49074 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=01-02 Stats: 61 lines in 8 files changed: 33 ins; 17 del; 11 mod Patch: https://git.openjdk.org/valhalla/pull/1392.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1392/head:pull/1392 PR: https://git.openjdk.org/valhalla/pull/1392 From qamai at openjdk.org Mon Mar 10 16:16:07 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 10 Mar 2025 16:16:07 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 18:27:18 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: >> >> - `Identity` should not return a new node >> - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value >> >> Please take a look and leave your reviews, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > assert non-larval Thanks a lot for your reviews and testings, I assume 1 review is enough :p ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1387#issuecomment-2711117233 From duke at openjdk.org Mon Mar 10 16:16:07 2025 From: duke at openjdk.org (duke) Date: Mon, 10 Mar 2025 16:16:07 GMT Subject: [lworld] RFR: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value [v2] In-Reply-To: References: Message-ID: On Sun, 2 Mar 2025 18:27:18 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: >> >> - `Identity` should not return a new node >> - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value >> >> Please take a look and leave your reviews, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > assert non-larval @merykitty Your change (at version e21072874a4cf965a4b28c5826848d1e8d14e874) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1387#issuecomment-2711120224 From liach at openjdk.org Mon Mar 10 18:36:07 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 10 Mar 2025 18:36:07 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v4] In-Reply-To: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: > Works for a basic case, running tests, need more tests to ensure other features added in this patch Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Should check array mismatch instead of just frames (can have backward jumps) ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1392/files - new: https://git.openjdk.org/valhalla/pull/1392/files/0db49074..9e856519 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/1392.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1392/head:pull/1392 PR: https://git.openjdk.org/valhalla/pull/1392 From liach at openjdk.org Mon Mar 10 20:04:41 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 10 Mar 2025 20:04:41 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v5] In-Reply-To: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: <3pbuxfoP3MaiFdMP-IH3quYXDR73Qug2LZ5aCc-kbWE=.ce18c7eb-e387-418e-a084-b9d37506a912@github.com> > Works for a basic case, running tests, need more tests to ensure other features added in this patch Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Move test to classfile ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1392/files - new: https://git.openjdk.org/valhalla/pull/1392/files/9e856519..beb03349 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1392.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1392/head:pull/1392 PR: https://git.openjdk.org/valhalla/pull/1392 From liach at openjdk.org Mon Mar 10 20:56:05 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 10 Mar 2025 20:56:05 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v5] In-Reply-To: <3pbuxfoP3MaiFdMP-IH3quYXDR73Qug2LZ5aCc-kbWE=.ce18c7eb-e387-418e-a084-b9d37506a912@github.com> References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> <3pbuxfoP3MaiFdMP-IH3quYXDR73Qug2LZ5aCc-kbWE=.ce18c7eb-e387-418e-a084-b9d37506a912@github.com> Message-ID: On Mon, 10 Mar 2025 20:04:41 GMT, Chen Liang wrote: >> Works for a basic case, running tests, need more tests to ensure other features added in this patch > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move test to classfile Fixed an issue from vicente's review and moved test per riggs' suggestion. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1392#issuecomment-2711798840 From vromero at openjdk.org Mon Mar 10 22:43:09 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 10 Mar 2025 22:43:09 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v5] In-Reply-To: <3pbuxfoP3MaiFdMP-IH3quYXDR73Qug2LZ5aCc-kbWE=.ce18c7eb-e387-418e-a084-b9d37506a912@github.com> References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> <3pbuxfoP3MaiFdMP-IH3quYXDR73Qug2LZ5aCc-kbWE=.ce18c7eb-e387-418e-a084-b9d37506a912@github.com> Message-ID: On Mon, 10 Mar 2025 20:04:41 GMT, Chen Liang wrote: >> Works for a basic case, running tests, need more tests to ensure other features added in this patch > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Move test to classfile src/java.base/share/classes/jdk/internal/classfile/impl/WritableField.java line 82: > 80: if (sizeOne != sizeTwo) > 81: return true; > 82: for (int i = 0; i < sizeOne; i++) { there could be a mismatch even if both arrays have the same length and same content but the order of the fields is different in each array, not sure if this could happen but we should consider it ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1392#discussion_r1988116361 From liach at openjdk.org Mon Mar 10 22:57:10 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 10 Mar 2025 22:57:10 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v5] In-Reply-To: References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> <3pbuxfoP3MaiFdMP-IH3quYXDR73Qug2LZ5aCc-kbWE=.ce18c7eb-e387-418e-a084-b9d37506a912@github.com> Message-ID: On Mon, 10 Mar 2025 22:40:20 GMT, Vicente Romero wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Move test to classfile > > src/java.base/share/classes/jdk/internal/classfile/impl/WritableField.java line 82: > >> 80: if (sizeOne != sizeTwo) >> 81: return true; >> 82: for (int i = 0; i < sizeOne; i++) { > > there could be a mismatch even if both arrays have the same length and same content but the order of the fields is different in each array, not sure if this could happen but we should consider it Originally this matches because I am only removing unsets. Now Dan told me that we need to consider adding more to unset fields if we have loops, so I will do a sort for the arrays to ensure they have some definite order. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1392#discussion_r1988126697 From dsimms at openjdk.org Tue Mar 11 11:06:13 2025 From: dsimms at openjdk.org (David Simms) Date: Tue, 11 Mar 2025 11:06:13 GMT Subject: [lworld] RFR: Merge jdk Message-ID: Merge jdk-25+13 ------------- Commit messages: - Merge branch 'lworld' into lworld_merge_jdk_25_13 - Merge tag 'jdk-25+13' into lworld_merge_jdk_25_13 - 8351165: Remove unused includes from vmStructs - 8351074: Disallow null prefix and suffix in DecimalFormat - 8350808: Small typos in JShell method SnippetEvent.toString() - 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) - 8350854: Include thread counts in safepoint logging - 8281511: java/net/ipv6tests/UdpTest.java fails with checkTime failed - 8350546: Several java/net/InetAddress tests fails UnknownHostException - 8351115: Test AOTClassLinkingVMOptions.java fails after JDK-8348322 - ... and 89 more: https://git.openjdk.org/valhalla/compare/0ab54947...09916612 The webrevs contain the adjustments done while merging with regards to each parent branch: - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1394&range=00.0 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1394&range=00.1 Changes: https://git.openjdk.org/valhalla/pull/1394/files Stats: 24224 lines in 807 files changed: 10399 ins; 9859 del; 3966 mod Patch: https://git.openjdk.org/valhalla/pull/1394.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/valhalla/pull/1394 From dsimms at openjdk.org Tue Mar 11 15:46:21 2025 From: dsimms at openjdk.org (David Simms) Date: Tue, 11 Mar 2025 15:46:21 GMT Subject: [lworld] Integrated: Merge jdk In-Reply-To: References: Message-ID: On Tue, 11 Mar 2025 10:59:14 GMT, David Simms wrote: > Merge jdk-25+13 This pull request has now been integrated. Changeset: b0214511 Author: David Simms URL: https://git.openjdk.org/valhalla/commit/b021451112cab5a51d5c7d231734c78f5d7e01ed Stats: 24224 lines in 807 files changed: 10399 ins; 9859 del; 3966 mod Merge jdk Merge jdk-25+13 ------------- PR: https://git.openjdk.org/valhalla/pull/1394 From qamai at openjdk.org Tue Mar 11 17:33:07 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 11 Mar 2025 17:33:07 GMT Subject: [lworld] Integrated: 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value In-Reply-To: References: Message-ID: <7DjwPiE-4U32BgZ76XCwkv9lC0zFr8b6-VNyYhXiLnI=.96204b6a-927b-4fcb-9294-f11f864015d8@github.com> On Sun, 2 Mar 2025 07:19:58 GMT, Quan Anh Mai wrote: > Hi, > > This patch moves the logic of `LoadNode::Identity` that tries to look through an `InlineTypeNode` to `can_see_stored_value`. This also fixes 2 issues: > > - `Identity` should not return a new node > - `LoadUS` from a `short` is not a mismatched access and hence can return a wrong value > > Please take a look and leave your reviews, thanks a lot. This pull request has now been integrated. Changeset: b8b1fbcf Author: Quan Anh Mai Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/b8b1fbcfd6e6829c0b7d0ff79869941e303a99fa Stats: 52 lines in 2 files changed: 35 ins; 17 del; 0 mod 8351006: [lworld] Refactor LoadNode::Identity of an InlineType into can_see_stored_value Reviewed-by: chagedorn ------------- PR: https://git.openjdk.org/valhalla/pull/1387 From liach at openjdk.org Tue Mar 11 19:50:38 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 11 Mar 2025 19:50:38 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v6] In-Reply-To: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: > Works for a basic case, running tests, need more tests to ensure other features added in this patch Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/cf-strict - Fix flow merge checks - wip loop work - Move test to classfile - Should check array mismatch instead of just frames (can have backward jumps) - Years - Add a cache for strict field check - Fix field transformation that add strict flag - Further optimize impl, complete tests - 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1392/files - new: https://git.openjdk.org/valhalla/pull/1392/files/beb03349..d65b0b2f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1392&range=04-05 Stats: 24555 lines in 818 files changed: 10659 ins; 9919 del; 3977 mod Patch: https://git.openjdk.org/valhalla/pull/1392.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1392/head:pull/1392 PR: https://git.openjdk.org/valhalla/pull/1392 From liach at openjdk.org Tue Mar 11 19:55:04 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 11 Mar 2025 19:55:04 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v5] In-Reply-To: References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> <3pbuxfoP3MaiFdMP-IH3quYXDR73Qug2LZ5aCc-kbWE=.ce18c7eb-e387-418e-a084-b9d37506a912@github.com> Message-ID: On Mon, 10 Mar 2025 22:54:32 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/WritableField.java line 82: >> >>> 80: if (sizeOne != sizeTwo) >>> 81: return true; >>> 82: for (int i = 0; i < sizeOne; i++) { >> >> there could be a mismatch even if both arrays have the same length and same content but the order of the fields is different in each array, not sure if this could happen but we should consider it > > Originally this matches because I am only removing unsets. Now Dan told me that we need to consider adding more to unset fields if we have loops, so I will do a sort for the arrays to ensure they have some definite order. I have added more test cases for control flow merge with different DA results. In the new version, I sort the fields by their CP indices (their UTF8s are from the same CP). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1392#discussion_r1990032077 From liach at openjdk.org Tue Mar 11 21:39:17 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 11 Mar 2025 21:39:17 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v6] In-Reply-To: References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: On Tue, 11 Mar 2025 19:50:38 GMT, Chen Liang wrote: >> Works for a basic case, running tests, need more tests to ensure other features added in this patch > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/cf-strict > - Fix flow merge checks > - wip loop work > - Move test to classfile > - Should check array mismatch instead of just frames (can have backward jumps) > - Years > - Add a cache for strict field check > - Fix field transformation that add strict flag > - Further optimize impl, complete tests > - 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment No related failures in tier 1-3 testing. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1392#issuecomment-2715758907 From duke at openjdk.org Tue Mar 11 21:39:17 2025 From: duke at openjdk.org (duke) Date: Tue, 11 Mar 2025 21:39:17 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v6] In-Reply-To: References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: On Tue, 11 Mar 2025 19:50:38 GMT, Chen Liang wrote: >> Works for a basic case, running tests, need more tests to ensure other features added in this patch > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/cf-strict > - Fix flow merge checks > - wip loop work > - Move test to classfile > - Should check array mismatch instead of just frames (can have backward jumps) > - Years > - Add a cache for strict field check > - Fix field transformation that add strict flag > - Further optimize impl, complete tests > - 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment @liach Your change (at version d65b0b2f79ba541adc15bfff7bf7da2ab59216bf) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1392#issuecomment-2715760825 From vromero at openjdk.org Tue Mar 11 22:39:08 2025 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 11 Mar 2025 22:39:08 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v6] In-Reply-To: References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: On Tue, 11 Mar 2025 19:50:38 GMT, Chen Liang wrote: >> Works for a basic case, running tests, need more tests to ensure other features added in this patch > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/cf-strict > - Fix flow merge checks > - wip loop work > - Move test to classfile > - Should check array mismatch instead of just frames (can have backward jumps) > - Years > - Add a cache for strict field check > - Fix field transformation that add strict flag > - Further optimize impl, complete tests > - 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment Marked as reviewed by vromero (Committer). test/jdk/jdk/classfile/StrictStackMapsTest.java line 119: > 117: } > 118: > 119: @Test nit: it would be great if a comment with the corresponding java code being generated was included in these tests, this will make easier future changes, fixing bugs etc. But I let that to your consideration ------------- PR Review: https://git.openjdk.org/valhalla/pull/1392#pullrequestreview-2676259165 PR Review Comment: https://git.openjdk.org/valhalla/pull/1392#discussion_r1990212993 From vromero at openjdk.org Tue Mar 11 23:42:13 2025 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 11 Mar 2025 23:42:13 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v6] In-Reply-To: References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: On Tue, 11 Mar 2025 19:50:38 GMT, Chen Liang wrote: >> Works for a basic case, running tests, need more tests to ensure other features added in this patch > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/cf-strict > - Fix flow merge checks > - wip loop work > - Move test to classfile > - Should check array mismatch instead of just frames (can have backward jumps) > - Years > - Add a cache for strict field check > - Fix field transformation that add strict flag > - Further optimize impl, complete tests > - 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1258: > 1256: > 1257: // Merge this frame's unset fields into the target frame > 1258: private void mergeUnsetFields(Frame target) { what test case is stressing this code? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1392#discussion_r1990296005 From liach at openjdk.org Tue Mar 11 23:52:09 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 11 Mar 2025 23:52:09 GMT Subject: [lworld] RFR: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment [v6] In-Reply-To: References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: On Tue, 11 Mar 2025 23:38:56 GMT, Vicente Romero wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: >> >> - Merge branch 'lworld' of https://github.com/openjdk/valhalla into feature/cf-strict >> - Fix flow merge checks >> - wip loop work >> - Move test to classfile >> - Should check array mismatch instead of just frames (can have backward jumps) >> - Years >> - Add a cache for strict field check >> - Fix field transformation that add strict flag >> - Further optimize impl, complete tests >> - 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment > > src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1258: > >> 1256: >> 1257: // Merge this frame's unset fields into the target frame >> 1258: private void mergeUnsetFields(Frame target) { > > what test case is stressing this code? allowMultiAssignTest ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1392#discussion_r1990311630 From liach at openjdk.org Wed Mar 12 08:45:15 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 12 Mar 2025 08:45:15 GMT Subject: [lworld] Integrated: 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment In-Reply-To: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> References: <-g7FiRFUznmDZ2Nb81Uze2-rZE2l9RwNF4LyG8lwji0=.b88be507-c05f-48de-a2ee-306aff2b6504@github.com> Message-ID: On Fri, 7 Mar 2025 23:59:24 GMT, Chen Liang wrote: > Works for a basic case, running tests, need more tests to ensure other features added in this patch This pull request has now been integrated. Changeset: 103cff25 Author: Chen Liang Committer: David Simms URL: https://git.openjdk.org/valhalla/commit/103cff25d139d43d1e323a74687e7ecc3858a5bd Stats: 632 lines in 13 files changed: 595 ins; 7 del; 30 mod 8351441: [lworld] ClassFile API support generating stack maps for strict field assignment Reviewed-by: vromero ------------- PR: https://git.openjdk.org/valhalla/pull/1392 From liach at openjdk.org Wed Mar 12 14:20:36 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 12 Mar 2025 14:20:36 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing Message-ID: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. ------------- Commit messages: - 8351362: Post-process @Strict annotation for testing Changes: https://git.openjdk.org/valhalla/pull/1395/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1395&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351362 Stats: 228 lines in 5 files changed: 224 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/1395.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1395/head:pull/1395 PR: https://git.openjdk.org/valhalla/pull/1395 From fparain at openjdk.org Wed Mar 12 18:02:34 2025 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 12 Mar 2025 18:02:34 GMT Subject: [lworld] RFR: 8351550: [lworld] Some bootstrap methods/lambda factories fail with -XX:+UseNullableValueFlattening Message-ID: <2b3gq_yMbLBumTSALLTaikiHTCBYBtuqTrVh8DjedtA=.868cc986-c901-435d-bf60-7ee9069dcb15@github.com> Fix handling of offsets for boxing classes. Thanks to Chen Liang and John Rose for their help identifying the root cause of the problem. Fred ------------- Commit messages: - Fix handling of offsets for boxing classes Changes: https://git.openjdk.org/valhalla/pull/1396/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351550 Stats: 62 lines in 2 files changed: 11 ins; 10 del; 41 mod Patch: https://git.openjdk.org/valhalla/pull/1396.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1396/head:pull/1396 PR: https://git.openjdk.org/valhalla/pull/1396 From fparain at openjdk.org Wed Mar 12 19:36:36 2025 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 12 Mar 2025 19:36:36 GMT Subject: [lworld] RFR: 8351550: [lworld] Some bootstrap methods/lambda factories fail with -XX:+UseNullableValueFlattening [v2] In-Reply-To: <2b3gq_yMbLBumTSALLTaikiHTCBYBtuqTrVh8DjedtA=.868cc986-c901-435d-bf60-7ee9069dcb15@github.com> References: <2b3gq_yMbLBumTSALLTaikiHTCBYBtuqTrVh8DjedtA=.868cc986-c901-435d-bf60-7ee9069dcb15@github.com> Message-ID: <81m5Cd361kgUJrlicDfqn4FKAab3evNVgb-sHCXsVHQ=.1702082e-482d-45b0-95b8-a1943403e828@github.com> > Fix handling of offsets for boxing classes. > Thanks to Chen Liang and John Rose for their help identifying the root cause of the problem. > > Fred Frederic Parain 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: - Merge remote-tracking branch 'upstream/lworld' into 8351550 - Fix handling of offsets for boxing classes ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1396/files - new: https://git.openjdk.org/valhalla/pull/1396/files/6e1e9b04..739c6f8a Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1396&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1396&range=00-01 Stats: 24908 lines in 821 files changed: 11029 ins; 9883 del; 3996 mod Patch: https://git.openjdk.org/valhalla/pull/1396.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1396/head:pull/1396 PR: https://git.openjdk.org/valhalla/pull/1396 From fparain at openjdk.org Wed Mar 12 19:36:36 2025 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 12 Mar 2025 19:36:36 GMT Subject: [lworld] Integrated: 8351550: [lworld] Some bootstrap methods/lambda factories fail with -XX:+UseNullableValueFlattening In-Reply-To: <2b3gq_yMbLBumTSALLTaikiHTCBYBtuqTrVh8DjedtA=.868cc986-c901-435d-bf60-7ee9069dcb15@github.com> References: <2b3gq_yMbLBumTSALLTaikiHTCBYBtuqTrVh8DjedtA=.868cc986-c901-435d-bf60-7ee9069dcb15@github.com> Message-ID: On Wed, 12 Mar 2025 17:57:49 GMT, Frederic Parain wrote: > Fix handling of offsets for boxing classes. > Thanks to Chen Liang and John Rose for their help identifying the root cause of the problem. > > Fred This pull request has now been integrated. Changeset: b37178a0 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/b37178a04fe751e6bb9c3c69acdc5345556c429e Stats: 62 lines in 2 files changed: 11 ins; 10 del; 41 mod 8351550: [lworld] Some bootstrap methods/lambda factories fail with -XX:+UseNullableValueFlattening ------------- PR: https://git.openjdk.org/valhalla/pull/1396 From jrose at openjdk.org Wed Mar 12 23:49:06 2025 From: jrose at openjdk.org (John R Rose) Date: Wed, 12 Mar 2025 23:49:06 GMT Subject: [lworld] RFR: 8351550: [lworld] Some bootstrap methods/lambda factories fail with -XX:+UseNullableValueFlattening [v2] In-Reply-To: <81m5Cd361kgUJrlicDfqn4FKAab3evNVgb-sHCXsVHQ=.1702082e-482d-45b0-95b8-a1943403e828@github.com> References: <2b3gq_yMbLBumTSALLTaikiHTCBYBtuqTrVh8DjedtA=.868cc986-c901-435d-bf60-7ee9069dcb15@github.com> <81m5Cd361kgUJrlicDfqn4FKAab3evNVgb-sHCXsVHQ=.1702082e-482d-45b0-95b8-a1943403e828@github.com> Message-ID: On Wed, 12 Mar 2025 19:36:36 GMT, Frederic Parain wrote: >> Fix handling of offsets for boxing classes. >> Thanks to Chen Liang and John Rose for their help identifying the root cause of the problem. >> >> Fred > > Frederic Parain 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: > > - Merge remote-tracking branch 'upstream/lworld' into 8351550 > - Fix handling of offsets for boxing classes Good. As it stands it needs some cleanup when Valhalla is integrated. Put a comment to that effect, something like "when we exit preview, this code must be simplified." I suggested some name changes. I also suggested a deeper cut, a more robust fix that would remember the offset separately for each `T_FOO` type. I would prefer that, but I won't insist, since this code is going to be reworked again. On the other hand, why not fix it in such a way, using a table indexed by `T_FOO`, that no further rework will be necessary? It may be that with a full table-based approach, you won't need to look at the preview flag. src/hotspot/share/classfile/javaClasses.cpp line 3990: > 3988: } > 3989: > 3990: int java_lang_boxing_object::_sub32bits_value_offset; An existing term of art in our code for `sub32bits` is "subword". The `_32` and `_64` are distracting; suggest simply `int` and `long`. That combined with `subword` will make clear enough what is happening. Suggestion: `s/sub32bits/subword/; s/32bits/int/; s/64bits/long/` Also, are we sure the subwords will always be all the same, and the floats and non-floats will correspond? This logic assumes that. I suppose the adjusted asserts will catch any future problems. A fuller fix would be to make a local array indexed by `T_FOO` code, as the VM has in many other places. (The length is `T_VOID`.) Then each offset could be stored in its own place, customized to each `T_FOO` type. Why not move all the way there, and forget about these ad hoc classifications? (But did the existing asserts catch this problem in the first place? If not why not?) ------------- PR Review: https://git.openjdk.org/valhalla/pull/1396#pullrequestreview-2680090553 PR Review Comment: https://git.openjdk.org/valhalla/pull/1396#discussion_r1992436070 From vromero at openjdk.org Thu Mar 13 19:45:41 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 13 Mar 2025 19:45:41 GMT Subject: [lworld] Integrated: 8351951: [lworld] javac should issue an error if a strict instance field has not been initialized before the super invocation In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 18:30:22 GMT, Vicente Romero wrote: > javac is not issuing an error if a strict instance field is not initialized before the super invocation, this PR is fixing this issue This pull request has now been integrated. Changeset: 6488ace9 Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/6488ace96b11f82b9dc17e2b495b268ad65c5f2f Stats: 36 lines in 4 files changed: 28 ins; 2 del; 6 mod 8351951: [lworld] javac should issue an error if a strict instance field has not been initialized before the super invocation ------------- PR: https://git.openjdk.org/valhalla/pull/1398 From vromero at openjdk.org Thu Mar 13 19:45:41 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 13 Mar 2025 19:45:41 GMT Subject: [lworld] Integrated: 8351951: [lworld] javac should issue an error if a strict instance field has not been initialized before the super invocation Message-ID: javac is not issuing an error if a strict instance field is not initialized before the super invocation, this PR is fixing this issue ------------- Commit messages: - Merge branch 'JDK-8351951' of https://github.com/vicente-romero-oracle/valhalla into JDK-8351951 - 8351951: [lworld] javac should issue an error if a strict instance field has not been initialized before the super invocation - 8351951: [lworld] javac should issue an error if a strict instance field has not been initialized before the super invocation Changes: https://git.openjdk.org/valhalla/pull/1398/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1398&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351951 Stats: 36 lines in 4 files changed: 28 ins; 2 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1398.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1398/head:pull/1398 PR: https://git.openjdk.org/valhalla/pull/1398 From thartmann at openjdk.org Fri Mar 14 13:59:45 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 14 Mar 2025 13:59:45 GMT Subject: [lworld] RFR: 8341767: [lworld] JIT support for nullable, atomic, flat arrays Message-ID: C1 and C2 support for the new nullable, atomic, flat arrays (see [JDK-8345995](https://bugs.openjdk.org/browse/JDK-8345995) for runtime). Follow-up work will be done with [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865) and is marked with `// TODO 8350865` in the code. Most complexity is in C2 due to the additional runtime checks and the conversion between scalarized values and atomic accesses. Thanks, Tobias ------------- Commit messages: - More refactoring - Merge branch 'JDK-8341767' of github.com:TobiHartmann/valhalla into JDK-8341767 - Trailing whitespace - Merge branch 'lworld' into JDK-8341767 - Runtime check for atomicity - More refactoring - Fixed last layout test case - Arraycopy fixes - More fixes, refactoring - Merge branch 'lworld' into JDK-8341767 - ... and 21 more: https://git.openjdk.org/valhalla/compare/b37178a0...f1295977 Changes: https://git.openjdk.org/valhalla/pull/1397/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341767 Stats: 2500 lines in 63 files changed: 1874 ins; 335 del; 291 mod Patch: https://git.openjdk.org/valhalla/pull/1397.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1397/head:pull/1397 PR: https://git.openjdk.org/valhalla/pull/1397 From thartmann at openjdk.org Fri Mar 14 14:44:28 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 14 Mar 2025 14:44:28 GMT Subject: [lworld] Integrated: 8341767: [lworld] JIT support for nullable, atomic, flat arrays In-Reply-To: References: Message-ID: On Thu, 13 Mar 2025 07:29:43 GMT, Tobias Hartmann wrote: > C1 and C2 support for the new nullable, atomic, flat arrays (see [JDK-8345995](https://bugs.openjdk.org/browse/JDK-8345995) for runtime). Follow-up work will be done with [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865) and is marked with `// TODO 8350865` in the code. Most complexity is in C2 due to the additional runtime checks and the conversion between scalarized values and atomic accesses. > > Thanks, > Tobias This pull request has now been integrated. Changeset: a0b174f4 Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/a0b174f4cf8166c5eff9c718045b5d3987c5e65c Stats: 2500 lines in 63 files changed: 1874 ins; 335 del; 291 mod 8341767: [lworld] JIT support for nullable, atomic, flat arrays ------------- PR: https://git.openjdk.org/valhalla/pull/1397 From matsaave at openjdk.org Fri Mar 14 16:06:01 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 14 Mar 2025 16:06:01 GMT Subject: [lworld] RFR: 8351979: Improve verification error messages for strict fields Message-ID: This patch adds more detail to the verifier errors throws when there are problems with strict instance fields. The class name and one field name is now printed. Verified with tier 1-3 tests. ------------- Commit messages: - Added detail to error message - 8351979: Improve verification error messages for strict fields Changes: https://git.openjdk.org/valhalla/pull/1400/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351979 Stats: 31 lines in 4 files changed: 28 ins; 0 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1400.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1400/head:pull/1400 PR: https://git.openjdk.org/valhalla/pull/1400 From coleenp at openjdk.org Fri Mar 14 16:17:13 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 14 Mar 2025 16:17:13 GMT Subject: [lworld] RFR: 8351979: Improve verification error messages for strict fields In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 16:00:50 GMT, Matias Saavedra Silva wrote: > This patch adds more detail to the verifier errors throws when there are problems with strict instance fields. The class name and one field name is now printed. Verified with tier 1-3 tests. src/hotspot/share/classfile/stackMapFrame.cpp line 71: > 69: sig->as_C_string(), > 70: klass->name()->as_C_string() > 71: ); I wonder if you need a ResourceMark here. Also, I wonder if you could use a stringStream here and concatenate all the names and signatures of the unset fields? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1400#discussion_r1995860689 From matsaave at openjdk.org Fri Mar 14 16:29:16 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 14 Mar 2025 16:29:16 GMT Subject: [lworld] RFR: 8351979: Improve verification error messages for strict fields In-Reply-To: References: Message-ID: <_8Ctg-eBzkccrXa1usfSW2xKj6LkVLCfuKDyN2m_nds=.a668b22f-f2ef-434b-a6ec-9e7ac66d43fd@github.com> On Fri, 14 Mar 2025 16:14:54 GMT, Coleen Phillimore wrote: >> This patch adds more detail to the verifier errors throws when there are problems with strict instance fields. The class name and one field name is now printed. Verified with tier 1-3 tests. > > src/hotspot/share/classfile/stackMapFrame.cpp line 71: > >> 69: sig->as_C_string(), >> 70: klass->name()->as_C_string() >> 71: ); > > I wonder if you need a ResourceMark here. Also, I wonder if you could use a stringStream here and concatenate all the names and signatures of the unset fields? Placing a ResourceMark here messes with the error message so I opted not to use one. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1400#discussion_r1995879138 From matsaave at openjdk.org Fri Mar 14 17:08:14 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 14 Mar 2025 17:08:14 GMT Subject: [lworld] RFR: 8351979: Improve verification error messages for strict fields In-Reply-To: <_8Ctg-eBzkccrXa1usfSW2xKj6LkVLCfuKDyN2m_nds=.a668b22f-f2ef-434b-a6ec-9e7ac66d43fd@github.com> References: <_8Ctg-eBzkccrXa1usfSW2xKj6LkVLCfuKDyN2m_nds=.a668b22f-f2ef-434b-a6ec-9e7ac66d43fd@github.com> Message-ID: On Fri, 14 Mar 2025 16:26:25 GMT, Matias Saavedra Silva wrote: >> src/hotspot/share/classfile/stackMapFrame.cpp line 71: >> >>> 69: sig->as_C_string(), >>> 70: klass->name()->as_C_string() >>> 71: ); >> >> I wonder if you need a ResourceMark here. Also, I wonder if you could use a stringStream here and concatenate all the names and signatures of the unset fields? > > Placing a ResourceMark here messes with the error message so I opted not to use one. Regarding stringStream, there's a chance that approach would flood the log output in some cases. Although most realistic cases would have a few strict instance fields per class, it is still possible to have a large amount and create a massive error message that could be hard to trace. I think a minimal but descriptive error message is sufficient here and then users can use `-Xlog:verification` for the complete list of fields. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1400#discussion_r1995950614 From coleenp at openjdk.org Fri Mar 14 18:35:20 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 14 Mar 2025 18:35:20 GMT Subject: [lworld] RFR: 8351979: Improve verification error messages for strict fields In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 16:00:50 GMT, Matias Saavedra Silva wrote: > This patch adds more detail to the verifier errors throws when there are problems with strict instance fields. The class name and one field name is now printed. Verified with tier 1-3 tests. This looks good! ------------- Marked as reviewed by coleenp (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1400#pullrequestreview-2686406112 From coleenp at openjdk.org Fri Mar 14 18:35:21 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 14 Mar 2025 18:35:21 GMT Subject: [lworld] RFR: 8351979: Improve verification error messages for strict fields In-Reply-To: References: <_8Ctg-eBzkccrXa1usfSW2xKj6LkVLCfuKDyN2m_nds=.a668b22f-f2ef-434b-a6ec-9e7ac66d43fd@github.com> Message-ID: On Fri, 14 Mar 2025 17:05:17 GMT, Matias Saavedra Silva wrote: >> Placing a ResourceMark here messes with the error message so I opted not to use one. > > Regarding stringStream, there's a chance that approach would flood the log output in some cases. Although most realistic cases would have a few strict instance fields per class, it is still possible to have a large amount and create a massive error message that could be hard to trace. > > I think a minimal but descriptive error message is sufficient here and then users can use `-Xlog:verification` for the complete list of fields. Okay, that makes sense. Also ResourceMarks are tricky in this code since so much is resource allocated. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1400#discussion_r1996043896 From fparain at openjdk.org Fri Mar 14 20:01:44 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 14 Mar 2025 20:01:44 GMT Subject: [lworld] Integrated: Adjustment and new API for VarHandles Message-ID: A few changes related to the work to fix the VarHandles code. The keyword volatile is now a signal to prevent field flattening. A new API in ValueClass allows Java code to query the atomicity characteristics of an array. ------------- Commit messages: - Adjustment and new API for VarHandles Changes: https://git.openjdk.org/valhalla/pull/1401/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1401&range=00 Stats: 162 lines in 8 files changed: 156 ins; 3 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/1401.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1401/head:pull/1401 PR: https://git.openjdk.org/valhalla/pull/1401 From fparain at openjdk.org Fri Mar 14 20:01:45 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 14 Mar 2025 20:01:45 GMT Subject: [lworld] Integrated: Adjustment and new API for VarHandles In-Reply-To: References: Message-ID: <_IyOfZ2UOfLYyuDEh2psGetrXcAxFWzLjyKv9Z69-pg=.dc60c025-abb3-4555-b453-8b7b03e95d40@github.com> On Fri, 14 Mar 2025 19:55:12 GMT, Frederic Parain wrote: > A few changes related to the work to fix the VarHandles code. > The keyword volatile is now a signal to prevent field flattening. > A new API in ValueClass allows Java code to query the atomicity characteristics of an array. This pull request has now been integrated. Changeset: 6c73f22b Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/6c73f22bfe6d10bc2478ed1a765a12137c84c37d Stats: 162 lines in 8 files changed: 156 ins; 3 del; 3 mod Adjustment and new API for VarHandles ------------- PR: https://git.openjdk.org/valhalla/pull/1401 From matsaave at openjdk.org Mon Mar 17 14:30:09 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 17 Mar 2025 14:30:09 GMT Subject: [lworld] RFR: 8351979: Improve verification error messages for strict fields In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 18:07:25 GMT, Coleen Phillimore wrote: >> This patch adds more detail to the verifier errors throws when there are problems with strict instance fields. The class name and one field name is now printed. Verified with tier 1-3 tests. > > This looks good! Thanks for the review @coleenp! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1400#issuecomment-2729718696 From duke at openjdk.org Mon Mar 17 14:30:10 2025 From: duke at openjdk.org (duke) Date: Mon, 17 Mar 2025 14:30:10 GMT Subject: [lworld] RFR: 8351979: Improve verification error messages for strict fields In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 16:00:50 GMT, Matias Saavedra Silva wrote: > This patch adds more detail to the verifier errors throws when there are problems with strict instance fields. The class name and one field name is now printed. Verified with tier 1-3 tests. @matias9927 Your change (at version c31e45d72968ff743efb584f7411b16b0bfe4987) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1400#issuecomment-2729722475 From matsaave at openjdk.org Mon Mar 17 19:13:27 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Mon, 17 Mar 2025 19:13:27 GMT Subject: [lworld] Integrated: 8351979: Improve verification error messages for strict fields In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 16:00:50 GMT, Matias Saavedra Silva wrote: > This patch adds more detail to the verifier errors throws when there are problems with strict instance fields. The class name and one field name is now printed. Verified with tier 1-3 tests. This pull request has now been integrated. Changeset: c394d178 Author: Matias Saavedra Silva Committer: Coleen Phillimore URL: https://git.openjdk.org/valhalla/commit/c394d178cbd6d9fb572334c0a510c6d4cbf16cb6 Stats: 31 lines in 4 files changed: 28 ins; 0 del; 3 mod 8351979: Improve verification error messages for strict fields Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/valhalla/pull/1400 From coleen.phillimore at oracle.com Mon Mar 17 19:37:40 2025 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 17 Mar 2025 15:37:40 -0400 Subject: CFV: New Committer: Matias Saavedra Silva Message-ID: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> I hereby nominate Matias Saavedra Silva [1] to Valhalla Committer. Matias is a member of the HotSpot Runtime Team at Oracle and an OpenJDK Reviewer. He is working on verifier changes for strict fields, and other runtime changes for Valhalla. He has contributed 6 changes to the valhalla repository [3]. Votes are due by March 31, 2025, 13:00 UTC. Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, Coleen Phillimore [1] https://openjdk.java.net/census#matsaave [2] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20matsaave%20and%20fixVersion%20%3D%20repo-valhalla%20 [3] https://openjdk.java.net/census#valhalla [4] https://openjdk.org/projects/#committer-vote From coleen.phillimore at oracle.com Mon Mar 17 19:43:23 2025 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 17 Mar 2025 15:43:23 -0400 Subject: CFV: New Committer: Matias Saavedra Silva In-Reply-To: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> References: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> Message-ID: <9e192b37-333b-4133-b007-31dc94ac9a39@oracle.com> Vote: yes (correction, it's now 8 changes). On 3/17/25 3:37 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Matias Saavedra Silva [1] to Valhalla Committer. > > Matias is a member of the HotSpot Runtime Team at Oracle and an > OpenJDK Reviewer. He is working on verifier changes for strict fields, > and other runtime changes for Valhalla. He has contributed 6 changes > to the valhalla repository [3]. > > Votes are due by March 31, 2025, 13:00 UTC. > > Only current Valhalla Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > Coleen Phillimore > > [1] https://openjdk.java.net/census#matsaave > [2] > https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20matsaave%20and%20fixVersion%20%3D%20repo-valhalla%20 > [3] https://openjdk.java.net/census#valhalla > [4] https://openjdk.org/projects/#committer-vote From lois.foltan at oracle.com Mon Mar 17 20:21:58 2025 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 17 Mar 2025 20:21:58 +0000 Subject: CFV: New Committer: Matias Saavedra Silva In-Reply-To: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> References: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> Message-ID: Vote: yes Lois From: valhalla-dev on behalf of coleen.phillimore at oracle.com Date: Monday, March 17, 2025 at 3:38?PM To: valhalla-dev at openjdk.org Subject: CFV: New Committer: Matias Saavedra Silva I hereby nominate Matias Saavedra Silva [1] to Valhalla Committer. Matias is a member of the HotSpot Runtime Team at Oracle and an OpenJDK Reviewer. He is working on verifier changes for strict fields, and other runtime changes for Valhalla. He has contributed 6 changes to the valhalla repository [3]. Votes are due by March 31, 2025, 13:00 UTC. Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Thanks, Coleen Phillimore [1] https://openjdk.java.net/census#matsaave [2] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20matsaave%20and%20fixVersion%20%3D%20repo-valhalla%20 [3] https://openjdk.java.net/census#valhalla [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Mon Mar 17 20:59:48 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 17 Mar 2025 20:59:48 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v2] In-Reply-To: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: > Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. Chen Liang 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: - Add very primitive super rewrite functionality - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/strict-processor - 8351362: Post-process @Strict annotation for testing ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1395/files - new: https://git.openjdk.org/valhalla/pull/1395/files/bb1fd0dc..30d78fb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1395&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1395&range=00-01 Stats: 2981 lines in 79 files changed: 2268 ins; 351 del; 362 mod Patch: https://git.openjdk.org/valhalla/pull/1395.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1395/head:pull/1395 PR: https://git.openjdk.org/valhalla/pull/1395 From liach at openjdk.org Mon Mar 17 21:25:12 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 17 Mar 2025 21:25:12 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v3] In-Reply-To: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: > Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix a bug and enhance tests ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1395/files - new: https://git.openjdk.org/valhalla/pull/1395/files/30d78fb9..a44c269c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1395&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1395&range=01-02 Stats: 77 lines in 2 files changed: 55 ins; 6 del; 16 mod Patch: https://git.openjdk.org/valhalla/pull/1395.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1395/head:pull/1395 PR: https://git.openjdk.org/valhalla/pull/1395 From liach at openjdk.org Mon Mar 17 21:25:14 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 17 Mar 2025 21:25:14 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v2] In-Reply-To: References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: On Mon, 17 Mar 2025 20:59:48 GMT, Chen Liang wrote: >> Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. > > Chen Liang 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: > > - Add very primitive super rewrite functionality > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/strict-processor > - 8351362: Post-process @Strict annotation for testing Looking to integrate this as I have added all functionalities in the RFE (despite the ctor call relocation being extremely primitive) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1395#issuecomment-2730958216 From duke at openjdk.org Mon Mar 17 21:25:14 2025 From: duke at openjdk.org (duke) Date: Mon, 17 Mar 2025 21:25:14 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v2] In-Reply-To: References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: <3r36XmJwlRe7xAocNA8DOx_MP0l4Vtxdo_aLRh5z6ss=.00c78379-dfe7-407d-bd0d-03b437ae1985@github.com> On Mon, 17 Mar 2025 20:59:48 GMT, Chen Liang wrote: >> Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. > > Chen Liang 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: > > - Add very primitive super rewrite functionality > - Merge branch 'lworld' of https://github.com/openjdk/valhalla into test/strict-processor > - 8351362: Post-process @Strict annotation for testing @liach Your change (at version a44c269c196dc334f76c12faa0bb101aa52365d7) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1395#issuecomment-2730959684 From vicente.romero at oracle.com Tue Mar 18 14:54:47 2025 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 18 Mar 2025 10:54:47 -0400 Subject: CFV: New Committer: Matias Saavedra Silva In-Reply-To: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> References: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> Message-ID: vote: yes Vicente On 3/17/25 15:37, coleen.phillimore at oracle.com wrote: > I hereby nominate Matias Saavedra Silva [1] to Valhalla Committer. > > Matias is a member of the HotSpot Runtime Team at Oracle and an > OpenJDK Reviewer. He is working on verifier changes for strict fields, > and other runtime changes for Valhalla. He has contributed 6 changes > to the valhalla repository [3]. > > Votes are due by March 31, 2025, 13:00 UTC. > > Only current Valhalla Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > Coleen Phillimore > > [1] https://openjdk.java.net/census#matsaave > [2] > https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20matsaave%20and%20fixVersion%20%3D%20repo-valhalla%20 > [3] https://openjdk.java.net/census#valhalla > [4] https://openjdk.org/projects/#committer-vote From roger.riggs at oracle.com Tue Mar 18 15:34:47 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 18 Mar 2025 11:34:47 -0400 Subject: CFV: New Committer: Matias Saavedra Silva In-Reply-To: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> References: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> Message-ID: <64f3fa19-72ac-4bea-99cc-79b550b921c4@oracle.com> Vote: Yes On 3/17/25 3:37 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Matias Saavedra Silva [1] to Valhalla Committer. From rriggs at openjdk.org Tue Mar 18 19:49:28 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 18 Mar 2025 19:49:28 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v3] In-Reply-To: References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: On Mon, 17 Mar 2025 21:25:12 GMT, Chen Liang wrote: >> Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix a bug and enhance tests test/lib/jdk/test/lib/value/Strict.java line 1: > 1: /* Can we use import `jdk.internal.vm.annotation.Strict` and not introduce a duplicate annotation? This code is already `using jdk.internal.vm.annotation.NullRestricted`. And/or add a comment here indicating it is an intentional duplication. test/lib/jdk/test/lib/value/StrictCompiler.java line 61: > 59: > 60: /** > 61: * @param args source and destination The arguments should be documented. Typically, command options like --enable-preview come before file (.java) file arguments. The parsing below seems to have this reversed. The only args that come after -- are file names that might otherwise be confused with options. (Nothing in this case). --enable-preview and --source should be handled like --deferSuperCall `--source` should have its own arg saved and propagated (like javac). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1395#discussion_r2001839438 PR Review Comment: https://git.openjdk.org/valhalla/pull/1395#discussion_r2001856813 From liach at openjdk.org Tue Mar 18 20:08:23 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 18 Mar 2025 20:08:23 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v3] In-Reply-To: References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: <-llSIYMQt-QGD9xrH5-m4J_ikBpTIaVpqMEFMgISwUY=.52e173e1-42b2-40de-91cf-b7ed7c5d7a3c@github.com> On Tue, 18 Mar 2025 19:24:33 GMT, Roger Riggs wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix a bug and enhance tests > > test/lib/jdk/test/lib/value/Strict.java line 1: > >> 1: /* > > Can we use import `jdk.internal.vm.annotation.Strict` and not introduce a duplicate annotation? > This code is already `using jdk.internal.vm.annotation.NullRestricted`. > > And/or add a comment here indicating it is an intentional duplication. @dansmithcode aims to migrate all usages of the internal strict to this test-specific strict. This is actually the reason behind this PR - annotations in the Java Language must not change program semantics. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1395#discussion_r2001899755 From rriggs at openjdk.org Tue Mar 18 20:15:17 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 18 Mar 2025 20:15:17 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v3] In-Reply-To: <-llSIYMQt-QGD9xrH5-m4J_ikBpTIaVpqMEFMgISwUY=.52e173e1-42b2-40de-91cf-b7ed7c5d7a3c@github.com> References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> <-llSIYMQt-QGD9xrH5-m4J_ikBpTIaVpqMEFMgISwUY=.52e173e1-42b2-40de-91cf-b7ed7c5d7a3c@github.com> Message-ID: On Tue, 18 Mar 2025 20:05:46 GMT, Chen Liang wrote: >> test/lib/jdk/test/lib/value/Strict.java line 1: >> >>> 1: /* >> >> Can we use import `jdk.internal.vm.annotation.Strict` and not introduce a duplicate annotation? >> This code is already `using jdk.internal.vm.annotation.NullRestricted`. >> >> And/or add a comment here indicating it is an intentional duplication. > > @dansmithcode aims to migrate all usages of the internal strict to this test-specific strict. This is actually the reason behind this PR - annotations in the Java Language must not change program semantics. That would then apply to NullRestricted also? That seems like an unnecessary split, since Strict is an internal annotation, it doesn't matter whether it is declared in a test specific library or jdk.internal.value. and it make maintenance harder because they are split. And it makes prototyping uses of Strict more difficult. And not defined or specified anywhere. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1395#discussion_r2001909724 From dlsmith at openjdk.org Wed Mar 19 01:25:28 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 19 Mar 2025 01:25:28 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v3] In-Reply-To: References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> Message-ID: On Mon, 17 Mar 2025 21:25:12 GMT, Chen Liang wrote: >> Added a test tool to strictify files and migrated the existing StrictFinalInstanceFieldsTest as an example. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Fix a bug and enhance tests I would not recommend integrating until https://github.com/openjdk/valhalla/pull/1389 is done. At that point, there will be a large number of tests to experiment with, and after seeing if/how conveniently they can be updated to adopt this tool, we can then have a conversation with the rest of the team about whether this is a good solution going forward, or whether there are still concerns about this not being built into javac. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1395#issuecomment-2735076497 From dlsmith at openjdk.org Wed Mar 19 01:25:28 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 19 Mar 2025 01:25:28 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v3] In-Reply-To: References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> <-llSIYMQt-QGD9xrH5-m4J_ikBpTIaVpqMEFMgISwUY=.52e173e1-42b2-40de-91cf-b7ed7c5d7a3c@github.com> Message-ID: On Tue, 18 Mar 2025 20:10:48 GMT, Roger Riggs wrote: >> @dansmithcode aims to migrate all usages of the internal strict to this test-specific strict. This is actually the reason behind this PR - annotations in the Java Language must not change program semantics. > > That would then apply to NullRestricted also? > That seems like an unnecessary split, since Strict is an internal annotation, it doesn't matter whether it is declared in a test specific library or jdk.internal.value. and it make maintenance harder because they are split. > And it makes prototyping uses of Strict more difficult. > And not defined or specified anywhere. The idea is that the `@Strict` annotation should live next to the tool that interprets it. If we decide we need a translation tool in `jdk.internal`, then putting `@Strict` there too makes sense. If this is purely a test-writing tool, then `@Strict` belongs in tests. `@NullRestricted` is interpret by the JVM, so it makes sense that it lives in the JVM's internal API. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1395#discussion_r2002236160 From tobias.hartmann at oracle.com Wed Mar 19 07:37:54 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 19 Mar 2025 08:37:54 +0100 Subject: CFV: New Committer: Matias Saavedra Silva In-Reply-To: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> References: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> Message-ID: <8a6956a4-a13b-485b-a2ad-746c79df2802@oracle.com> Vote: yes Best regards, Tobias On 3/17/25 20:37, coleen.phillimore at oracle.com wrote: > I hereby nominate Matias Saavedra Silva [1] to Valhalla Committer. > > Matias is a member of the HotSpot Runtime Team at Oracle and an OpenJDK Reviewer. He is working on verifier changes for strict fields, and other runtime changes for Valhalla. He has contributed 6 changes to the valhalla repository [3]. > > Votes are due by March 31, 2025, 13:00 UTC. > > Only current Valhalla Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > Coleen Phillimore > > [1] https://openjdk.java.net/census#matsaave > [2] https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20matsaave%20and%20fixVersion%20%3D%20repo-valhalla%20 > [3] https://openjdk.java.net/census#valhalla > [4] https://openjdk.org/projects/#committer-vote From rriggs at openjdk.org Wed Mar 19 14:23:22 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 19 Mar 2025 14:23:22 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v3] In-Reply-To: References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> <-llSIYMQt-QGD9xrH5-m4J_ikBpTIaVpqMEFMgISwUY=.52e173e1-42b2-40de-91cf-b7ed7c5d7a3c@github.com> Message-ID: <7Z_MqQ_7cUQ9Z8Hjr5buuWJkZv8AwAbWmqibfu0habk=.c32d2a31-f0fd-41e9-97d0-1263012a7531@github.com> On Wed, 19 Mar 2025 01:20:48 GMT, Dan Smith wrote: >> That would then apply to NullRestricted also? >> That seems like an unnecessary split, since Strict is an internal annotation, it doesn't matter whether it is declared in a test specific library or jdk.internal.value. and it make maintenance harder because they are split. >> And it makes prototyping uses of Strict more difficult. >> And not defined or specified anywhere. > > The idea is that the `@Strict` annotation should live next to the tool that interprets it. > > If we decide we need a translation tool in `jdk.internal`, then putting `@Strict` there too makes sense. If this is purely a test-writing tool, then `@Strict` belongs in tests. > > `@NullRestricted` is interpret by the JVM, so it makes sense that it lives in the JVM's internal API. It has been said that in tests every NullRestricted annotated element should also have @Strict. Since @Strict is there only for test generation; would it be simpler to have the tool look for NullRestricted and do the right thing; avoiding both excessive editing of tests and parallel but dependent annotations. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1395#discussion_r2003452226 From dlsmith at openjdk.org Wed Mar 19 16:04:27 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 19 Mar 2025 16:04:27 GMT Subject: [lworld] RFR: 8351362: Post-process @Strict annotation for testing [v3] In-Reply-To: <7Z_MqQ_7cUQ9Z8Hjr5buuWJkZv8AwAbWmqibfu0habk=.c32d2a31-f0fd-41e9-97d0-1263012a7531@github.com> References: <3so8x8XfM8haO8SCPqUpb-Abg0lgzle4_OWZJkZoEVM=.74e40e6c-28b2-4780-b55b-d54f5f4b38fa@github.com> <-llSIYMQt-QGD9xrH5-m4J_ikBpTIaVpqMEFMgISwUY=.52e173e1-42b2-40de-91cf-b7ed7c5d7a3c@github.com> <7Z_MqQ_7cUQ9Z8Hjr5buuWJkZv8AwAbWmqibfu0habk=.c32d2a31-f0fd-41e9-97d0-1263012a7531@github.com> Message-ID: On Wed, 19 Mar 2025 14:20:44 GMT, Roger Riggs wrote: >> The idea is that the `@Strict` annotation should live next to the tool that interprets it. >> >> If we decide we need a translation tool in `jdk.internal`, then putting `@Strict` there too makes sense. If this is purely a test-writing tool, then `@Strict` belongs in tests. >> >> `@NullRestricted` is interpret by the JVM, so it makes sense that it lives in the JVM's internal API. > > It has been said that in tests every NullRestricted annotated element should also have @Strict. > Since @Strict is there only for test generation; would it be simpler to have the tool look for NullRestricted and do the right thing; avoiding both excessive editing of tests and parallel but dependent annotations. Possibly, yes. The trade-off is then it's harder or confusing to write tests of validation behavior?when you explicitly want a class file that has `@NullRestricted` but not ACC_STRICT. Maybe that's a corner case we can deal with though. It also obscures the dependency on the translation tool (importing the test library is a helpful signal that you intend to use the translation tool). But, sure, that's a possible enhancement. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1395#discussion_r2003711045 From duke at openjdk.org Thu Mar 20 08:21:18 2025 From: duke at openjdk.org (Andrew Byrd) Date: Thu, 20 Mar 2025 08:21:18 GMT Subject: [valhalla-docs] RFR: Add Brian Goetz presentation from July 2024 In-Reply-To: References: Message-ID: <1N8DbQDDRp95JDiEectt32i6rcpBAhRT1hlJwzj9qv8=.199956cc-900b-45d9-a3fc-cdfcf22e7e48@github.com> On Tue, 18 Feb 2025 15:33:14 GMT, Andrew Byrd wrote: > Looking into the present state of project Valhalla, I found a very good presentation from July of 2024 at https://inside.java/tag/valhalla that was not listed on the page at https://openjdk.org/projects/valhalla/ but seems to fit well alongside the other presentations listed there. > > I updated the page to include this presentation from Brian Goetz. I also sorted the presentations in reverse chronological order, as some of the information in this 2024 presentation seems to supersede previous ones. This is a minor documentation change intended only to ensure the public can readily find the clearest and most recent information on project Valhalla. I do not have a particular sponsor / Committer in mind. Hopefully someone with the appropriate permissions can verify that the link leads to a valuable and authoritative source of information on the current state of the project. ------------- PR Comment: https://git.openjdk.org/valhalla-docs/pull/14#issuecomment-2739539341 From mcimadamore at openjdk.org Thu Mar 20 10:55:18 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 10:55:18 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles Message-ID: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. ------------- Commit messages: - Remove redundant import - Fix missing fence in `putFlatValueVolatile` - Make atomic var handle support depend on user-visible properties - Refactor flat value var handle implementation - Reintroduce assertion that static fields can't be flat - Initial push Changes: https://git.openjdk.org/valhalla/pull/1402/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351569 Stats: 766 lines in 8 files changed: 556 ins; 71 del; 139 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From mcimadamore at openjdk.org Thu Mar 20 10:55:19 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 10:55:19 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Wed, 19 Mar 2025 18:31:27 GMT, Maurizio Cimadamore wrote: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. #### Problem The VM has [several](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/oops/layoutKind.hpp#L28) different flat layouts to pick from. Some layouts support atomic load/stores (but require the value payload, including the null channel -- where present -- to fit in 64 bits) -- we call these layouts *atomic layouts*. Others do not. When value fields/array elements are accessed through the VarHandle API, a question arises: under which conditions can the API support the various access modes provided by the API? Should all access modes be available, regardless of the JVM layout? Or should non-plain access modes only be supported by atomic JVM layouts? The current implementation attempts to do the former -- all access modes are supported all the time. This is done by surrounding atomic operations such as CAS with a `synchronized` block. While this strategy is good for prototyping, it is not efficient, and only works correctly _as long as all the accesses_ occur via the `synchronized `block. For instance, if CAS code is mixed with plain access, the CAS code might observe a torn read -- which seems bad. #### Solution The VarHandle API should only provide access to non-plain access mode if either a layout is non-flat, or if the layout is flat and *atomic*. In the former case, we can implement access using `Unsafe`'s reference access primitives. In the latter case we can implement access using a combination of `Unsafe::getFlatValue`, memory barriers (for non-plain access modes such as acquire, or volatile) and weak CAS loops. In other words, by limiting support to atomic flat layouts, no `synchronized` block is ever required. One important design consideration is that we want the set of access modes supported by a `VarHandle` to be *stable* and *predictable*. That is, given that there are many factors influencing which JVM layout is picked for a field or an array element, how do user knows if a CAS operation is going to fail or not? To provide for more stability I've opted for a simple rule: a field var handle supports atomic operations if either * it is declared `volatile` * its type is nullable * the field type is not a `@WeaklyConsistent` class For arrays, things are more convoluted: as arrays are covariant, it is always possible to create an array for `Object[].class` but then use it against a flat array. In such cases some dynamic dispatch is unavoidable: the array var handle code has to detect covariant cases, and switch to a "sharper" var handle that models the accessed array. An accessed array instance supports atomic operations if either: * `ValueClass::isAtomicArray` returns true for the accessed array * `ValueClass::isNullRestrictedArray` returns false for the accessed array * the component type of the accessed array is not a `@WeaklyConsistent` class (Note the above rules mean that var handles targeting migrated value class in [JEP 401](https://openjdk.org/jeps/401) will, by definition, support all access modes -- as all uses of such classes will be through nullable types). #### Changes In the code this PR replaces, there are two `VarHandle` implementation classes, namely `VarHandleReferences` and `VarHandleFlatValues`. These classes support _all_ access modes -- one is used for non-flat values, the other is used for flat values. This first change is to refine the implementation classes so that we can support **four** cases: * flat values that support non-plain access modes (`VarHandleFlatValues`) * flat values that do not support non-plain access modes (`VarHandleNonAtomicFlatValues`) * non-flat values that support non-plain access modes (`VarHandleReferences`) * non-flat values that do not support non-plain access modes (`VarHandleNonAtomicReferences`) The `VarHandles::makeFieldVarHandle/makeStaticFieldVarHandle` is then updated so that the correct var handle is returned, based on the characteristics of the field. As mentioned above, for `VarHandles::makeArrayElementHandle` our strategy is to _always_ create an indirect var handle that supports all access modes (`VarHandleReferences`) -- and then delegate the check at runtime (once we know the array we are operating on). The logic to select a sharp var handle based on the dynamic array instance is in `VarHandles::flatArrayElementHandleFor`. The decision of whether a given field or array should support non-plain operation is defined in the `VarHandles::isAtomicFlat`predicates (there's one for fields and one for arrays). The logic there follows what discussed above, with one exception: we only treat as atomic value types that have no object pointers in them. This is due to a technical limitation in the `Unsafe` support for the atomic operations (like CAS), where we can turn a flat value CAS into a numeric CAS only as long as the value payload doesn't contain objects (this restrictions prevents us from accidentally updating an object pointer without notifying the GC). While this restriction shouldn't be viewed as permanent, supporting CAS operations on flat values with pointers is a separate challenge that will not be addressed by this PR. This PR updates most of the non-plain access primitives for flat values in the `Unsafe` class. Atomic operations are now implemented using weak CAS loops. We needed to perform some heroics to turn a value payload into a numeric value (a `byte`, a `short` an `int` or a `long`), so that we can turn a flat value CAS into a numeric CAS -- this logic is in `Unsafe::compareAndSetFlatValueAsBytes`. Non-plain, non-atomic access (e.g. opaque, acquire/release, volatile) are implemented in terms of plain access, with extra barriers -- as described in this [document](https://gee.cs.oswego.edu/dl/html/j9mm.html). This allows us to implement all the access modes on atomic flat layouts in Java. It is possible that, in the future, some (or all) of these methods will turn into JVM intrinsics which will allow to avoid some of the workarounds described here. Finally, note that even some atomic operations involving reference types have been updated as well -- when a value type is passed to a reference CAS, we need to perform CAS in a way so that it uses the correct definition of `==` (e.g. not pointer comparison). Before this PR this was done, again, with a monitor. All monitor code is now gone. #### Testing The main new test added here is `FlatVarHandleTest` -- this checks that field and array element var handles support the expected access modes. This test doesn't focus on whether the _implementation_ of the access primitive is correct -- only on whether the access mode is supported or not. An existing test (`NullRestrictedArraysTest`) has been augmented to test the correctness of the various non-plain mode accesses. Some test cases in one JVM test (`TestIntrinsics`) had to be disabled: this test expects calls to atomic operations on flat values to always work -- regardless of whether such flat values feature an atomic layout or not. This is incorrect, as the new `Unsafe` primitives only work with atomic flat layouts (as we need to be able to turn a value layout into a numeric value). src/java.base/share/classes/java/lang/invoke/VarHandles.java line 77: > 75: : new VarHandleReferences.FieldInstanceReadWrite(refc, foffset, type, f.getCheckedFieldType())); > 76: } else { > 77: return maybeAdapt(f.isFinal() && !isWriteAllowedOnFinalFields While this case is not terribly important (typically, if something is non-flat, then it will be "atomic" from a programming model perspective), there are various JVM flags that can affect whether something is flattened or not. It's important here that we don't return a var handles that "overpromises" and support more access modes (just because we know that, underneath, we can use reference `Unsafe` primitives) as such behavior might not be stable, ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1402#issuecomment-2737711409 PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2005271860 From mcimadamore at openjdk.org Thu Mar 20 11:14:20 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 11:14:20 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: <-4BkbOKNPx7aLnDIRhH1J3JYlaYEFKnePu5EK2me8d4=.168fe7db-3d77-49b8-a442-d51eb20e0f78@github.com> On Wed, 19 Mar 2025 18:31:27 GMT, Maurizio Cimadamore wrote: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. src/java.base/share/classes/java/lang/invoke/VarHandles.java line 311: > 309: // do not check for atomicity now -- atomicity will be checked on the accessed array object > 310: // a sharper var handle will be obtained (dynamically) from flatArrayElementHandleFor(Object) > 311: return maybeAdapt(new VarHandleReferences.Array(aoffset, ashift, arrayClass)); Note: this works because: * the reference Array plain access uses array syntax (which works no matter the array passed in) * non-plain access modes always delegate to sharper var handles based on the type of the accessed array ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2005363221 From mcimadamore at openjdk.org Thu Mar 20 11:18:27 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 11:18:27 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles In-Reply-To: <-4BkbOKNPx7aLnDIRhH1J3JYlaYEFKnePu5EK2me8d4=.168fe7db-3d77-49b8-a442-d51eb20e0f78@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> <-4BkbOKNPx7aLnDIRhH1J3JYlaYEFKnePu5EK2me8d4=.168fe7db-3d77-49b8-a442-d51eb20e0f78@github.com> Message-ID: On Thu, 20 Mar 2025 11:11:40 GMT, Maurizio Cimadamore wrote: >> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. > > src/java.base/share/classes/java/lang/invoke/VarHandles.java line 311: > >> 309: // do not check for atomicity now -- atomicity will be checked on the accessed array object >> 310: // a sharper var handle will be obtained (dynamically) from flatArrayElementHandleFor(Object) >> 311: return maybeAdapt(new VarHandleReferences.Array(aoffset, ashift, arrayClass)); > > Note: this works because: > * the reference Array plain access uses array syntax (which works no matter the array passed in) > * non-plain access modes always delegate to sharper var handles based on the type of the accessed array Another note: at the language level there's no mechanism to obtain a class mirror for a null-restricted, or atomic array. This means we can't really create an array var handle that works only on one array shape (which would allow us to eliminate the dynamic dispatch completely, at least for some array var handles). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2005370591 From mcimadamore at openjdk.org Thu Mar 20 14:08:42 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 14:08:42 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v2] In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Enhance compareAndSetFlatValueAsBytes to work on different kinds of flat arrays Cache result of oop-free analysis Beef up tests to check different combinations of VM flags ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1402/files - new: https://git.openjdk.org/valhalla/pull/1402/files/856cb9a0..8ca6bef1 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=00-01 Stats: 29 lines in 4 files changed: 13 ins; 1 del; 15 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From mcimadamore at openjdk.org Thu Mar 20 14:08:43 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 14:08:43 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v2] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Thu, 20 Mar 2025 14:06:02 GMT, Maurizio Cimadamore wrote: >> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Enhance compareAndSetFlatValueAsBytes to work on different kinds of flat arrays > Cache result of oop-free analysis > Beef up tests to check different combinations of VM flags src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2851: > 2849: Object expectedArray = ValueClass.newNullableAtomicArray(valueType, 1); > 2850: Object xArray = ValueClass.newNullableAtomicArray(valueType, 1); > 2851: if (arrayLayout(expectedArray.getClass()) != layout) { This part feels a bit dirty: we are receiving a request for layout X - we need to be able to create an array with _that same layout_ -- but there's no primitive for doing that. Which means I have to try using different factories and make sure that I get something compatible (which isn't always guaranteed because of VM flags). All this guesswork should not be necessary -- that is, there should be an unsafe API to create an array with the layout I want (assuming that layout is supported of course) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2005727171 From mcimadamore at openjdk.org Thu Mar 20 14:13:27 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 14:13:27 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v2] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Thu, 20 Mar 2025 14:06:02 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Enhance compareAndSetFlatValueAsBytes to work on different kinds of flat arrays >> Cache result of oop-free analysis >> Beef up tests to check different combinations of VM flags > > src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2851: > >> 2849: Object expectedArray = ValueClass.newNullableAtomicArray(valueType, 1); >> 2850: Object xArray = ValueClass.newNullableAtomicArray(valueType, 1); >> 2851: if (arrayLayout(expectedArray.getClass()) != layout) { > > This part feels a bit dirty: we are receiving a request for layout X - we need to be able to create an array with _that same layout_ -- but there's no primitive for doing that. Which means I have to try using different factories and make sure that I get something compatible (which isn't always guaranteed because of VM flags). All this guesswork should not be necessary -- that is, there should be an unsafe API to create an array with the layout I want (assuming that layout is supported of course) I have considered avoiding the array creation -- but that is messy because it means you have to deal with nulls directly. E.g. if either `expected` or `x` are `null`, what is their corresponding numeric configuration? Going through an array element allows the code to remain agnostic as to how nulls are represented. Another way to avoid array creation would be to have some way to unsafely get the payload of a value as a long, including null channel and everything. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2005731807 From mcimadamore at openjdk.org Thu Mar 20 16:40:03 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 16:40:03 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v3] In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix test header ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1402/files - new: https://git.openjdk.org/valhalla/pull/1402/files/8ca6bef1..1cd81764 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From mcimadamore at openjdk.org Thu Mar 20 17:59:03 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 17:59:03 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v4] In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Avoid dynamic var handle creation in the middle of array element access ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1402/files - new: https://git.openjdk.org/valhalla/pull/1402/files/1cd81764..70af9a2c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=02-03 Stats: 247 lines in 6 files changed: 142 ins; 30 del; 75 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From mcimadamore at openjdk.org Thu Mar 20 18:05:21 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 18:05:21 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v4] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Thu, 20 Mar 2025 17:59:03 GMT, Maurizio Cimadamore wrote: >> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Avoid dynamic var handle creation in the middle of array element access test/jdk/valhalla/valuetypes/NullRestrictedArraysTest.java line 304: > 302: // test atomic set with null witness > 303: > 304: assertFalse(vh.compareAndSet(array, 2, null, value1)); I realized that the VH code we have is liberal w.r.t. `null` witness values in CAS-like operations -- in the sense that it allows them, even though the underlying variable is null-restricted. For now I decided to preserve this behavior (instead e.g. throwing an IAE) - but better add a test :-) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2006183430 From mcimadamore at openjdk.org Thu Mar 20 18:21:59 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 18:21:59 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v5] In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tighten the signature of VarHandles::checkAtomicFlatArray ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1402/files - new: https://git.openjdk.org/valhalla/pull/1402/files/70af9a2c..0e2eff2e Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=04 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=03-04 Stats: 19 lines in 2 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From mcimadamore at openjdk.org Thu Mar 20 18:26:20 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 20 Mar 2025 18:26:20 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v5] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Thu, 20 Mar 2025 18:21:59 GMT, Maurizio Cimadamore wrote: >> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tighten the signature of VarHandles::checkAtomicFlatArray make/modules/java.base/gensrc/GensrcVarHandles.gmk line 42: > 40: define GenerateVarHandle > 41: > 42: $1_InputType := $2 We need to do a bit of trickery here. Basically we have two pair of input values, which should use the _same_ unsafe access primitives: * Reference, NonAtomicReference -> get/putReference * FlatValue, NonAtomicFlatValue -> get/putFlatValue So, we now use `InputType` to model the input type to the template, and from there we derive `Type` (which is really the Unsafe access type). There's also some other changes: * Not all generated classes need non-plain operations (e.g. NonAtomicReference, NonAtomicFlatValue do not) * Not all generated classes need to handle static fields (e.g. FlatValues and NonAtomicFlatValues do not, as static fields are never flattened) * Not all generated classes need to deal with arrays (e.g. FlatValues and NonAtomicFlatValues do not -- access to value arrays is always handled in the Reference impl class) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2006216567 From fparain at openjdk.org Fri Mar 21 14:24:30 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 21 Mar 2025 14:24:30 GMT Subject: [lworld] RFR: 8351550: [lworld] Some bootstrap methods/lambda factories fail with -XX:+UseNullableValueFlattening [v2] In-Reply-To: References: <2b3gq_yMbLBumTSALLTaikiHTCBYBtuqTrVh8DjedtA=.868cc986-c901-435d-bf60-7ee9069dcb15@github.com> <81m5Cd361kgUJrlicDfqn4FKAab3evNVgb-sHCXsVHQ=.1702082e-482d-45b0-95b8-a1943403e828@github.com> Message-ID: On Wed, 12 Mar 2025 23:38:28 GMT, John R Rose wrote: >> Frederic Parain 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: >> >> - Merge remote-tracking branch 'upstream/lworld' into 8351550 >> - Fix handling of offsets for boxing classes > > src/hotspot/share/classfile/javaClasses.cpp line 3990: > >> 3988: } >> 3989: >> 3990: int java_lang_boxing_object::_sub32bits_value_offset; > > An existing term of art in our code for `sub32bits` is "subword". > The `_32` and `_64` are distracting; suggest simply `int` and `long`. > That combined with `subword` will make clear enough what is happening. > Suggestion: `s/sub32bits/subword/; s/32bits/int/; s/64bits/long/` > > Also, are we sure the subwords will always be all the same, and the floats and non-floats will correspond? This logic assumes that. I suppose the adjusted asserts will catch any future problems. > > A fuller fix would be to make a local array indexed by `T_FOO` code, as the VM has in many other places. (The length is `T_VOID`.) Then each offset could be stored in its own place, customized to each `T_FOO` type. Why not move all the way there, and forget about these ad hoc classifications? > > (But did the existing asserts catch this problem in the first place? If not why not?) I've hesitated getting rid of the classification and doing the check for each wrapper class individually, but I was wondering why it was implemented that way initially, and that I might be missing something. But I agree it would be a much cleaner and robust fix. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1396#discussion_r2007692600 From fparain at openjdk.org Fri Mar 21 14:37:38 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 21 Mar 2025 14:37:38 GMT Subject: [lworld] RFR: 8352613: [lworld] New Unsafe API for special array creation needed by VarHandle Message-ID: New Unsafe API to help the implementation of VarHandle's CAS operations on flat values. ------------- Commit messages: - New Unsafe API for special array creation Changes: https://git.openjdk.org/valhalla/pull/1404/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1404&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352613 Stats: 130 lines in 3 files changed: 130 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1404.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1404/head:pull/1404 PR: https://git.openjdk.org/valhalla/pull/1404 From mcimadamore at openjdk.org Fri Mar 21 14:55:24 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 14:55:24 GMT Subject: [lworld] RFR: 8352613: [lworld] New Unsafe API for special array creation needed by VarHandle In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 14:32:23 GMT, Frederic Parain wrote: > New Unsafe API to help the implementation of VarHandle's CAS operations on flat values. src/hotspot/share/prims/unsafe.cpp line 409: > 407: } UNSAFE_END > 408: > 409: UNSAFE_ENTRY(jarray, Unsafe_NewSpecialArray(JNIEnv *env, jobject unsafe, jclass elmClass, jint len, jint layoutKind)) { Should it be called newFlatArray? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1404#discussion_r2007752774 From mcimadamore at openjdk.org Fri Mar 21 15:02:26 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 15:02:26 GMT Subject: [lworld] RFR: 8352613: [lworld] New Unsafe API for special array creation needed by VarHandle In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 14:32:23 GMT, Frederic Parain wrote: > New Unsafe API to help the implementation of VarHandle's CAS operations on flat values. Looks good - thanks! ------------- Marked as reviewed by mcimadamore (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1404#pullrequestreview-2706269425 From liach at openjdk.org Fri Mar 21 15:26:21 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 15:26:21 GMT Subject: [lworld] RFR: 8352613: [lworld] New Unsafe API for special array creation needed by VarHandle In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 14:52:15 GMT, Maurizio Cimadamore wrote: >> New Unsafe API to help the implementation of VarHandle's CAS operations on flat values. > > src/hotspot/share/prims/unsafe.cpp line 409: > >> 407: } UNSAFE_END >> 408: >> 409: UNSAFE_ENTRY(jarray, Unsafe_NewSpecialArray(JNIEnv *env, jobject unsafe, jclass elmClass, jint len, jint layoutKind)) { > > Should it be called newFlatArray? Indeed, this rejects `LayoutKind::REFERENCE` ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1404#discussion_r2007818916 From liach at openjdk.org Fri Mar 21 15:39:31 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 15:39:31 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v5] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: <_cJy_5VwKgX0TYeBFKCuI8lEXKlmv295AJ5SAIGmLas=.e0445bcc-2d3a-4576-9bf4-b5695b0427ee@github.com> On Thu, 20 Mar 2025 18:21:59 GMT, Maurizio Cimadamore wrote: >> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tighten the signature of VarHandles::checkAtomicFlatArray src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2735: > 2733: @ForceInline > 2734: public final Object getFlatValueOpaque(Object o, long offset, int layout, Class valueType) { > 2735: // this is stronger that opaque semantics Suggestion: // this is stronger than opaque semantics src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2735: > 2733: @ForceInline > 2734: public final Object getFlatValueOpaque(Object o, long offset, int layout, Class valueType) { > 2735: // this is stronger that opaque semantics Suggestion: // this is stronger than opaque semantics src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2795: > 2793: @ForceInline > 2794: public final void putFlatValueOpaque(Object o, long offset, int layout, Class valueType, V x) { > 2795: // this is stronger that opaque semantics Suggestion: // this is stronger than opaque semantics src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2795: > 2793: @ForceInline > 2794: public final void putFlatValueOpaque(Object o, long offset, int layout, Class valueType, V x) { > 2795: // this is stronger that opaque semantics Suggestion: // this is stronger than opaque semantics src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3286: > 3284: } > 3285: > 3286: public Object getAndSetFlatValue(Object o, long offset, int layoutKind, Class valueType, Object newValue) { Why no more `@ForceInline`? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2007837918 PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2007838405 PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2007838080 PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2007838571 PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2007840859 From liach at openjdk.org Fri Mar 21 15:39:32 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 15:39:32 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v2] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Thu, 20 Mar 2025 14:08:23 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2851: >> >>> 2849: Object expectedArray = ValueClass.newNullableAtomicArray(valueType, 1); >>> 2850: Object xArray = ValueClass.newNullableAtomicArray(valueType, 1); >>> 2851: if (arrayLayout(expectedArray.getClass()) != layout) { >> >> This part feels a bit dirty: we are receiving a request for layout X - we need to be able to create an array with _that same layout_ -- but there's no primitive for doing that. Which means I have to try using different factories and make sure that I get something compatible (which isn't always guaranteed because of VM flags). All this guesswork should not be necessary -- that is, there should be an unsafe API to create an array with the layout I want (assuming that layout is supported of course) > > I have considered avoiding the array creation -- but that is messy because it means you have to deal with nulls directly. E.g. if either `expected` or `x` are `null`, what is their corresponding numeric configuration? Going through an array element allows the code to remain agnostic as to how nulls are represented. Another way to avoid array creation would be to have some way to unsafely get the payload of a value as a long, including null channel and everything. I think runtime support is better for down the road for this part. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2007839964 From mcimadamore at openjdk.org Fri Mar 21 16:17:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 16:17:51 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v6] In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java Co-authored-by: Chen Liang - Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1402/files - new: https://git.openjdk.org/valhalla/pull/1402/files/0e2eff2e..7ddd5493 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=05 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From mcimadamore at openjdk.org Fri Mar 21 16:17:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 16:17:51 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v2] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Fri, 21 Mar 2025 15:35:37 GMT, Chen Liang wrote: >> I have considered avoiding the array creation -- but that is messy because it means you have to deal with nulls directly. E.g. if either `expected` or `x` are `null`, what is their corresponding numeric configuration? Going through an array element allows the code to remain agnostic as to how nulls are represented. Another way to avoid array creation would be to have some way to unsafely get the payload of a value as a long, including null channel and everything. > > I think runtime support is better for down the road for this part. We have decided to address this by adding a primitive to create a flat array with given known layout: https://github.com/openjdk/valhalla/pull/1404 Once that API is integrated, I will rebase this PR on top of that. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2007902690 From mcimadamore at openjdk.org Fri Mar 21 16:17:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 16:17:51 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v5] In-Reply-To: <_cJy_5VwKgX0TYeBFKCuI8lEXKlmv295AJ5SAIGmLas=.e0445bcc-2d3a-4576-9bf4-b5695b0427ee@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> <_cJy_5VwKgX0TYeBFKCuI8lEXKlmv295AJ5SAIGmLas=.e0445bcc-2d3a-4576-9bf4-b5695b0427ee@github.com> Message-ID: On Fri, 21 Mar 2025 15:36:09 GMT, Chen Liang wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Tighten the signature of VarHandles::checkAtomicFlatArray > > src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3286: > >> 3284: } >> 3285: >> 3286: public Object getAndSetFlatValue(Object o, long offset, int layoutKind, Class valueType, Object newValue) { > > Why no more `@ForceInline`? Good catch ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2007903156 From mcimadamore at openjdk.org Fri Mar 21 16:21:10 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 16:21:10 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v7] In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add missing `@ForceInline` ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1402/files - new: https://git.openjdk.org/valhalla/pull/1402/files/7ddd5493..6b1b3794 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=06 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=05-06 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From fparain at openjdk.org Fri Mar 21 17:27:34 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 21 Mar 2025 17:27:34 GMT Subject: [lworld] RFR: 8352613: [lworld] New Unsafe API for special array creation needed by VarHandle In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 15:24:08 GMT, Chen Liang wrote: >> src/hotspot/share/prims/unsafe.cpp line 409: >> >>> 407: } UNSAFE_END >>> 408: >>> 409: UNSAFE_ENTRY(jarray, Unsafe_NewSpecialArray(JNIEnv *env, jobject unsafe, jclass elmClass, jint len, jint layoutKind)) { >> >> Should it be called newFlatArray? > > Indeed, this rejects `LayoutKind::REFERENCE` Special is less restrictive if we have to evolve this API (the layout argument being an opaque token for the Java side, we can encode a lot of things in it). ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1404#discussion_r2008013464 From fparain at openjdk.org Fri Mar 21 17:27:34 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 21 Mar 2025 17:27:34 GMT Subject: [lworld] Integrated: 8352613: [lworld] New Unsafe API for special array creation needed by VarHandle In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 14:32:23 GMT, Frederic Parain wrote: > New Unsafe API to help the implementation of VarHandle's CAS operations on flat values. This pull request has now been integrated. Changeset: eae2c524 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/eae2c5243f1adafd7678d2f73a503b628ae6f419 Stats: 130 lines in 3 files changed: 130 ins; 0 del; 0 mod 8352613: [lworld] New Unsafe API for special array creation needed by VarHandle Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/valhalla/pull/1404 From liach at openjdk.org Fri Mar 21 17:53:17 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 17:53:17 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v7] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> <-4BkbOKNPx7aLnDIRhH1J3JYlaYEFKnePu5EK2me8d4=.168fe7db-3d77-49b8-a442-d51eb20e0f78@github.com> Message-ID: On Thu, 20 Mar 2025 11:15:34 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 311: >> >>> 309: // do not check for atomicity now -- atomicity will be checked on the accessed array object >>> 310: // a sharper var handle will be obtained (dynamically) from flatArrayElementHandleFor(Object) >>> 311: return maybeAdapt(new VarHandleReferences.Array(aoffset, ashift, arrayClass)); >> >> Note: this works because: >> * the reference Array plain access uses array syntax (which works no matter the array passed in) >> * non-plain access modes always delegate to sharper var handles based on the type of the accessed array > > Another note: at the language level there's no mechanism to obtain a class mirror for a null-restricted, or atomic array. This means we can't really create an array var handle that works only on one array shape (which would allow us to eliminate the dynamic dispatch completely, at least for some array var handles). Yep, now it is crucial for us to benchmark these var handles - I suspect they are very sensitive to profile pollutions. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008047511 From liach at openjdk.org Fri Mar 21 17:53:19 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 17:53:19 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v7] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Fri, 21 Mar 2025 16:21:10 GMT, Maurizio Cimadamore wrote: >> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add missing `@ForceInline` src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template line 441: > 439: #end[Object] > 440: #if[FlatValue] > 441: final int layout; extra spaces test/jdk/valhalla/valuetypes/NullRestrictedArraysTest.java line 29: > 27: * @enablePreview > 28: * @run junit/othervm NullRestrictedArraysTest > 29: * @run junit/othervm -XX:-UseArrayFlattening NullRestrictedArraysTest Why remove the no flattening configurations? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008048497 PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008053379 From liach at openjdk.org Fri Mar 21 17:53:20 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 17:53:20 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v5] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> <_cJy_5VwKgX0TYeBFKCuI8lEXKlmv295AJ5SAIGmLas=.e0445bcc-2d3a-4576-9bf4-b5695b0427ee@github.com> Message-ID: On Fri, 21 Mar 2025 16:13:58 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3286: >> >>> 3284: } >>> 3285: >>> 3286: public Object getAndSetFlatValue(Object o, long offset, int layoutKind, Class valueType, Object newValue) { >> >> Why no more `@ForceInline`? > > Good catch Still missing forceinline here Suggestion: @ForceInline public Object getAndSetFlatValue(Object o, long offset, int layoutKind, Class valueType, Object newValue) { ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008052152 From liach at openjdk.org Fri Mar 21 17:53:19 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 17:53:19 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v2] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Fri, 21 Mar 2025 16:13:39 GMT, Maurizio Cimadamore wrote: >> I think runtime support is better for down the road for this part. > > We have decided to address this by adding a primitive to create a flat array with given known layout: > https://github.com/openjdk/valhalla/pull/1404 > > Once that API is integrated, I will rebase this PR on top of that. That API is now in. This patch looks fine to me otherwise. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008044143 From mcimadamore at openjdk.org Fri Mar 21 19:02:30 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 19:02:30 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v8] In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - Address review commments - Simplify Unsafe::compareAndSetFlatValueAsBytes to use new unsafe flat array creation primitive - Merge branch 'lworld' into varhandle_flat - Add missing `@ForceInline` - Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java Co-authored-by: Chen Liang - Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java Co-authored-by: Chen Liang - Tighten the signature of VarHandles::checkAtomicFlatArray - Avoid dynamic var handle creation in the middle of array element access - Fix test header - Enhance compareAndSetFlatValueAsBytes to work on different kinds of flat arrays Cache result of oop-free analysis Beef up tests to check different combinations of VM flags - ... and 6 more: https://git.openjdk.org/valhalla/compare/fae70008...000917a3 ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1402/files - new: https://git.openjdk.org/valhalla/pull/1402/files/6b1b3794..000917a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=07 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=06-07 Stats: 144 lines in 5 files changed: 131 ins; 5 del; 8 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From mcimadamore at openjdk.org Fri Mar 21 19:02:30 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 19:02:30 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v2] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: <7btBhiphnZPV3oZFckXTHg6dZk8TlvBrQ7noK2wltKc=.fde05cab-9fdb-482f-b676-3b9ba6661746@github.com> On Fri, 21 Mar 2025 17:45:15 GMT, Chen Liang wrote: >> We have decided to address this by adding a primitive to create a flat array with given known layout: >> https://github.com/openjdk/valhalla/pull/1404 >> >> Once that API is integrated, I will rebase this PR on top of that. > > That API is now in. This patch looks fine to me otherwise. I've now simplified the code to use the new primitive. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008161109 From mcimadamore at openjdk.org Fri Mar 21 19:02:31 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 19:02:31 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v8] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: <_5qNKKVfgAcwJuyOG4Vv_-lf9KOeyaJQmdS7gnBmpI8=.28f73392-676e-42a5-a1b7-57303fe97bcd@github.com> On Fri, 21 Mar 2025 17:50:25 GMT, Chen Liang wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: >> >> - Address review commments >> - Simplify Unsafe::compareAndSetFlatValueAsBytes to use new unsafe flat array creation primitive >> - Merge branch 'lworld' into varhandle_flat >> - Add missing `@ForceInline` >> - Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java >> >> Co-authored-by: Chen Liang >> - Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java >> >> Co-authored-by: Chen Liang >> - Tighten the signature of VarHandles::checkAtomicFlatArray >> - Avoid dynamic var handle creation in the middle of array element access >> - Fix test header >> - Enhance compareAndSetFlatValueAsBytes to work on different kinds of flat arrays >> Cache result of oop-free analysis >> Beef up tests to check different combinations of VM flags >> - ... and 6 more: https://git.openjdk.org/valhalla/compare/fae70008...000917a3 > > test/jdk/valhalla/valuetypes/NullRestrictedArraysTest.java line 29: > >> 27: * @enablePreview >> 28: * @run junit/othervm NullRestrictedArraysTest >> 29: * @run junit/othervm -XX:-UseArrayFlattening NullRestrictedArraysTest > > Why remove the no flattening configurations? If array flattening is disabled, but field flattening is enabled, we might run into situation where the new flat array primitive fails -- that primitive requires same level of flattening for both arrays and fields. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008163595 From mcimadamore at openjdk.org Fri Mar 21 19:02:31 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 19:02:31 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v8] In-Reply-To: <_5qNKKVfgAcwJuyOG4Vv_-lf9KOeyaJQmdS7gnBmpI8=.28f73392-676e-42a5-a1b7-57303fe97bcd@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> <_5qNKKVfgAcwJuyOG4Vv_-lf9KOeyaJQmdS7gnBmpI8=.28f73392-676e-42a5-a1b7-57303fe97bcd@github.com> Message-ID: On Fri, 21 Mar 2025 18:56:50 GMT, Maurizio Cimadamore wrote: >> test/jdk/valhalla/valuetypes/NullRestrictedArraysTest.java line 29: >> >>> 27: * @enablePreview >>> 28: * @run junit/othervm NullRestrictedArraysTest >>> 29: * @run junit/othervm -XX:-UseArrayFlattening NullRestrictedArraysTest >> >> Why remove the no flattening configurations? > > If array flattening is disabled, but field flattening is enabled, we might run into situation where the new flat array primitive fails -- that primitive requires same level of flattening for both arrays and fields. I've now re-enabled this combo -- but disabled both array flattening and nullable flattening. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008165367 From liach at openjdk.org Fri Mar 21 19:24:33 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 19:24:33 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v8] In-Reply-To: References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Fri, 21 Mar 2025 19:02:30 GMT, Maurizio Cimadamore wrote: >> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - Address review commments > - Simplify Unsafe::compareAndSetFlatValueAsBytes to use new unsafe flat array creation primitive > - Merge branch 'lworld' into varhandle_flat > - Add missing `@ForceInline` > - Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java > > Co-authored-by: Chen Liang > - Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java > > Co-authored-by: Chen Liang > - Tighten the signature of VarHandles::checkAtomicFlatArray > - Avoid dynamic var handle creation in the middle of array element access > - Fix test header > - Enhance compareAndSetFlatValueAsBytes to work on different kinds of flat arrays > Cache result of oop-free analysis > Beef up tests to check different combinations of VM flags > - ... and 6 more: https://git.openjdk.org/valhalla/compare/1c6416bf...000917a3 src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3288: > 3286: > 3287: public Object getAndSetFlatValue(Object o, long offset, int layoutKind, Class valueType, Object newValue) { > 3288: Object v; Suggestion: @ForceInline public Object getAndSetFlatValue(Object o, long offset, int layoutKind, Class valueType, Object newValue) { Object v; Just because how stupid github comment thread is :( ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2008202189 From frederic.parain at oracle.com Fri Mar 21 19:54:41 2025 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 21 Mar 2025 15:54:41 -0400 Subject: CFV: New Committer: Matias Saavedra Silva In-Reply-To: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> References: <617393b2-f64a-41b9-af3f-fa18a3f64e49@oracle.com> Message-ID: <552878e2-943b-43c4-a08f-fec58783fdf8@oracle.com> Vote: yes On 3/17/25 15:37, coleen.phillimore at oracle.com wrote: > I hereby nominate Matias Saavedra Silva [1] to Valhalla Committer. > > Matias is a member of the HotSpot Runtime Team at Oracle and an > OpenJDK Reviewer. He is working on verifier changes for strict fields, > and other runtime changes for Valhalla. He has contributed 6 changes > to the valhalla repository [3]. > > Votes are due by March 31, 2025, 13:00 UTC. > > Only current Valhalla Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. > > Thanks, > Coleen Phillimore > > [1] https://openjdk.java.net/census#matsaave > [2] > https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20matsaave%20and%20fixVersion%20%3D%20repo-valhalla%20 > [3] https://openjdk.java.net/census#valhalla > [4] https://openjdk.org/projects/#committer-vote From mcimadamore at openjdk.org Fri Mar 21 21:47:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 21 Mar 2025 21:47:39 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v9] In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: <6vvGs7XX3m7_Oa6euag0QAbrAjN_liMm2eRMfC9jyCg=.c3c79dfd-519f-4afe-82e0-e242f5eb0570@github.com> > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1402/files - new: https://git.openjdk.org/valhalla/pull/1402/files/000917a3..a823ba4c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=08 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1402&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1402.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1402/head:pull/1402 PR: https://git.openjdk.org/valhalla/pull/1402 From liach at openjdk.org Fri Mar 21 23:57:28 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 21 Mar 2025 23:57:28 GMT Subject: [lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v9] In-Reply-To: <6vvGs7XX3m7_Oa6euag0QAbrAjN_liMm2eRMfC9jyCg=.c3c79dfd-519f-4afe-82e0-e242f5eb0570@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> <6vvGs7XX3m7_Oa6euag0QAbrAjN_liMm2eRMfC9jyCg=.c3c79dfd-519f-4afe-82e0-e242f5eb0570@github.com> Message-ID: <-FmHunPyE-CwBBC3q_IgFvkJ_YjC-Q37qftAthEYitw=.a47788f6-b2c0-427d-95f2-192f9dd3a36d@github.com> On Fri, 21 Mar 2025 21:47:39 GMT, Maurizio Cimadamore wrote: >> This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/jdk/internal/misc/Unsafe.java > > Co-authored-by: Chen Liang Looks good. ------------- Marked as reviewed by liach (no project role). PR Review: https://git.openjdk.org/valhalla/pull/1402#pullrequestreview-2707579229 From qamai at openjdk.org Sun Mar 23 07:25:20 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 23 Mar 2025 07:25:20 GMT Subject: [lworld] Withdrawn: 8335256: [lworld] compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently In-Reply-To: References: Message-ID: On Mon, 10 Feb 2025 18:31:00 GMT, Quan Anh Mai wrote: > Hi, > > The assert fires because in this place: > > if (is_osr_parse()) { > Node* osr_buf = entry_map->in(TypeFunc::Parms+0); > entry_map->set_req(TypeFunc::Parms+0, top()); > set_map(entry_map); > load_interpreter_state(osr_buf); > } else { > set_map(entry_map); > do_method_entry(); > } > > `load_interpreter_state` assumes that all incoming inline types are non-larval, while in the following place: > > if (t->is_inlinetypeptr()) { > // Create InlineTypeNode from the oop and replace the parameter > bool is_larval = (i == 0) && method()->is_object_constructor() && !method()->holder()->is_java_lang_Object(); > Node* vt = InlineTypeNode::make_from_oop(this, parm, t->inline_klass(), !t->maybe_null(), is_larval); > replace_in_map(parm, vt); > } > > `is_larval == true` because we are osr-compiling the constructor of a value class. As a result, we pass a non-larval object into `InlineTypeNode::make_from_oop` and want to make it larval, triggering the assert. > > Thinking more deeply into this, I think there is no way we can know the larval-ness of an incoming object in an osr-compilation unless `ciTypeFlow` does so. For example, consider this bytecode sequence: > > ValueObject x = new ValueObject; > for { > } > x.(); > > Then, when we osr-compile the method from the loop, `x` will be a larval object and it can be at any place on the JVM stack or in the local slots. > > As a result, I propose optimistically assuming all osr parameters be non-larval, then we can change them to larval when encountering a constructor invocation or a field store instruction. The verifier should ensure that we cannot do anything else on a larval object as well as do these actions on a non-larval object, so we should recognize the correct state of the value object if any operation is performed on them. Otherwise, they should be dead and not apear here. > > Please take a look and give your advices, thanks a lot. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/1358 From qamai at openjdk.org Sun Mar 23 17:25:29 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 23 Mar 2025 17:25:29 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics Message-ID: Hi, As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. Please take a look and review this PR, thanks a lot. ------------- Commit messages: - Remove larval InlineTypeNode in Unsafe instrinsics Changes: https://git.openjdk.org/valhalla/pull/1406/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352647 Stats: 52 lines in 3 files changed: 38 ins; 2 del; 12 mod Patch: https://git.openjdk.org/valhalla/pull/1406.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/valhalla/pull/1406 From mcimadamore at openjdk.org Mon Mar 24 13:16:26 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 24 Mar 2025 13:16:26 GMT Subject: [lworld] Integrated: 8351569: [lworld] Revisit atomic access modes in flat var handles In-Reply-To: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> References: <87K9B87b9Lf44mAT2uGcyIuOnWlzGP3CXsxJwuOYsT8=.3c264451-fabe-4383-b29f-74da0c5e6f53@github.com> Message-ID: On Wed, 19 Mar 2025 18:31:27 GMT, Maurizio Cimadamore wrote: > This PR is an attempt to put var handle support for flat values on a more solid footing. Some more notes in a comment below. This pull request has now been integrated. Changeset: 0f7cdf3b Author: Maurizio Cimadamore URL: https://git.openjdk.org/valhalla/commit/0f7cdf3b34b8339d3c4f7982a09133089c5b09b0 Stats: 919 lines in 8 files changed: 667 ins; 58 del; 194 mod 8351569: [lworld] Revisit atomic access modes in flat var handles Reviewed-by: liach ------------- PR: https://git.openjdk.org/valhalla/pull/1402 From rriggs at openjdk.org Tue Mar 25 18:51:02 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 25 Mar 2025 18:51:02 GMT Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects [v6] In-Reply-To: References: Message-ID: > Add APINote and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. > Simplified WeakHashMap javadoc updates for IdentityException. > Added note to System.identityHashCode to include value objects. > Added to class javadoc for IdentityHashMap for value objects. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'lworld' into 8346307-throws-identityexception - Merge branch 'lworld' into 8346307-throws-identityexception - Merge - Expand javadoc reference to Reference - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception - Merge branch 'openjdk:lworld' into 8346307-throws-identityexception - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException Add APINote and javadoc for IdentityException where it will be useful to know. Simplified WeakHashMap javadoc updates for IdentityException. Added note to System.identityHashCode to include value objects. - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException Add APINote and javadoc for IdentityException where it will be useful to know. Updated Objects.hasIdentity to return true for non-null reference to identity class; else false Added Objects.isValueObject to return true for non-null reference to value class; else false Updated tests for value objects. ------------- Changes: https://git.openjdk.org/valhalla/pull/1327/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1327&range=05 Stats: 250 lines in 11 files changed: 193 ins; 14 del; 43 mod Patch: https://git.openjdk.org/valhalla/pull/1327.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1327/head:pull/1327 PR: https://git.openjdk.org/valhalla/pull/1327 From jbhateja at openjdk.org Wed Mar 26 03:21:14 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 26 Mar 2025 03:21:14 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 17:21:15 GMT, Quan Anh Mai wrote: > Hi, > > As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. > > Please take a look and review this PR, thanks a lot. src/hotspot/share/opto/doCall.cpp line 156: > 154: CallGenerator* cg = find_intrinsic(callee, call_does_dispatch); > 155: > 156: if (cg == nullptr) { Please add comment when will cg be null in this context. src/hotspot/share/opto/library_call.cpp line 2685: > 2683: ciInlineKlass* vk = type->inline_klass(); > 2684: Node* klass = makecon(TypeKlassPtr::make(vk)); > 2685: Node* obj = new_instance(klass); We have adpoted a similar strategy in lworld-vector https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1071 ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2013317869 PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2013321491 From jbhateja at openjdk.org Wed Mar 26 03:21:15 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 26 Mar 2025 03:21:15 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 03:15:06 GMT, Jatin Bhateja wrote: >> Hi, >> >> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. >> >> Please take a look and review this PR, thanks a lot. > > src/hotspot/share/opto/library_call.cpp line 2685: > >> 2683: ciInlineKlass* vk = type->inline_klass(); >> 2684: Node* klass = makecon(TypeKlassPtr::make(vk)); >> 2685: Node* obj = new_instance(klass); > > We have adpoted a similar strategy in lworld-vector > > https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1071 We should also emit the IR to mark the larval bit in the object header. https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1075 ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2013322213 From thartmann at openjdk.org Wed Mar 26 09:04:24 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 26 Mar 2025 09:04:24 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: Message-ID: On Sun, 23 Mar 2025 17:21:15 GMT, Quan Anh Mai wrote: > Hi, > > As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. > > Please take a look and review this PR, thanks a lot. I just had a look at https://github.com/openjdk/valhalla/pull/1405, thanks for working on this @merykitty. > so that larval objects do not cross call boundaries except for invoking object constructors But this will not prevent users from passing larval objects created via `makePrivateBuffer` to other methods, right? I.e., we still have the issues described in [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) (and linked issues). ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2753658777 From chagedorn at openjdk.org Wed Mar 26 11:42:55 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 26 Mar 2025 11:42:55 GMT Subject: [lworld] RFR: 8350632: [lworld] Parse::array_store_check() assert introduced by 8348411 fails Message-ID: <6x_vuskTWo30ZfMFsXOSiKZTPN--LkzBV2f0RKDOd48=.83ac83c6-0efe-4db6-8083-3f6a2bc078b4@github.com> The assert introduced with JDK-8348411 is too strong when having value classes around because of the following reason: https://github.com/openjdk/valhalla/blob/3f6f249bd457538f020d062ffe5b295509b45a4c/src/hotspot/share/opto/parseHelper.cpp#L265-L267 I've updated the assert to make it work with value classes by special casing them. Thanks, Christian ------------- Commit messages: - 8350632: [lworld] Parse::array_store_check() assert introduced by 8348411 fails Changes: https://git.openjdk.org/valhalla/pull/1410/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1410&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350632 Stats: 10 lines in 1 file changed: 8 ins; 2 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1410.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1410/head:pull/1410 PR: https://git.openjdk.org/valhalla/pull/1410 From thartmann at openjdk.org Wed Mar 26 13:20:38 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 26 Mar 2025 13:20:38 GMT Subject: [lworld] RFR: 8350632: [lworld] Parse::array_store_check() assert introduced by 8348411 fails In-Reply-To: <6x_vuskTWo30ZfMFsXOSiKZTPN--LkzBV2f0RKDOd48=.83ac83c6-0efe-4db6-8083-3f6a2bc078b4@github.com> References: <6x_vuskTWo30ZfMFsXOSiKZTPN--LkzBV2f0RKDOd48=.83ac83c6-0efe-4db6-8083-3f6a2bc078b4@github.com> Message-ID: <-DCADMoPcDxcLt4GLZTLu_VjQe7_PjGN0vFY3Kbiiuw=.4d7cb288-0801-4181-a35d-a0daf8a1abb2@github.com> On Wed, 26 Mar 2025 11:37:13 GMT, Christian Hagedorn wrote: > The assert introduced with JDK-8348411 is too strong when having value classes around because of the following reason: > > https://github.com/openjdk/valhalla/blob/3f6f249bd457538f020d062ffe5b295509b45a4c/src/hotspot/share/opto/parseHelper.cpp#L265-L267 > > I've updated the assert to make it work with value classes by special casing them. > > Thanks, > Christian Looks good to me. Thanks for working on this, Christian! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1410#pullrequestreview-2717141466 From chagedorn at openjdk.org Wed Mar 26 14:10:21 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 26 Mar 2025 14:10:21 GMT Subject: [lworld] RFR: 8350632: [lworld] Parse::array_store_check() assert introduced by 8348411 fails In-Reply-To: <6x_vuskTWo30ZfMFsXOSiKZTPN--LkzBV2f0RKDOd48=.83ac83c6-0efe-4db6-8083-3f6a2bc078b4@github.com> References: <6x_vuskTWo30ZfMFsXOSiKZTPN--LkzBV2f0RKDOd48=.83ac83c6-0efe-4db6-8083-3f6a2bc078b4@github.com> Message-ID: <9FQ65zU_WIbOZgziR1QnkwrgG7O5YM5qNiRrXrPIsXM=.b7b3d0e3-e7b8-4748-a0de-21690a6c3311@github.com> On Wed, 26 Mar 2025 11:37:13 GMT, Christian Hagedorn wrote: > The assert introduced with JDK-8348411 is too strong when having value classes around because of the following reason: > > https://github.com/openjdk/valhalla/blob/3f6f249bd457538f020d062ffe5b295509b45a4c/src/hotspot/share/opto/parseHelper.cpp#L265-L267 > > I've updated the assert to make it work with value classes by special casing them. > > Thanks, > Christian Thanks Tobias for your review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1410#issuecomment-2754557227 From chagedorn at openjdk.org Wed Mar 26 14:10:22 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 26 Mar 2025 14:10:22 GMT Subject: [lworld] Integrated: 8350632: [lworld] Parse::array_store_check() assert introduced by 8348411 fails In-Reply-To: <6x_vuskTWo30ZfMFsXOSiKZTPN--LkzBV2f0RKDOd48=.83ac83c6-0efe-4db6-8083-3f6a2bc078b4@github.com> References: <6x_vuskTWo30ZfMFsXOSiKZTPN--LkzBV2f0RKDOd48=.83ac83c6-0efe-4db6-8083-3f6a2bc078b4@github.com> Message-ID: <-udCDgrBS9-VAizfk1Ijpq9Qi-0hMk1u_NRqJPzuXOM=.875129ee-95dd-4c86-b80b-7fe3810091a2@github.com> On Wed, 26 Mar 2025 11:37:13 GMT, Christian Hagedorn wrote: > The assert introduced with JDK-8348411 is too strong when having value classes around because of the following reason: > > https://github.com/openjdk/valhalla/blob/3f6f249bd457538f020d062ffe5b295509b45a4c/src/hotspot/share/opto/parseHelper.cpp#L265-L267 > > I've updated the assert to make it work with value classes by special casing them. > > Thanks, > Christian This pull request has now been integrated. Changeset: dd0b9589 Author: Christian Hagedorn URL: https://git.openjdk.org/valhalla/commit/dd0b9589f5db0784ffe102e8952e742ea60e0852 Stats: 10 lines in 1 file changed: 8 ins; 2 del; 0 mod 8350632: [lworld] Parse::array_store_check() assert introduced by 8348411 fails Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1410 From qamai at openjdk.org Wed Mar 26 14:14:12 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 26 Mar 2025 14:14:12 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: > Hi, > > As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. > > Please take a look and review this PR, thanks a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: comments, set and unset larval bit ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1406/files - new: https://git.openjdk.org/valhalla/pull/1406/files/192bcdfd..70c7030c Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1406&range=00-01 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/1406.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1406/head:pull/1406 PR: https://git.openjdk.org/valhalla/pull/1406 From qamai at openjdk.org Wed Mar 26 14:14:14 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 26 Mar 2025 14:14:14 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 09:01:31 GMT, Tobias Hartmann wrote: >> Hi, >> >> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. >> >> Please take a look and review this PR, thanks a lot. > > I just had a look at https://github.com/openjdk/valhalla/pull/1405, thanks for working on this @merykitty. > >> so that larval objects do not cross call boundaries except for invoking object constructors > > But this will not prevent users from passing larval objects created via `makePrivateBuffer` to other methods, right? I.e., we still have the issues described in [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) (and linked issues). @TobiHartmann > But this will not prevent users from passing larval objects created via makePrivateBuffer to other methods, right? I.e., we still have the issues described in [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) (and linked issues). My stance on this matter is that we should simply disallow passing larval objects except to `Unsafe::putXXX` and `Unsafe::finishPrivateBuffer`. What do you think? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2754571231 From qamai at openjdk.org Wed Mar 26 14:14:16 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 26 Mar 2025 14:14:16 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 03:16:29 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/library_call.cpp line 2685: >> >>> 2683: ciInlineKlass* vk = type->inline_klass(); >>> 2684: Node* klass = makecon(TypeKlassPtr::make(vk)); >>> 2685: Node* obj = new_instance(klass); >> >> We have adpoted a similar strategy in lworld-vector >> >> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1071 > > We should also emit the IR to mark the larval bit in the object header. > https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1075 Thanks for noticing, I forgot about that, I believe setting the `_larval` field in the corresponding `AllocateNode` is adequate, since macro expansion will do the right thing. I also add code to unset the larval bit in `finishPrivateBuffer`. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2014241292 From vromero at openjdk.org Wed Mar 26 20:06:05 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 26 Mar 2025 20:06:05 GMT Subject: [lworld] Integrated: 8352892: [lworld] javac is issuing a compiler error for a method that just sets a strict field Message-ID: when compiling this code: import jdk.internal.vm.annotation.*; value class Point { Point(int i, int j) {} } class Parent { @Strict @NullRestricted Point fp = new Point(1, 2); /* Flattenable and flattened inline field */ public void setFp(Point p) { fp = p; } } javac is failing with: myTests/StrictFieldsError.java:12: error: cannot assign to fp after supertype constructor has been called public void setFp(Point p) { fp = p; } ^ Note: myTests/StrictFieldsError.java uses preview features of Java SE 25. Note: Recompile with -Xlint:preview for details. 1 error command: build/langtools/bin/javac -d out --enable-preview -source 25 --add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED myTests/StrictFieldsError.java this code should be accepted by the compiler ------------- Commit messages: - refactoring - additional infra for value records - 8352892: [lworld] javac is issuing a compiler error for a method that just sets a strict field Changes: https://git.openjdk.org/valhalla/pull/1408/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1408&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352892 Stats: 71 lines in 6 files changed: 51 ins; 14 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/1408.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1408/head:pull/1408 PR: https://git.openjdk.org/valhalla/pull/1408 From vromero at openjdk.org Wed Mar 26 20:06:06 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 26 Mar 2025 20:06:06 GMT Subject: [lworld] Integrated: 8352892: [lworld] javac is issuing a compiler error for a method that just sets a strict field In-Reply-To: References: Message-ID: On Tue, 25 Mar 2025 20:40:15 GMT, Vicente Romero wrote: > when compiling this code: > > import jdk.internal.vm.annotation.*; > > value class Point { > Point(int i, int j) {} > } > > class Parent { > @Strict > @NullRestricted > Point fp = new Point(1, 2); /* Flattenable and flattened inline field */ > > public void setFp(Point p) { fp = p; } > } > > javac is failing with: > > myTests/StrictFieldsError.java:12: error: cannot assign to fp after supertype constructor has been called > public void setFp(Point p) { fp = p; } > ^ > Note: myTests/StrictFieldsError.java uses preview features of Java SE 25. > Note: Recompile with -Xlint:preview for details. > 1 error > > command: > > build/langtools/bin/javac -d out --enable-preview -source 25 --add-exports=java.base/jdk.internal.vm.annotation=ALL-UNNAMED myTests/StrictFieldsError.java > > > this code should be accepted by the compiler This pull request has now been integrated. Changeset: ea8521de Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/ea8521de3f1627ec35894be33bed14988572fae1 Stats: 71 lines in 6 files changed: 51 ins; 14 del; 6 mod 8352892: [lworld] javac is issuing a compiler error for a method that just sets a strict field ------------- PR: https://git.openjdk.org/valhalla/pull/1408 From chagedorn at openjdk.org Thu Mar 27 14:29:17 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 27 Mar 2025 14:29:17 GMT Subject: [lworld] RFR: 8352727: [lworld] Remove or replace obsolete StressInlineTypeReturnedAsFields flag from tests Message-ID: [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) renamed `StressInlineTypeReturnedAsFields` to `StressCallingConvention` and added some more stressing possibilities. However, it was forgotten to update the flag in tests in two locations: ### Use in Default Scenario One default scenario uses `-XX:+StressInlineTypeReturnedAsFields` for Valhalla IR tests. The tests still succeed because we have `-XX:+IgnoreUnrecognizedVMOptions` in place which ignores the now non-existing flag. I tried to replace `StressInlineTypeReturnedAsFields` with the updated `StressCallingConvention` flag but it turns out that too many IR rules rely on a predictable calling convention such that we could verify that all allocations are removed. With `StressCallingConvention`, we could now randomly enforce allocations because we cannot pass a value object in scalarized form anymore because there is only a non-scalarized calling convention. I therefore propose to simply drop `StressInlineTypeReturnedAsFields` from the default scenario without replacement. Note that we still have stress jobs in place that run with `StressCallingConvention` enabled to exercise different combinations of calling conventions. ### Use in `TestCallingConventionC1.java` The second use in `TestCallingConventionC1.java` can be replaced by `StressCallingConvention` because we do not have any IR rules that could be affected. Thanks, Christian ------------- Commit messages: - 8352727: [lworld] Remove or replace obsolete StressInlineTypeReturnedAsFields flag from tests Changes: https://git.openjdk.org/valhalla/pull/1412/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1412&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352727 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/1412.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1412/head:pull/1412 PR: https://git.openjdk.org/valhalla/pull/1412 From jbhateja at openjdk.org Fri Mar 28 08:45:56 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 28 Mar 2025 08:45:56 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: Message-ID: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> On Wed, 26 Mar 2025 14:10:30 GMT, Quan Anh Mai wrote: >> I just had a look at https://github.com/openjdk/valhalla/pull/1405, thanks for working on this @merykitty. >> >>> so that larval objects do not cross call boundaries except for invoking object constructors >> >> But this will not prevent users from passing larval objects created via `makePrivateBuffer` to other methods, right? I.e., we still have the issues described in [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) (and linked issues). > > @TobiHartmann > >> But this will not prevent users from passing larval objects created via makePrivateBuffer to other methods, right? I.e., we still have the issues described in [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) (and linked issues). > > My stance on this matter is that we should simply disallow passing larval objects except to `Unsafe::putXXX` and `Unsafe::finishPrivateBuffer`. What do you think? Hi @merykitty , For attached test case I am seeing crash at state merge point b/w larval and non-larval value [unsafe_access.txt](https://github.com/user-attachments/files/19501609/unsafe_access.txt) CPROMPT>javac --enable-preview -source 25 --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED unsafe_access.java Note: unsafe_access.java uses preview features of Java SE 25. Note: Recompile with -Xlint:preview for details. CPROMPT> CPROMPT>java -XX:-PauseAtStartup --enable-preview --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -cp . unsafe_access # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/jatinbha/sandboxes/lworld/src/hotspot/share/opto/parse1.cpp:1790), pid=2453805, tid=2453825 # assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized # # JRE version: OpenJDK Runtime Environment (25.0) (slowdebug build 25-internal-adhoc.root.lworld) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 25-internal-adhoc.root.lworld, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x178efa5] Parse::merge_common(Parse::Block*, int)+0x49f # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/code/java/valhalla/core.2453805) # # An error report file with more information is saved as: # /home/jatinbha/code/java/valhalla/hs_err_pid2453805.log 10001399990 # # Compiler replay data is saved as: # /home/jatinbha/code/java/valhalla/replay_pid2453805.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # Aborted (core dumped) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2760570153 From vromero at openjdk.org Fri Mar 28 14:58:42 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Mar 2025 14:58:42 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers Message-ID: proxy locals ------------- Commit messages: - uncommenting code - generate local proxy variables by default - Merge branch 'lworld' into JDK-8334484 - refactorings - fixing bug in stackmap tables - additional refactoring - refactoring - additional changes - merge with lworld - new development - ... and 3 more: https://git.openjdk.org/valhalla/compare/ea8521de...a2edb309 Changes: https://git.openjdk.org/valhalla/pull/1403/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334484 Stats: 377 lines in 8 files changed: 363 ins; 2 del; 12 mod Patch: https://git.openjdk.org/valhalla/pull/1403.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1403/head:pull/1403 PR: https://git.openjdk.org/valhalla/pull/1403 From thartmann at openjdk.org Fri Mar 28 15:14:01 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 28 Mar 2025 15:14:01 GMT Subject: [lworld] RFR: 8353186: [lworld] Disable failing tests after JDK-8351569 In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 15:07:08 GMT, Christian Hagedorn wrote: > [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) triggered some test failures (see [JDK-8353180](https://bugs.openjdk.org/browse/JDK-8353180) and [JDK-8353182](https://bugs.openjdk.org/browse/JDK-8353182)). To reduce noise until these are fixed, I'm disabling the failing tests by either disabling IR rules or preventing certain flag modes. > > Thanks, > Christian Marked as reviewed by thartmann (Committer). Looks good, thanks! ------------- PR Review: https://git.openjdk.org/valhalla/pull/1413#pullrequestreview-2725865512 PR Comment: https://git.openjdk.org/valhalla/pull/1413#issuecomment-2761645274 From chagedorn at openjdk.org Fri Mar 28 15:14:02 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 28 Mar 2025 15:14:02 GMT Subject: [lworld] RFR: 8353186: [lworld] Disable failing tests after JDK-8351569 In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 15:07:08 GMT, Christian Hagedorn wrote: > [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) triggered some test failures (see [JDK-8353180](https://bugs.openjdk.org/browse/JDK-8353180) and [JDK-8353182](https://bugs.openjdk.org/browse/JDK-8353182)). To reduce noise until these are fixed, I'm disabling the failing tests by either disabling IR rules or preventing certain flag modes. > > Thanks, > Christian Thanks Tobias for your quick review! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1413#issuecomment-2761646121 From chagedorn at openjdk.org Fri Mar 28 15:14:01 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 28 Mar 2025 15:14:01 GMT Subject: [lworld] RFR: 8353186: [lworld] Disable failing tests after JDK-8351569 Message-ID: [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) triggered some test failures (see [JDK-8353180](https://bugs.openjdk.org/browse/JDK-8353180) and [JDK-8353182](https://bugs.openjdk.org/browse/JDK-8353182)). To reduce noise until these are fixed, I'm disabling the failing tests by either disabling IR rules or preventing certain flag modes. Thanks, Christian ------------- Commit messages: - 8353186: [lworld] Disable failing tests after JDK-8351569 Changes: https://git.openjdk.org/valhalla/pull/1413/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1413&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353186 Stats: 31 lines in 3 files changed: 16 ins; 0 del; 15 mod Patch: https://git.openjdk.org/valhalla/pull/1413.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1413/head:pull/1413 PR: https://git.openjdk.org/valhalla/pull/1413 From chagedorn at openjdk.org Fri Mar 28 16:07:21 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 28 Mar 2025 16:07:21 GMT Subject: [lworld] Integrated: 8353186: [lworld] Disable failing tests after JDK-8351569 In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 15:07:08 GMT, Christian Hagedorn wrote: > [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) triggered some test failures (see [JDK-8353180](https://bugs.openjdk.org/browse/JDK-8353180) and [JDK-8353182](https://bugs.openjdk.org/browse/JDK-8353182)). To reduce noise until these are fixed, I'm disabling the failing tests by either disabling IR rules or preventing certain flag modes. > > Thanks, > Christian This pull request has now been integrated. Changeset: ab99743f Author: Christian Hagedorn URL: https://git.openjdk.org/valhalla/commit/ab99743fac6056c3d33ad6aef8cc1f287a393d14 Stats: 31 lines in 3 files changed: 16 ins; 0 del; 15 mod 8353186: [lworld] Disable failing tests after JDK-8351569 Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/1413 From thartmann at openjdk.org Fri Mar 28 16:45:45 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 28 Mar 2025 16:45:45 GMT Subject: [lworld] RFR: 8352727: [lworld] Remove or replace obsolete StressInlineTypeReturnedAsFields flag from tests In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 14:23:21 GMT, Christian Hagedorn wrote: > [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) renamed `StressInlineTypeReturnedAsFields` to `StressCallingConvention` and added some more stressing possibilities. However, it was forgotten to update the flag in tests in two locations: > > ### Use in Default Scenario > > One default scenario uses `-XX:+StressInlineTypeReturnedAsFields` for Valhalla IR tests. The tests still succeed because we have `-XX:+IgnoreUnrecognizedVMOptions` in place which ignores the now non-existing flag. > > I tried to replace `StressInlineTypeReturnedAsFields` with the updated `StressCallingConvention` flag but it turns out that too many IR rules rely on a predictable calling convention such that we could verify that all allocations are removed. With `StressCallingConvention`, we could now randomly enforce allocations because we cannot pass a value object in scalarized form anymore because there is only a non-scalarized calling convention. > > I therefore propose to simply drop `StressInlineTypeReturnedAsFields` from the default scenario without replacement. > > Note that we still have stress jobs in place that run with `StressCallingConvention` enabled to exercise different combinations of calling conventions. > > > ### Use in `TestCallingConventionC1.java` > The second use in `TestCallingConventionC1.java` can be replaced by `StressCallingConvention` because we do not have any IR rules that could be affected. > > Thanks, > Christian Good catch! The fix looks good to me. ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/1412#pullrequestreview-2726119106 From dlsmith at openjdk.org Fri Mar 28 16:55:32 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Fri, 28 Mar 2025 16:55:32 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers In-Reply-To: References: Message-ID: On Wed, 19 Mar 2025 19:26:00 GMT, Vicente Romero wrote: > Proxy locals are added as a new compiler phase which is executed just before code generation. > > Q - what it does? > A - basically for code like: > > abstract value class Super { > Super(String s) {} > } > > value class V extends Super { > int i; > V(String s) { > if (s != null) { > i = 100; > } else { > i = 200; > } > super("100" + s); > } > } > > javac will generate for V's constructor something in the lines of: > > V(String s) { > /*synthetic*/ int local$i; > if (s != null) { > local$i = 100; > } else { > local$i = 200; > } > { > /*synthetic*/ final String local$0 = "100" + s; > i = local$i; > super(local$0); > } > } > > so given a constructor for which any strict field is assigned to in a block that is not at the same level as the super constructor invocation, javac will generate synthetic local variables that will correspond to every strict field and any read or write done to a given strict field will be done on the synthetic local variable. > > Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor. > > Q - does it interacts with other valhalla features? > A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry is not generated now > Q- is it on by default? > A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests > > TIA for any comments Based on the description, looks like the trigger for this treatment is being a strict field assigned to with nontrivial control flow. That's not an issue?we've got StackMapTable entries to manage those fields (and we _want_ to be exercising those StackMapTable entries, to ensure they're working properly). Where we need a proxy local is when a field is _read_ somewhere in the early construction phase. In that case, the generated `getfield` would always trigger a verifier error, and javac needs to translate to a local variable read instead. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1403#issuecomment-2761911720 From qamai at openjdk.org Fri Mar 28 16:57:33 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 28 Mar 2025 16:57:33 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> References: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> Message-ID: On Fri, 28 Mar 2025 08:42:52 GMT, Jatin Bhateja wrote: >> @TobiHartmann >> >>> But this will not prevent users from passing larval objects created via makePrivateBuffer to other methods, right? I.e., we still have the issues described in [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) (and linked issues). >> >> My stance on this matter is that we should simply disallow passing larval objects except to `Unsafe::putXXX` and `Unsafe::finishPrivateBuffer`. What do you think? > > Hi @merykitty , > For attached test case I am seeing crash at state merge point b/w larval and non-larval value > > [unsafe_access.txt](https://github.com/user-attachments/files/19501609/unsafe_access.txt) > > > CPROMPT>javac --enable-preview -source 25 --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED unsafe_access.java > Note: unsafe_access.java uses preview features of Java SE 25. > Note: Recompile with -Xlint:preview for details. > CPROMPT> > CPROMPT>java -XX:-PauseAtStartup --enable-preview --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -cp . unsafe_access > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/jatinbha/sandboxes/lworld/src/hotspot/share/opto/parse1.cpp:1790), pid=2453805, tid=2453825 > # assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized > # > # JRE version: OpenJDK Runtime Environment (25.0) (slowdebug build 25-internal-adhoc.root.lworld) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 25-internal-adhoc.root.lworld, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x178efa5] Parse::merge_common(Parse::Block*, int)+0x49f > # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/code/java/valhalla/core.2453805) > # > # An error report file with more information is saved as: > # /home/jatinbha/code/java/valhalla/hs_err_pid2453805.log > 10001399990 > # > # Compiler replay data is saved as: > # /home/jatinbha/code/java/valhalla/replay_pid2453805.log > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > Aborted (core dumped) @jatin-bhateja Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. There are issues with merges of larval objects, though, for example: MyValue v = UNSAFE.makePrivateBuffer(v0); for (int i = 0; i < 100; i++) {} return UNSAFE.finishPrivateBuffer(v); But generally, the situation of merging larval objects are messy not just with larval objects created by `Unsafe` and I want to defer the fix to after #1405. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2761918786 From mcimadamore at openjdk.org Fri Mar 28 18:17:34 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Mar 2025 18:17:34 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers In-Reply-To: References: Message-ID: On Wed, 19 Mar 2025 19:26:00 GMT, Vicente Romero wrote: > Proxy locals are added as a new compiler phase which is executed just before code generation. > > Q - what it does? > A - basically for code like: > > abstract value class Super { > Super(String s) {} > } > > value class V extends Super { > int i; > V(String s) { > if (s != null) { > i = 100; > } else { > i = 200; > } > super("100" + s); > } > } > > javac will generate for V's constructor something in the lines of: > > V(String s) { > /*synthetic*/ int local$i; > if (s != null) { > local$i = 100; > } else { > local$i = 200; > } > { > /*synthetic*/ final String local$0 = "100" + s; > i = local$i; > super(local$0); > } > } > > so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable. > > Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor. > > Q - does it interacts with other valhalla features? > A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now > Q- is it on by default? > A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests > > TIA for any comments src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 147: > 145: if (t.hasTag(JCTree.Tag.METHODDEF)) { > 146: JCMethodDecl md = (JCMethodDecl) t; > 147: // ignore telescopic and generated constructors I think TreeInfo::hasAnyConstructorCall might check this for you? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1403#discussion_r2019128068 From mcimadamore at openjdk.org Fri Mar 28 18:21:21 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Mar 2025 18:21:21 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers In-Reply-To: References: Message-ID: <_Fq_bZmKvmoJ_3IwIZrFMDIWNjyQyACo09j6oapOgQA=.bb6fc123-55a6-40fe-ac52-61cfafbc5099@github.com> On Wed, 19 Mar 2025 19:26:00 GMT, Vicente Romero wrote: > Proxy locals are added as a new compiler phase which is executed just before code generation. > > Q - what it does? > A - basically for code like: > > abstract value class Super { > Super(String s) {} > } > > value class V extends Super { > int i; > V(String s) { > if (s != null) { > i = 100; > } else { > i = 200; > } > super("100" + s); > } > } > > javac will generate for V's constructor something in the lines of: > > V(String s) { > /*synthetic*/ int local$i; > if (s != null) { > local$i = 100; > } else { > local$i = 200; > } > { > /*synthetic*/ final String local$0 = "100" + s; > i = local$i; > super(local$0); > } > } > > so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable. > > Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor. > > Q - does it interacts with other valhalla features? > A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now > Q- is it on by default? > A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests > > TIA for any comments src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 295: > 293: private class ConstructorScanner extends TreeScanner { > 294: // Match this scan stack: 1=JCMethodDecl, 2=JCExpressionStatement, 3=JCMethodInvocation > 295: private int scanDepth = 0; // current scan recursion depth in method body Is this used? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1403#discussion_r2019132947 From mcimadamore at openjdk.org Fri Mar 28 18:27:11 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Mar 2025 18:27:11 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 18:14:39 GMT, Maurizio Cimadamore wrote: >> Proxy locals are added as a new compiler phase which is executed just before code generation. >> >> Q - what it does? >> A - basically for code like: >> >> abstract value class Super { >> Super(String s) {} >> } >> >> value class V extends Super { >> int i; >> V(String s) { >> if (s != null) { >> i = 100; >> } else { >> i = 200; >> } >> super("100" + s); >> } >> } >> >> javac will generate for V's constructor something in the lines of: >> >> V(String s) { >> /*synthetic*/ int local$i; >> if (s != null) { >> local$i = 100; >> } else { >> local$i = 200; >> } >> { >> /*synthetic*/ final String local$0 = "100" + s; >> i = local$i; >> super(local$0); >> } >> } >> >> so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable. >> >> Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor. >> >> Q - does it interacts with other valhalla features? >> A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now >> Q- is it on by default? >> A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests >> >> TIA for any comments > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 147: > >> 145: if (t.hasTag(JCTree.Tag.METHODDEF)) { >> 146: JCMethodDecl md = (JCMethodDecl) t; >> 147: // ignore telescopic and generated constructors > > I think TreeInfo::hasAnyConstructorCall might check this for you? Uhmmm probably that doesn't deal with GENERATEDCONSTR (although -- a default constructor should not do much damage -- just maybe some redundant analysis?) ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1403#discussion_r2019139542 From jbhateja at openjdk.org Fri Mar 28 19:21:16 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 28 Mar 2025 19:21:16 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> References: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> Message-ID: On Fri, 28 Mar 2025 08:42:52 GMT, Jatin Bhateja wrote: >> @TobiHartmann >> >>> But this will not prevent users from passing larval objects created via makePrivateBuffer to other methods, right? I.e., we still have the issues described in [JDK-8239003](https://bugs.openjdk.org/browse/JDK-8239003) (and linked issues). >> >> My stance on this matter is that we should simply disallow passing larval objects except to `Unsafe::putXXX` and `Unsafe::finishPrivateBuffer`. What do you think? > > Hi @merykitty , > For attached test case I am seeing crash at state merge point b/w larval and non-larval value > > [unsafe_access.txt](https://github.com/user-attachments/files/19501609/unsafe_access.txt) > > > CPROMPT>javac --enable-preview -source 25 --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED unsafe_access.java > Note: unsafe_access.java uses preview features of Java SE 25. > Note: Recompile with -Xlint:preview for details. > CPROMPT> > CPROMPT>java -XX:-PauseAtStartup --enable-preview --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -cp . unsafe_access > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/jatinbha/sandboxes/lworld/src/hotspot/share/opto/parse1.cpp:1790), pid=2453805, tid=2453825 > # assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized > # > # JRE version: OpenJDK Runtime Environment (25.0) (slowdebug build 25-internal-adhoc.root.lworld) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 25-internal-adhoc.root.lworld, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x178efa5] Parse::merge_common(Parse::Block*, int)+0x49f > # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/code/java/valhalla/core.2453805) > # > # An error report file with more information is saved as: > # /home/jatinbha/code/java/valhalla/hs_err_pid2453805.log > 10001399990 > # > # Compiler replay data is saved as: > # /home/jatinbha/code/java/valhalla/replay_pid2453805.log > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > Aborted (core dumped) > @jatin-bhateja Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. There are issues with merges of larval objects, though, for example: > > ``` > MyValue v = UNSAFE.makePrivateBuffer(v0); > for (int i = 0; i < 100; i++) {} > return UNSAFE.finishPrivateBuffer(v); > ``` > > But generally, the situation of merging larval objects are messy not just with larval objects created by `Unsafe` and I want to defer the fix to after #1405. Easier solution will be to buffer InlineTypeNode if other input of the Phi node is a larval object i.e. in oop form, all the users of this Phi will see the value in oop form with no value forwarding. > @jatin-bhateja Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. There are issues with merges of larval objects, though, for example: > > ``` > MyValue v = UNSAFE.makePrivateBuffer(v0); > for (int i = 0; i < 100; i++) {} > return UNSAFE.finishPrivateBuffer(v); > ``` > > But generally, the situation of merging larval objects are messy not just with larval objects created by `Unsafe` and I want to defer the fix to after #1405. Thanks, @merykitty. I think MEET over larval and non-larval should result in a larval value, so InlineTypeNode, which is the other input of the Phi node, should be buffered and treated as a larval object, too, until we hit upon a finishPrivate buffer call that brings this merged oop value out of the larval state and re-materialize an InlineTypeNode. Kindly include this test with this patch. for now, we can add it to ProblemList.txt, which can be enabled after #1405 . ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2762229178 From qamai at openjdk.org Fri Mar 28 19:47:57 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 28 Mar 2025 19:47:57 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> Message-ID: On Fri, 28 Mar 2025 19:18:26 GMT, Jatin Bhateja wrote: >> Hi @merykitty , >> For attached test case I am seeing crash at state merge point b/w larval and non-larval value >> >> [unsafe_access.txt](https://github.com/user-attachments/files/19501609/unsafe_access.txt) >> >> >> CPROMPT>javac --enable-preview -source 25 --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED unsafe_access.java >> Note: unsafe_access.java uses preview features of Java SE 25. >> Note: Recompile with -Xlint:preview for details. >> CPROMPT> >> CPROMPT>java -XX:-PauseAtStartup --enable-preview --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -cp . unsafe_access >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/jatinbha/sandboxes/lworld/src/hotspot/share/opto/parse1.cpp:1790), pid=2453805, tid=2453825 >> # assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized >> # >> # JRE version: OpenJDK Runtime Environment (25.0) (slowdebug build 25-internal-adhoc.root.lworld) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 25-internal-adhoc.root.lworld, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x178efa5] Parse::merge_common(Parse::Block*, int)+0x49f >> # >> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/code/java/valhalla/core.2453805) >> # >> # An error report file with more information is saved as: >> # /home/jatinbha/code/java/valhalla/hs_err_pid2453805.log >> 10001399990 >> # >> # Compiler replay data is saved as: >> # /home/jatinbha/code/java/valhalla/replay_pid2453805.log >> # >> # If you would like to submit a bug report, please visit: >> # https://bugreport.java.com/bugreport/crash.jsp >> # >> Aborted (core dumped) > >> @jatin-bhateja Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. There are issues with merges of larval objects, though, for example: >> >> ``` >> MyValue v = UNSAFE.makePrivateBuffer(v0); >> for (int i = 0; i < 100; i++) {} >> return UNSAFE.finishPrivateBuffer(v); >> ``` >> >> But generally, the situation of merging larval objects are messy not just with larval objects created by `Unsafe` and I want to defer the fix to after #1405. > > Thanks, @merykitty. I think MEET over larval and non-larval should result in a larval value, so InlineTypeNode, which is the other input of the Phi node, should be buffered and treated as a larval object too, until we hit upon a finishPrivate buffer call that brings this merged oop value out of the larval state and re-materialize an InlineTypeNode. > > Kindly include this test with this patch. for now, we can add it to ProblemList.txt, which can be enabled after #1405 . @jatin-bhateja A larval object created by `Unsafe` should adhere to all the rules that are put on a larval object created by the `new` bytecode. In the type verification system, each larval object has a distinct type being either `uninitializedThis` or `uninitialized(Offset)`. Meeting of a larval object with another larval object or with a non-larval object, thus, will result in a non-typed `reference`. As a result, the program is ill-formed if the merge is used. Please refer to [the JVMS, section 4.10.1](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1). ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2762278615 From vromero at openjdk.org Fri Mar 28 20:00:11 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Mar 2025 20:00:11 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers [v2] In-Reply-To: References: Message-ID: > Proxy locals are added as a new compiler phase which is executed just before code generation. > > Q - what it does? > A - basically for code like: > > abstract value class Super { > Super(String s) {} > } > > value class V extends Super { > int i; > V(String s) { > if (s != null) { > i = 100; > } else { > i = 200; > } > super("100" + s); > } > } > > javac will generate for V's constructor something in the lines of: > > V(String s) { > /*synthetic*/ int local$i; > if (s != null) { > local$i = 100; > } else { > local$i = 200; > } > { > /*synthetic*/ final String local$0 = "100" + s; > i = local$i; > super(local$0); > } > } > > so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable. > > Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor. > > Q - does it interacts with other valhalla features? > A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now > Q- is it on by default? > A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests > > TIA for any comments Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: refactorings ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1403/files - new: https://git.openjdk.org/valhalla/pull/1403/files/a2edb309..de6020a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1403&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1403&range=00-01 Stats: 44 lines in 2 files changed: 1 ins; 26 del; 17 mod Patch: https://git.openjdk.org/valhalla/pull/1403.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1403/head:pull/1403 PR: https://git.openjdk.org/valhalla/pull/1403 From vromero at openjdk.org Fri Mar 28 20:17:20 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Mar 2025 20:17:20 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers [v2] In-Reply-To: <_Fq_bZmKvmoJ_3IwIZrFMDIWNjyQyACo09j6oapOgQA=.bb6fc123-55a6-40fe-ac52-61cfafbc5099@github.com> References: <_Fq_bZmKvmoJ_3IwIZrFMDIWNjyQyACo09j6oapOgQA=.bb6fc123-55a6-40fe-ac52-61cfafbc5099@github.com> Message-ID: On Fri, 28 Mar 2025 18:18:10 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> refactorings > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 295: > >> 293: private class ConstructorScanner extends TreeScanner { >> 294: // Match this scan stack: 1=JCMethodDecl, 2=JCExpressionStatement, 3=JCMethodInvocation >> 295: private int scanDepth = 0; // current scan recursion depth in method body > > Is this used? yep removed it, dead code, thanks ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1403#discussion_r2019290417 From vromero at openjdk.org Fri Mar 28 20:23:42 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 28 Mar 2025 20:23:42 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 16:51:01 GMT, Dan Smith wrote: > Based on the description, looks like the trigger for this treatment is being a strict field assigned to with nontrivial control flow. > > That's not an issue?we've got StackMapTable entries to manage those fields (and we _want_ to be exercising those StackMapTable entries, to ensure they're working properly). > > Where we need a proxy local is when a field is _read_ somewhere in the early construction phase. In that case, the generated `getfield` would always trigger a verifier error, and javac needs to translate to a local variable read instead. ok my bad, I will update the implementation then, thanks ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1403#issuecomment-2762364040 From vromero at openjdk.org Sat Mar 29 01:06:05 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 29 Mar 2025 01:06:05 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers [v3] In-Reply-To: References: Message-ID: > Proxy locals are added as a new compiler phase which is executed just before code generation. > > Q - what it does? > A - basically for code like: > > abstract value class Super { > Super(String s) {} > } > > value class V extends Super { > int i; > V(String s) { > if (s != null) { > i = 100; > } else { > i = 200; > } > super("100" + s); > } > } > > javac will generate for V's constructor something in the lines of: > > V(String s) { > /*synthetic*/ int local$i; > if (s != null) { > local$i = 100; > } else { > local$i = 200; > } > { > /*synthetic*/ final String local$0 = "100" + s; > i = local$i; > super(local$0); > } > } > > so given a constructor for which any strict field is assigned to more than once, javac will generate synthetic local variables that will correspond to it and any read or write done to this strict field will be done on the synthetic local variable. > > Javac will also generate additional synthetic local variables to hold the arguments, if any, of the super constructor invocation and will assign the strict fields with the current value of the corresponding synthetic local just before invoking the super constructor. > > Q - does it interacts with other valhalla features? > A - yes it has a direct interaction with the new stackmap table as the new assert_unset_fields entry, in most cases, is not generated now > Q- is it on by default? > A- yes but there is a hidden option to tell javac not to generate local proxy variables: `noLocalProxyVars` this will allow us to continue using javac for test cases that check for the generation of the assert_unset_fields entry in the stackmap table attribute until we have time to migrate those tests > > TIA for any comments Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/1403/files - new: https://git.openjdk.org/valhalla/pull/1403/files/de6020a6..dae0fc32 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1403&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1403&range=01-02 Stats: 116 lines in 7 files changed: 35 ins; 59 del; 22 mod Patch: https://git.openjdk.org/valhalla/pull/1403.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1403/head:pull/1403 PR: https://git.openjdk.org/valhalla/pull/1403 From vromero at openjdk.org Sat Mar 29 01:06:06 2025 From: vromero at openjdk.org (Vicente Romero) Date: Sat, 29 Mar 2025 01:06:06 GMT Subject: [lworld] RFR: 8334484: [lworld] new translation strategy for instance field initializers [v3] In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 18:23:24 GMT, Maurizio Cimadamore wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 147: >> >>> 145: if (t.hasTag(JCTree.Tag.METHODDEF)) { >>> 146: JCMethodDecl md = (JCMethodDecl) t; >>> 147: // ignore telescopic and generated constructors >> >> I think TreeInfo::hasAnyConstructorCall might check this for you? > > Uhmmm probably that doesn't deal with GENERATEDCONSTR (although -- a default constructor should not do much damage -- just maybe some redundant analysis?) well but TreeInfo::hasAnyConstructorCall will return true for `this()` which I want to discriminate ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1403#discussion_r2019635778 From jbhateja at openjdk.org Sat Mar 29 08:22:45 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 29 Mar 2025 08:22:45 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> Message-ID: On Fri, 28 Mar 2025 19:18:26 GMT, Jatin Bhateja wrote: >> Hi @merykitty , >> For attached test case I am seeing crash at state merge point b/w larval and non-larval value >> >> [unsafe_access.txt](https://github.com/user-attachments/files/19501609/unsafe_access.txt) >> >> >> CPROMPT>javac --enable-preview -source 25 --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED unsafe_access.java >> Note: unsafe_access.java uses preview features of Java SE 25. >> Note: Recompile with -Xlint:preview for details. >> CPROMPT> >> CPROMPT>java -XX:-PauseAtStartup --enable-preview --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -cp . unsafe_access >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/jatinbha/sandboxes/lworld/src/hotspot/share/opto/parse1.cpp:1790), pid=2453805, tid=2453825 >> # assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized >> # >> # JRE version: OpenJDK Runtime Environment (25.0) (slowdebug build 25-internal-adhoc.root.lworld) >> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 25-internal-adhoc.root.lworld, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) >> # Problematic frame: >> # V [libjvm.so+0x178efa5] Parse::merge_common(Parse::Block*, int)+0x49f >> # >> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/jatinbha/code/java/valhalla/core.2453805) >> # >> # An error report file with more information is saved as: >> # /home/jatinbha/code/java/valhalla/hs_err_pid2453805.log >> 10001399990 >> # >> # Compiler replay data is saved as: >> # /home/jatinbha/code/java/valhalla/replay_pid2453805.log >> # >> # If you would like to submit a bug report, please visit: >> # https://bugreport.java.com/bugreport/crash.jsp >> # >> Aborted (core dumped) > >> @jatin-bhateja Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. There are issues with merges of larval objects, though, for example: >> >> ``` >> MyValue v = UNSAFE.makePrivateBuffer(v0); >> for (int i = 0; i < 100; i++) {} >> return UNSAFE.finishPrivateBuffer(v); >> ``` >> >> But generally, the situation of merging larval objects are messy not just with larval objects created by `Unsafe` and I want to defer the fix to after #1405. > > Thanks, @merykitty. I think MEET over larval and non-larval should result in a larval value, so InlineTypeNode, which is the other input of the Phi node, should be buffered and treated as a larval object too, until we hit upon a finishPrivate buffer call that brings this merged oop value out of the larval state and re-materialize an InlineTypeNode. > > Kindly include this test with this patch. for now, we can add it to ProblemList.txt, which can be enabled after #1405 . > @jatin-bhateja A larval object created by `Unsafe` should adhere to all the rules that are put on a larval object created by the `new` bytecode. In the type verification system, each larval object has a distinct type being either `uninitializedThis` or `uninitialized(Offset)`. Meeting of a larval object with another larval object or with a non-larval object, thus, will result in a non-typed `reference`. As a result, the program is ill-formed if the merge is used. Please refer to [the JVMS, section 4.10.1](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1). Hi @merykitty , Larval transitions are either implicit, i.e. when a new value type instance is created, it begins in larval state and then post initilization transition out of larval state. The second kind of larval transition is explicit when we use UNSAFE APIs. While an object is in the larval state, it should not exist in scalarized form, thus, a larval object should be buffered; it still is a legitimate value instance, but because it is assigned a buffer location, we can say for now it has a pseudo-identity. The compiler cannot directly forward the field initialization of larvals to its user; a read of a field value of a larval object is similar to getfield, i.e., the compiler needs to explicitly load the field value at the corresponding field offset from the base. Given these semantics, a MEET b/w a larval and non-larval value should result in a laval value when mering the states of two basic blocks. I don't fully follow your comment on non-typed reference, as larval and non-larval instances are of value type. Your approach to buffer the value type instance within the makePrivate buffer looks correct to me. Please include the test case that I shared with the patch and add it to ProblemList.txt for now. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2763228402 From qamai at openjdk.org Sat Mar 29 15:15:21 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 29 Mar 2025 15:15:21 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> Message-ID: <3mb-E7aSlvDpVQrTXwbcdqU8A4sWgZKl6vz368XTnrc=.0045d024-a5c5-4c7d-9526-81780da9aea0@github.com> On Sat, 29 Mar 2025 08:16:25 GMT, Jatin Bhateja wrote: >>> @jatin-bhateja Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. There are issues with merges of larval objects, though, for example: >>> >>> ``` >>> MyValue v = UNSAFE.makePrivateBuffer(v0); >>> for (int i = 0; i < 100; i++) {} >>> return UNSAFE.finishPrivateBuffer(v); >>> ``` >>> >>> But generally, the situation of merging larval objects are messy not just with larval objects created by `Unsafe` and I want to defer the fix to after #1405. >> >> Thanks, @merykitty. I think MEET over larval and non-larval should result in a larval value, so InlineTypeNode, which is the other input of the Phi node, should be buffered and treated as a larval object too, until we hit upon a finishPrivate buffer call that brings this merged oop value out of the larval state and re-materialize an InlineTypeNode. >> >> Kindly include this test with this patch. for now, we can add it to ProblemList.txt, which can be enabled after #1405 . > >> @jatin-bhateja A larval object created by `Unsafe` should adhere to all the rules that are put on a larval object created by the `new` bytecode. In the type verification system, each larval object has a distinct type being either `uninitializedThis` or `uninitialized(Offset)`. Meeting of a larval object with another larval object or with a non-larval object, thus, will result in a non-typed `reference`. As a result, the program is ill-formed if the merge is used. Please refer to [the JVMS, section 4.10.1](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1). > > Hi @merykitty , > Larval transitions are either implicit, i.e. when a new value type instance is created, it begins in larval state and then post initilization transition out of larval state. The second kind of larval transition is explicit when we use UNSAFE APIs. > > While an object is in the larval state, it should not exist in scalarized form, thus, a larval object should be buffered; it still is a legitimate value instance, but because it is assigned a buffer location, we can say for now it has a pseudo-identity. The compiler cannot directly forward the field initialization of larvals to its user; a read of a field value of a larval object is similar to getfield, i.e., the compiler needs to explicitly load the field value at the corresponding field offset from the base. > > Given these semantics, a MEET b/w a larval and non-larval value should result in a laval value when mering the states of two basic blocks. I don't fully follow your comment on non-typed reference, as larval and non-larval instances are of value type. > Your approach to buffer the value type instance within the makePrivate buffer looks correct to me. Please include the test case that I shared with the patch and add it to ProblemList.txt for now. @jatin-bhateja Note that for the verifier, `uninitialized` and `MyValue` are completely different types that have their closest common ancestor being `reference` ([section 4.10.1.2](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1.2)). When a `new MyValue` instruction is executed, it pushes onto the stack a value of type `uninitialized(Offset)`, not a value of type `MyValue` ([section 4.10.1.9.new](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1.9.new)). The only action that can be done with a value of this type is to pass it into a constructor, after which all instances of type `uninitialized(Offset)` on the stack are replaced with the a value of type `MyValue` ([section 4.10.1.9.invokespecial](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1.9.invokespecial)). Inside the constructor `MyValue::`, the first parameter has its type being `uninitializedThis` ([section 4.10.1.6](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1.6)). There is nothing that can be done with a value of this type except passing it to a constructor of the superclass or executing `putfield` instructions. This value will be replaced by a value of type `MyValue` after the execution of the constructor of the superclass. `Unsafe` lets you bypass the restriction that final fields can only be set inside the constructor of its holder class. To achieve this, it lies to the bytecode verifier that you are having a value of type `MyValue` when in reality the returned value of `Unsafe::makePrivateBuffer` is a value of type `uninitialized`. However, you still must adhere to the rules that are put on the values of type `uninitialized`, such as: - You cannot pass a larval object to any method except to `Unsafe::putXXX` or `Unsafe::finishPrivateBuffer`, which are designed to allow working with larval objects. - You cannot load from a field of a larval object. - Meeting of an `uninitialized` with a `MyValue` results in a value of type `reference`, which you cannot possibly work with. As a result, you cannot assign to a non-larval local variable with a larval value. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2763479875 From jbhateja at openjdk.org Sat Mar 29 22:45:06 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 29 Mar 2025 22:45:06 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> Message-ID: On Sat, 29 Mar 2025 08:16:25 GMT, Jatin Bhateja wrote: >>> @jatin-bhateja Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. There are issues with merges of larval objects, though, for example: >>> >>> ``` >>> MyValue v = UNSAFE.makePrivateBuffer(v0); >>> for (int i = 0; i < 100; i++) {} >>> return UNSAFE.finishPrivateBuffer(v); >>> ``` >>> >>> But generally, the situation of merging larval objects are messy not just with larval objects created by `Unsafe` and I want to defer the fix to after #1405. >> >> Thanks, @merykitty. I think MEET over larval and non-larval should result in a larval value, so InlineTypeNode, which is the other input of the Phi node, should be buffered and treated as a larval object too, until we hit upon a finishPrivate buffer call that brings this merged oop value out of the larval state and re-materialize an InlineTypeNode. >> >> Kindly include this test with this patch. for now, we can add it to ProblemList.txt, which can be enabled after #1405 . > >> @jatin-bhateja A larval object created by `Unsafe` should adhere to all the rules that are put on a larval object created by the `new` bytecode. In the type verification system, each larval object has a distinct type being either `uninitializedThis` or `uninitialized(Offset)`. Meeting of a larval object with another larval object or with a non-larval object, thus, will result in a non-typed `reference`. As a result, the program is ill-formed if the merge is used. Please refer to [the JVMS, section 4.10.1](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1). > > Hi @merykitty , > Larval transitions are either implicit, i.e. when a new value type instance is created, it begins in larval state and then post initilization transition out of larval state. The second kind of larval transition is explicit when we use UNSAFE APIs. > > While an object is in the larval state, it should not exist in scalarized form, thus, a larval object should be buffered; it still is a legitimate value instance, but because it is assigned a buffer location, we can say for now it has a pseudo-identity. The compiler cannot directly forward the field initialization of larvals to its user; a read of a field value of a larval object is similar to getfield, i.e., the compiler needs to explicitly load the field value at the corresponding field offset from the base. > > Given these semantics, a MEET b/w a larval and non-larval value should result in a laval value when merging the states of two basic blocks. I don't fully follow your comment on non-typed reference, as larval and non-larval instances are of value type. > I think your approach to buffer the value type instance within the makePrivate buffer looks right to me. Please include the test case that I shared with the patch and add it to ProblemList.txt for now. > @jatin-bhateja Note that for the verifier, `uninitialized` and `MyValue` are completely different types that have their closest common ancestor being `reference` ([section 4.10.1.2](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1.2)). > > When a `new MyValue` instruction is executed, it pushes onto the stack a value of type `uninitialized(Offset)`, not a value of type `MyValue` ([section 4.10.1.9.new](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1.9.new)). The only action that can be done with a value of this type is to pass it into a constructor, after which all instances of type `uninitialized(Offset)` on the stack are replaced with the a value of type `MyValue` ([section 4.10.1.9.invokespecial](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1.9.invokespecial)). > > Inside the constructor `MyValue::`, the first parameter has its type being `uninitializedThis` ([section 4.10.1.6](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html#jvms-4.10.1.6)). There is nothing that can be done with a value of this type except passing it to a constructor of the superclass or executing `putfield` instructions. This value will be replaced by a value of type `MyValue` after the execution of the constructor of the superclass. > > `Unsafe` lets you bypass the restriction that final fields can only be set inside the constructor of its holder class. To achieve this, it lies to the bytecode verifier that you are having a value of type `MyValue` when in reality the returned value of `Unsafe::makePrivateBuffer` is a value of type `uninitialized`. However, you still must adhere to the rules that are put on the values of type `uninitialized`, such as: > > * You cannot pass a larval object to any method except to `Unsafe::putXXX` or `Unsafe::finishPrivateBuffer`, which are designed to allow working with larval objects. > * You cannot load from a field of a larval object. > * Meeting of an `uninitialized` with a `MyValue` results in a value of type `reference`, which you cannot possibly work with. As a result, you cannot assign to a non-larval local variable with a larval value. Hi @merykitty , >> * Meeting of an `uninitialized` with a `MyValue` results in a value of type `reference`, " Yes, I agree, this should be seen on the lines of a primitive (value) meeting an identity object (boxes), https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/01-background#:~:text=Java%E2%80%99s%20eight%20built%2Din%20primitive%20types%20are%20not%20objects%2C%20but%20they%20have%20boxes.%20When%20primitives%20want%20to%20interact%20in%20the%20world%20of%20objects%2C%20we%20transparently%20convert%20them%20to%20and%20from%20their%20corresponding%20box https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/01-background#:~:text=Objects%20have%20identity%2C%20whereas%20primitives%20do%20not%3B%20boxing%20is%20not%20able%20to%20fully%20paper%20over%20this%20gap.%20Each%20time%20we%20convert%20from%20Integer%20to%20int%20the%20identity%20is%20lost%2C%20and%20each%20time%20we%20convert%20from%20int%20to%20an%20Integer%2C%20a%20fresh%20(but%20accidental)%20identity%20is%20created Laraval value carries an identity while value (MyValue) does not, larval value still adheres to semantic restrictions of value type, i.e should not be used for synchronization, non-tearable etc. Thus, here at merge point, MyValue should be buffered, since this is MEETing a larval value so new oop (Phi) should be larval, similar to following ![image](https://github.com/user-attachments/assets/27bce951-353f-4492-8cda-605fa1b0c89c) >> "Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. " Do you think we should get the semantics documented in the specification first or let the spec evolve from the implementation you choose? ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764270053 From qamai at openjdk.org Sun Mar 30 03:01:14 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 30 Mar 2025 03:01:14 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> Message-ID: On Sat, 29 Mar 2025 22:41:26 GMT, Jatin Bhateja wrote: > Yes, I agree, this should be seen on the lines of a primitive (value) meeting an identity object (boxes), I think you are misunderstanding, the type `reference` here refers to a verification type that represents the most general reference type, it is even higher than `java.lang.Object`. From the JVMS: Verification type hierarchy: top ____________/____________ / \ / \ oneWord twoWord / | \ / \ / | \ / \ int float reference long double <--- meeting of a larval value and a non-larval value results in the `reference` type here / \ / _____________ / \ / \ uninitialized +------------------+ <--- larval objects have their verification type being `uninitialized` / \ | Java reference | <--- `java.lang.Object` and its subclasses are here / \ | type hierarchy | uninitializedThis uninitialized(Offset) +------------------+ | | null > Thus, here at merge point, MyValue should be buffered, since this is MEETing a larval value so new oop (Phi) should be larval, similar to following Note that this implicit boxing and unboxing only happens at the language level, `javac` will automatically translate `ret = genInt(val)` into `ret = Integer.valueOf(genInt(val))`. So, at the VM level, we do not ever encounter a meet of a `java.lang.Integer` and an `int`. As a result, C2 does not have to take auto boxing and unboxing into consideration. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764355420 From qamai at openjdk.org Sun Mar 30 05:54:42 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 30 Mar 2025 05:54:42 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 14:14:12 GMT, Quan Anh Mai wrote: >> Hi, >> >> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. >> >> Please take a look and review this PR, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > comments, set and unset larval bit To be clear, your second example is irrelevant also because a `java.lang.Integer` is not a larval `int`, it is a fully constructed `int` and its identity comes from the lack of value classes, which will eventually be removed once value classes land. A more direct translation of your first example to non-unsafe would be something like: p = new Point; p.(val, val + 10); if (val > 5000) { q = new Point; q.f1 = p.f1; q.f2 = p.f2; p = q; p.f1 = val + 10; } last_hash = p.hashCode(); if (val > 5000) { p.(); } return p; And I am sure the verifier would reject a bytecode sequence like this. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764399874 From jbhateja at openjdk.org Sun Mar 30 07:19:17 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 30 Mar 2025 07:19:17 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics In-Reply-To: References: <6kddSMBj6ydo7GvQJbaNTp56amyVuSWUbj9zf52TuAQ=.7ecb72b4-389f-47a5-bd24-f15bd012d922@github.com> Message-ID: On Sun, 30 Mar 2025 02:57:54 GMT, Quan Anh Mai wrote: > > Yes, I agree, this should be seen on the lines of a primitive (value) meeting an identity object (boxes), > > I think you are misunderstanding, the type `reference` here refers to a verification type that represents the most general reference type, it is even higher than `java.lang.Object`. From the JVMS: > > ``` > Verification type hierarchy: > > top > ____________/____________ > / \ > / \ > oneWord twoWord > / | \ / \ > / | \ / \ > int float reference long double <--- meeting of a larval value and a non-larval value results in the `reference` type here > / \ > / _____________ > / \ > / \ > uninitialized +------------------+ <--- larval objects have their verification type being `uninitialized` > / \ | Java reference | <--- `java.lang.Object` and its subclasses are here > / \ | type hierarchy | > uninitializedThis uninitialized(Offset) +------------------+ > | > | > null > ``` > > > Thus, here at merge point, MyValue should be buffered, since this is MEETing a larval value so new oop (Phi) should be larval, similar to following > > Note that this implicit boxing and unboxing only happens at the language level, `javac` will automatically translate `ret = genInt(val)` into `ret = Integer.valueOf(genInt(val))`. So, at the VM level, we do not ever encounter a meet of a `java.lang.Integer` and an `int`. As a result, C2 does not have to take auto boxing and unboxing into consideration. Exactly, MEET b/w two reference type results in a type which is LCA of both, and in the worst cast it could be j.l.o Here, we are dealing with larval and non-larval values, which are different representations of same value type instance. Our discussion context is around the VM model as language semantics are clear on make/finishPrivate buffer semantics. In the above example, I drew an analogy b/w boxes as larval values VS primitives as value type instances. public static Point micro(int val) throws Exception { Point p = new Point(val, val + 10); if (val > 50000) { p = UNSAFE.makePrivateBuffer(p); UNSAFE.putInt(p, UNSAFE.objectFieldOffset(Point.class.getDeclaredField("f1")), val + 10); } last_hash = p.hashCode(); if (val > 50000) { p = UNSAFE.finishPrivateBuffer(p); } return p; } >> "Merging a larval object and a non-larval object is undefined behaviour, and crashing should be an acceptable outcome then. " Please mention your strategy to handle the above case and what you mean by crash as an acceptable outcome. We can think through this as address this as a larger fix in PR 1405, for now I am ok with you fix and if can checkin the test and add it to ProblemList.txt ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764424519 From qamai at openjdk.org Sun Mar 30 07:37:43 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 30 Mar 2025 07:37:43 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 14:14:12 GMT, Quan Anh Mai wrote: >> Hi, >> >> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. >> >> Please take a look and review this PR, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > comments, set and unset larval bit > Exactly, MEET b/w two reference type results in a type which is LCA of both, and in the worst case it could be j.l.o No, it is wrong, from the verification type system, the highest reference type in the type hierarchy is `reference`, which comprises `java.lang.Object` and larval objects (`uninitialized`). Larval objects have their types being subtypes of `uninitialized` and non-larval objects have their types being subtypes of `java.lang.Object`. These 2 are separate under the bytecode verifier. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764430255 From jbhateja at openjdk.org Sun Mar 30 08:02:40 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 30 Mar 2025 08:02:40 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: On Sun, 30 Mar 2025 07:33:59 GMT, Quan Anh Mai wrote: > > Exactly, MEET b/w two reference type results in a type which is LCA of both, and in the worst case it could be j.l.o > > No, it is wrong, from the verification type system, the highest reference type in the type hierarchy is `reference`, which comprises `java.lang.Object` and larval objects (`uninitialized`). Larval objects have their types being subtypes of `uninitialized` and non-larval objects have their types being subtypes of `java.lang.Object`. These 2 are separate under the bytecode verifier. Bytecode verification should be same for larval and non-larval objects, you are mixing explicit and implicit larval here which is where the confusion arises. MEET operation semantics are in accordance with semantics defined in following logic https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/type.cpp#L4734 With UNSAFE we explicit transition the value to a mutable state and thus need to handle them at merge point if it meets a non-larval value. Let's think through this and address it as your larger fix for https://github.com/openjdk/valhalla/pull/1405 >> Crashing is an acceptable outcome when you are dealing with Unsafe. Using Unsafe means you are lying to the VM about the >> actual thing you are doing and have to rely on your own verification to make sure the program is valid. If the program using >> Unsafe is invalid (e.g. writing arbitrary value to a reference field), there is nothing the VM can do. Crash occurs at the state merge point. If you run following test with C1 compiler it works fine. So we need to address this crash in C2 compiler. https://github.com/user-attachments/files/19501609/unsafe_access.txt CPROMPT>java --enable-preview --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED -XX:TieredStopAtLevel=3 -cp . unsafe_access 10001399990 For now I am ok with your fix, please also emit the IR to set larval bit in mark word during allocation expansion. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764438050 From qamai at openjdk.org Sun Mar 30 08:27:28 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sun, 30 Mar 2025 08:27:28 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: On Sun, 30 Mar 2025 07:59:11 GMT, Jatin Bhateja wrote: > Bytecode verification should be same for larval and non-larval objects, you are mixing explicit and implicit larval here which is where the confusion arises. I have addressed this point above: "`Unsafe` lets you bypass the restriction that final fields can only be set inside the constructor of its holder class. To achieve this, it lies to the bytecode verifier that you are having a value of type `MyValue` when in reality the returned value of `Unsafe::makePrivateBuffer` is a value of type `uninitialized`. However, you still must adhere to the rules that are put on the values of type `uninitialized`". Bytecode verification being the same for `Unsafe::makePrivateBuffer` and non-larval objects is due to the fact that you are lying to the bytecode verifier when using `Unsafe`, not because they are fundamentally the same. Explicit and implicit larval objects should be fundamentally the same. > Crash occurs at the state merge point. If you run following test with C1 compiler it works fine. So we need to address this crash in C2 compiler. Undefined behaviour means that any behaviour is an acceptable behaviour. C1 can execute just fine and it is an acceptable outcome, C2 crashes and it is also an acceptable outcome. > For now I am ok with your fix, please also emit the IR to set larval bit in mark word during allocation expansion. I believe setting `AllocateNode._larval` to true will make the expansion include setting the larval bit. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764447663 From jbhateja at openjdk.org Sun Mar 30 13:47:41 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 30 Mar 2025 13:47:41 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 14:14:12 GMT, Quan Anh Mai wrote: >> Hi, >> >> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. >> >> Please take a look and review this PR, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > comments, set and unset larval bit src/hotspot/share/opto/library_call.cpp line 2669: > 2667: const Type* type = gvn().type(value); > 2668: if (!type->is_inlinetypeptr()) { > 2669: C->record_method_not_compilable("value passed to Unsafe::makePrivateBuffer is not of a constant value type"); Suggestion: C->record_method_not_compilable("Argument passed to Unsafe::makePrivateBuffer is not a concrete value type"); ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/1406#discussion_r2020151549 From jbhateja at openjdk.org Sun Mar 30 13:47:41 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 30 Mar 2025 13:47:41 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: On Sun, 30 Mar 2025 08:25:10 GMT, Quan Anh Mai wrote: > Undefined behaviour means that any behaviour is an acceptable behaviour. C1 can execute just fine and it is an acceptable outcome, C2 crashes and it is also an acceptable outcome. >From user standpoint be it C1 or C2 compiler, JVM needs to be consistent w.r.t to undefined behavior and crash is not acceptable. > I believe setting `AllocateNode._larval` to true will make the expansion include setting the larval bit. Yes, AllocateNode::make_ideal_mark handles this. >> No, it is wrong, from the verification type system, the highest reference type in the type hierarchy is reference, which comprises java.lang.Object and larval objects (uninitialized). Larval objects have their types being subtypes of uninitialized and non-larval objects have their types being subtypes of java.lang.Object. These 2 are separate under the bytecode verifier. I see your point , but the contention here is that value types have a default value see https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/oops/instanceKlass.cpp#L1459 So, technically they don't qualify as uninitialized objects. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764569554 From jbhateja at openjdk.org Sun Mar 30 13:52:45 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 30 Mar 2025 13:52:45 GMT Subject: [lworld] RFR: 8352647: [lworld] Remove larval InlineTypeNode in Unsafe intrinsics [v2] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 14:14:12 GMT, Quan Anh Mai wrote: >> Hi, >> >> As a step of #1405, I would like to remove the usage of larval value objects in `Unsafe` intrinsics. This patch also tries to make sure that `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer` are always inlined, so that larval objects do not cross call boundaries except for invoking object constructors. >> >> Please take a look and review this PR, thanks a lot. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > comments, set and unset larval bit Not asking to address in this patch, but what if we return a larval value to caller ? i.e. value returned by makePrivateBuffer is returned from a method since the return type will still be a concrete value type; hence, the caller will expect to receive the arguments in scalarized form. https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/graphKit.cpp#L2009 ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1406#issuecomment-2764572206