From xgong at openjdk.org Thu Mar 2 09:07:29 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 2 Mar 2023 09:07:29 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer Message-ID: When calling Unsafe.finishPrivateBuffer(), JVM crashes with following assertion failure: Internal Error (/mnt/local/code/valhalla/src/hotspot/share/prims/unsafe.cpp:388), pid=29517, tid=29518 assert(v->mark().is_larval_state()) failed: must be a larval value JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-05e4d0dba) Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-05e4d0dba, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) Problematic frame: V [[libjvm.so](http://libjvm.so/)+0x1a92a64] Unsafe_FinishPrivateBuffer+0xc0 The assertion is used to check whether the input value is in larval state. Usually this method is called after `Unsafe.makePrivateBuffer()`, which will create a new oop and set it to larval state. If everything works fine, the above assertion won't fail. But the issue happens if all the fields of the input value object of `Unsafe.makePrivateBuffer()` are the relative java default values (i.e. `0`). The root cause is the C2 compiler will optimize the new buffered oop to the default oop for such value object, and the larval state is missed during the optimization. Marking the larval bit of the optimized oop can fix the issue. ------------- Commit messages: - 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer Changes: https://git.openjdk.org/valhalla/pull/828/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303416 Stats: 114 lines in 2 files changed: 108 ins; 0 del; 6 mod Patch: https://git.openjdk.org/valhalla/pull/828.diff Fetch: git fetch https://git.openjdk.org/valhalla pull/828/head:pull/828 PR: https://git.openjdk.org/valhalla/pull/828 From thartmann at openjdk.org Thu Mar 2 09:36:32 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 2 Mar 2023 09:36:32 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer In-Reply-To: References: Message-ID: <7wqt3r6WVWTrS1jvG6NY_8UYW800UxGcCqeuegikb2Y=.d3a757b0-2d0b-445d-976f-133dbc732f24@github.com> On Thu, 2 Mar 2023 09:00:41 GMT, Xiaohong Gong wrote: > When calling Unsafe.finishPrivateBuffer(), JVM crashes with following > assertion failure: > > > Internal Error (/mnt/local/code/valhalla/src/hotspot/share/prims/unsafe.cpp:388), pid=29517, tid=29518 > assert(v->mark().is_larval_state()) failed: must be a larval value > > JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-05e4d0dba) > Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-05e4d0dba, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) > Problematic frame: > V [[libjvm.so](http://libjvm.so/)+0x1a92a64] Unsafe_FinishPrivateBuffer+0xc0 > > The assertion is used to check whether the input value is in larval > state. Usually this method is called after `Unsafe.makePrivateBuffer()`, > which will create a new oop and set it to larval state. If everything > works fine, the above assertion won't fail. But the issue happens if > all the fields of the input value object of `Unsafe.makePrivateBuffer()` > are the relative java default values (i.e. `0`). The root cause is the > C2 compiler will optimize the new buffered oop to the default oop for > such value object, and the larval state is missed during the optimization. > Marking the larval bit of the optimized oop can fix the issue. I don't think this is correct, as it would overwrite the larval state of the default oop/buffer of that type. Right? ------------- Changes requested by thartmann (Committer). PR: https://git.openjdk.org/valhalla/pull/828 From xgong at openjdk.org Thu Mar 2 09:51:30 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 2 Mar 2023 09:51:30 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer In-Reply-To: <7wqt3r6WVWTrS1jvG6NY_8UYW800UxGcCqeuegikb2Y=.d3a757b0-2d0b-445d-976f-133dbc732f24@github.com> References: <7wqt3r6WVWTrS1jvG6NY_8UYW800UxGcCqeuegikb2Y=.d3a757b0-2d0b-445d-976f-133dbc732f24@github.com> Message-ID: On Thu, 2 Mar 2023 09:33:22 GMT, Tobias Hartmann wrote: > I don't think this is correct, as it would overwrite the larval state of the default oop/buffer of that type. Right? Yes, it would. And the larval state will be set back after calling "finishLarvalBuffer". I was thinking the whole progress happens in a single thread. But regarding to the default oop, changing larval state of it seems not right in multi-thread progress. So how about disgarding the GVN optimization of the `InlineTypeNode` if a private buffer is allocated and marked larval for it? ------------- PR: https://git.openjdk.org/valhalla/pull/828 From thartmann at openjdk.org Thu Mar 2 10:04:38 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 2 Mar 2023 10:04:38 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer In-Reply-To: References: <7wqt3r6WVWTrS1jvG6NY_8UYW800UxGcCqeuegikb2Y=.d3a757b0-2d0b-445d-976f-133dbc732f24@github.com> Message-ID: On Thu, 2 Mar 2023 09:49:04 GMT, Xiaohong Gong wrote: > So how about disgarding the GVN optimization of the InlineTypeNode if a private buffer is allocated and marked larval for it? Yes, I think that would make sense, although it's still an incomplete fix until JDK-8239003 is in. ------------- PR: https://git.openjdk.org/valhalla/pull/828 From xgong at openjdk.org Fri Mar 3 01:03:33 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 3 Mar 2023 01:03:33 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer In-Reply-To: References: <7wqt3r6WVWTrS1jvG6NY_8UYW800UxGcCqeuegikb2Y=.d3a757b0-2d0b-445d-976f-133dbc732f24@github.com> Message-ID: <9QNi35uRq9l8vpI9O7MkuJ_Zw8Xu8KtL3xnxP7ryT-Q=.6a466eda-97ae-418f-9155-36a179324f8d@github.com> On Thu, 2 Mar 2023 10:01:41 GMT, Tobias Hartmann wrote: > > So how about disgarding the GVN optimization of the InlineTypeNode if a private buffer is allocated and marked larval for it? > > Yes, I think that would make sense, although it's still an incomplete fix until JDK-8239003 is in. Yes, agree! I will update the patch once I finish our internal testing. Thanks! ------------- PR: https://git.openjdk.org/valhalla/pull/828 From xgong at openjdk.org Fri Mar 3 08:37:39 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 3 Mar 2023 08:37:39 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer [v2] In-Reply-To: References: Message-ID: > When calling Unsafe.finishPrivateBuffer(), JVM crashes with following > assertion failure: > > > Internal Error (/mnt/local/code/valhalla/src/hotspot/share/prims/unsafe.cpp:388), pid=29517, tid=29518 > assert(v->mark().is_larval_state()) failed: must be a larval value > > JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-05e4d0dba) > Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-05e4d0dba, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) > Problematic frame: > V [[libjvm.so](http://libjvm.so/)+0x1a92a64] Unsafe_FinishPrivateBuffer+0xc0 > > The assertion is used to check whether the input value is in larval > state. Usually this method is called after `Unsafe.makePrivateBuffer()`, > which will create a new oop and set it to larval state. If everything > works fine, the above assertion won't fail. But the issue happens if > all the fields of the input value object of `Unsafe.makePrivateBuffer()` > are the relative java default values (i.e. `0`). The root cause is the > C2 compiler will optimize the new buffered oop to the default oop for > such value object, and the larval state is missed during the optimization. > Marking the larval bit of the optimized oop can fix the issue. Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Revert the larval bit setting change, and discard the default oop replacement for larval state oop ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/828/files - new: https://git.openjdk.org/valhalla/pull/828/files/d3820a09..0629b9bb Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=828&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=828&range=00-01 Stats: 33 lines in 2 files changed: 15 ins; 11 del; 7 mod Patch: https://git.openjdk.org/valhalla/pull/828.diff Fetch: git fetch https://git.openjdk.org/valhalla pull/828/head:pull/828 PR: https://git.openjdk.org/valhalla/pull/828 From xgong at openjdk.org Fri Mar 3 08:38:14 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 3 Mar 2023 08:38:14 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer In-Reply-To: References: Message-ID: On Thu, 2 Mar 2023 09:00:41 GMT, Xiaohong Gong wrote: > When calling Unsafe.finishPrivateBuffer(), JVM crashes with following > assertion failure: > > > Internal Error (/mnt/local/code/valhalla/src/hotspot/share/prims/unsafe.cpp:388), pid=29517, tid=29518 > assert(v->mark().is_larval_state()) failed: must be a larval value > > JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-05e4d0dba) > Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-05e4d0dba, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) > Problematic frame: > V [[libjvm.so](http://libjvm.so/)+0x1a92a64] Unsafe_FinishPrivateBuffer+0xc0 > > The assertion is used to check whether the input value is in larval > state. Usually this method is called after `Unsafe.makePrivateBuffer()`, > which will create a new oop and set it to larval state. If everything > works fine, the above assertion won't fail. But the issue happens if > all the fields of the input value object of `Unsafe.makePrivateBuffer()` > are the relative java default values (i.e. `0`). The root cause is the > C2 compiler will optimize the new buffered oop to the default oop for > such value object, and the larval state is missed during the optimization. > Marking the larval bit of the optimized oop can fix the issue. Hi, The new commit reverts the larval state setting to the default oop. As consider the default oop is immutable, the new private buffered oop with larval state is not right to be optimized to the default oop. Since we know its fields will be changed after then. So the new commit just discards the optimization of the inline type if its oop is an allocated buffer with larval state. Note that current version is still an incomplete fix until [JDK-8239003](https://bugs.openjdk.java.net/browse/JDK-8239003) in. Please feel free to review this PR. Thanks a lot in advance! Best Regards, Xiaohong ------------- PR: https://git.openjdk.org/valhalla/pull/828 From thartmann at openjdk.org Fri Mar 3 09:37:05 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 3 Mar 2023 09:37:05 GMT Subject: [lworld] RFR: 8293800: [lworld] Remove TypeInlineType and related code Message-ID: After [JDK-8293542](https://bugs.openjdk.org/browse/JDK-8293542), we only use `TypeInlineType` for flat arrays and for the calling convention. This large cleanup removes it and uses a pointer type instead, which significantly reduces the complexity of the implementation. Thanks to Roland, for helping with fixing some C2 type system issues! Best regards, Tobias ------------- Commit messages: - offset fix - Fixed wrong bug number - Merge - Improved TypeAryKlassPtr::dump2 - Fixed incorrect speculation on varargs Object array being not null-free - Removed some ToDos - More fixes - Small fix - More refactoring - More cleanups - ... and 1 more: https://git.openjdk.org/valhalla/compare/5e871a47...ccbc1d47 Changes: https://git.openjdk.org/valhalla/pull/829/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=829&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293800 Stats: 580 lines in 15 files changed: 48 ins; 403 del; 129 mod Patch: https://git.openjdk.org/valhalla/pull/829.diff Fetch: git fetch https://git.openjdk.org/valhalla pull/829/head:pull/829 PR: https://git.openjdk.org/valhalla/pull/829 From thartmann at openjdk.org Mon Mar 6 18:43:54 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 6 Mar 2023 18:43:54 GMT Subject: [lworld] Integrated: 8293800: [lworld] Remove TypeInlineType and related code In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 09:28:51 GMT, Tobias Hartmann wrote: > After [JDK-8293542](https://bugs.openjdk.org/browse/JDK-8293542), we only use `TypeInlineType` for flat arrays and for the calling convention. This large cleanup removes it and uses a pointer type instead, which significantly reduces the complexity of the implementation. > > Thanks to Roland, for helping with fixing some C2 type system issues! > > Best regards, > Tobias This pull request has now been integrated. Changeset: 0baf5d1e Author: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/0baf5d1e66045f648bc7312d2802ad962960cff2 Stats: 580 lines in 15 files changed: 48 ins; 403 del; 129 mod 8293800: [lworld] Remove TypeInlineType and related code Co-authored-by: Roland Westrelin ------------- PR: https://git.openjdk.org/valhalla/pull/829 From thartmann at openjdk.org Tue Mar 7 09:03:05 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 7 Mar 2023 09:03:05 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer [v2] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 08:37:39 GMT, Xiaohong Gong wrote: >> When calling Unsafe.finishPrivateBuffer(), JVM crashes with following >> assertion failure: >> >> >> Internal Error (/mnt/local/code/valhalla/src/hotspot/share/prims/unsafe.cpp:388), pid=29517, tid=29518 >> assert(v->mark().is_larval_state()) failed: must be a larval value >> >> JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-05e4d0dba) >> Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-05e4d0dba, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) >> Problematic frame: >> V [[libjvm.so](http://libjvm.so/)+0x1a92a64] Unsafe_FinishPrivateBuffer+0xc0 >> >> The assertion is used to check whether the input value is in larval >> state. Usually this method is called after `Unsafe.makePrivateBuffer()`, >> which will create a new oop and set it to larval state. If everything >> works fine, the above assertion won't fail. But the issue happens if >> all the fields of the input value object of `Unsafe.makePrivateBuffer()` >> are the relative java default values (i.e. `0`). The root cause is the >> C2 compiler will optimize the new buffered oop to the default oop for >> such value object, and the larval state is missed during the optimization. >> Marking the larval bit of the optimized oop can fix the issue. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Revert the larval bit setting change, and discard the default oop replacement for larval state oop Looks good to me! ------------- Marked as reviewed by thartmann (Committer). PR: https://git.openjdk.org/valhalla/pull/828 From xgong at openjdk.org Tue Mar 7 09:03:06 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 7 Mar 2023 09:03:06 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer [v2] In-Reply-To: References: <7wqt3r6WVWTrS1jvG6NY_8UYW800UxGcCqeuegikb2Y=.d3a757b0-2d0b-445d-976f-133dbc732f24@github.com> Message-ID: <4PfMLXNFR7HfXkaTp7AQVM3bzuH3kQH5fhPI7-z7UXQ=.16229259-7510-404d-8dc8-e9f989d0c8a6@github.com> On Thu, 2 Mar 2023 10:01:41 GMT, Tobias Hartmann wrote: >>> I don't think this is correct, as it would overwrite the larval state of the default oop/buffer of that type. Right? >> >> Yes, it would. And the larval state will be set back after calling "finishLarvalBuffer". I was thinking the whole progress happens in a single thread. But regarding to the default oop, changing larval state of it seems not right in multi-thread progress. So how about disgarding the GVN optimization of the `InlineTypeNode` if a private buffer is allocated and marked larval for it? > >> So how about disgarding the GVN optimization of the InlineTypeNode if a private buffer is allocated and marked larval for it? > > Yes, I think that would make sense, although it's still an incomplete fix until JDK-8239003 is in. Thanks for the review @TobiHartmann ! ------------- PR: https://git.openjdk.org/valhalla/pull/828 From thartmann at openjdk.org Tue Mar 7 17:17:03 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 7 Mar 2023 17:17:03 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer [v2] In-Reply-To: References: Message-ID: On Fri, 3 Mar 2023 08:37:39 GMT, Xiaohong Gong wrote: >> When calling Unsafe.finishPrivateBuffer(), JVM crashes with following >> assertion failure: >> >> >> Internal Error (/mnt/local/code/valhalla/src/hotspot/share/prims/unsafe.cpp:388), pid=29517, tid=29518 >> assert(v->mark().is_larval_state()) failed: must be a larval value >> >> JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-05e4d0dba) >> Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-05e4d0dba, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) >> Problematic frame: >> V [[libjvm.so](http://libjvm.so/)+0x1a92a64] Unsafe_FinishPrivateBuffer+0xc0 >> >> The assertion is used to check whether the input value is in larval >> state. Usually this method is called after `Unsafe.makePrivateBuffer()`, >> which will create a new oop and set it to larval state. If everything >> works fine, the above assertion won't fail. But the issue happens if >> all the fields of the input value object of `Unsafe.makePrivateBuffer()` >> are the relative java default values (i.e. `0`). The root cause is the >> C2 compiler will optimize the new buffered oop to the default oop for >> such value object, and the larval state is missed during the optimization. >> Marking the larval bit of the optimized oop can fix the issue. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Revert the larval bit setting change, and discard the default oop replacement for larval state oop One review is sufficient for this and testing passed. Feel free to integrate. ------------- PR: https://git.openjdk.org/valhalla/pull/828 From mchung at openjdk.org Wed Mar 8 21:16:48 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 8 Mar 2023 21:16:48 GMT Subject: [lworld] RFR: 8271959: [lworld] Convert Optional and VBS classes to value class [v6] In-Reply-To: References: Message-ID: On Mon, 27 Feb 2023 23:38:13 GMT, Roger Riggs wrote: >> Make copies of classes to be made value classes in src/java.base/valueclasses/classes >> Modify CompileJavaModules.gmk to trigger builds of values classes and construct a .jar for each module. >> Add the jar files to $JAVA_HOME/lib/valueclasses/-valueclasses.jar >> >> Modify hotspot arguments.cpp to scan for patch jar files when --enable-preview and -XX:+EnableValhalla. >> For each jar, the equivalent of --patch-module = is added and the system properties `jdk.module.patch.` include jar file paths. > > Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: > > - Revert unnecessary removals of super() in java.time.zone > - Revert unnecessary removals of super() in java.time.format classes. LGTM ------------- Marked as reviewed by mchung (Committer). PR: https://git.openjdk.org/valhalla/pull/816 From rriggs at openjdk.org Wed Mar 8 22:02:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Mar 2023 22:02:43 GMT Subject: [lworld] Integrated: 8271959: [lworld] Convert Optional and VBS classes to value class In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 01:38:03 GMT, Roger Riggs wrote: > Make copies of classes to be made value classes in src/java.base/valueclasses/classes > Modify CompileJavaModules.gmk to trigger builds of values classes and construct a .jar for each module. > Add the jar files to $JAVA_HOME/lib/valueclasses/-valueclasses.jar > > Modify hotspot arguments.cpp to scan for patch jar files when --enable-preview and -XX:+EnableValhalla. > For each jar, the equivalent of --patch-module = is added and the system properties `jdk.module.patch.` include jar file paths. This pull request has now been integrated. Changeset: 4f71167c Author: Roger Riggs URL: https://git.openjdk.org/valhalla/commit/4f71167ca2eacc3330e1a4b709c482c3d0bd36e5 Stats: 379 lines in 15 files changed: 328 ins; 22 del; 29 mod 8271959: [lworld] Convert Optional and VBS classes to value class Reviewed-by: erikj, mchung ------------- PR: https://git.openjdk.org/valhalla/pull/816 From xgong at openjdk.org Mon Mar 13 05:43:49 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 13 Mar 2023 05:43:49 GMT Subject: [lworld] RFR: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer [v2] In-Reply-To: References: Message-ID: On Tue, 7 Mar 2023 17:14:18 GMT, Tobias Hartmann wrote: > One review is sufficient for this and testing passed. Feel free to integrate. Thanks for the remainding! I will integrate it soon. ------------- PR: https://git.openjdk.org/valhalla/pull/828 From xgong at openjdk.org Mon Mar 13 15:21:13 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 13 Mar 2023 15:21:13 GMT Subject: [lworld] Integrated: 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer In-Reply-To: References: Message-ID: <6dzCju3GKguhQOu34nrvGco2s9TdKpUYwp8LTbKjsX4=.c0d56add-283f-4127-9ea3-6ec67e0796ec@github.com> On Thu, 2 Mar 2023 09:00:41 GMT, Xiaohong Gong wrote: > When calling Unsafe.finishPrivateBuffer(), JVM crashes with following > assertion failure: > > > Internal Error (/mnt/local/code/valhalla/src/hotspot/share/prims/unsafe.cpp:388), pid=29517, tid=29518 > assert(v->mark().is_larval_state()) failed: must be a larval value > > JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-05e4d0dba) > Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-05e4d0dba, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) > Problematic frame: > V [[libjvm.so](http://libjvm.so/)+0x1a92a64] Unsafe_FinishPrivateBuffer+0xc0 > > The assertion is used to check whether the input value is in larval > state. Usually this method is called after `Unsafe.makePrivateBuffer()`, > which will create a new oop and set it to larval state. If everything > works fine, the above assertion won't fail. But the issue happens if > all the fields of the input value object of `Unsafe.makePrivateBuffer()` > are the relative java default values (i.e. `0`). The root cause is the > C2 compiler will optimize the new buffered oop to the default oop for > such value object, and the larval state is missed during the optimization. > Marking the larval bit of the optimized oop can fix the issue. This pull request has now been integrated. Changeset: d8e7d2eb Author: Xiaohong Gong Committer: Tobias Hartmann URL: https://git.openjdk.org/valhalla/commit/d8e7d2eb3837c6b18a2c88955ae2ab89667889bb Stats: 113 lines in 3 files changed: 112 ins; 0 del; 1 mod 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/828 From rriggs at openjdk.org Mon Mar 13 22:22:08 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Mar 2023 22:22:08 GMT Subject: [lworld] RFR: 8304084: [lworld] Fix copyright text in GensrcValueClasses.gmk Message-ID: <7r3Q1iVJBkKuNW-AfXJPi47QmRLwj0R8p64OqEnMm1g=.46c80a2e-a3b3-4caa-b35a-6ce01644b1f7@github.com> Correct incomplete copyright. ------------- Commit messages: - 8304084: [lworld] Fix copyright text in GensrcValueClasses.gmk Changes: https://git.openjdk.org/valhalla/pull/830/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=830&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304084 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/830.diff Fetch: git fetch https://git.openjdk.org/valhalla pull/830/head:pull/830 PR: https://git.openjdk.org/valhalla/pull/830 From mchung at openjdk.org Mon Mar 13 22:37:08 2023 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 13 Mar 2023 22:37:08 GMT Subject: [lworld] RFR: 8304084: [lworld] Fix copyright text in GensrcValueClasses.gmk In-Reply-To: <7r3Q1iVJBkKuNW-AfXJPi47QmRLwj0R8p64OqEnMm1g=.46c80a2e-a3b3-4caa-b35a-6ce01644b1f7@github.com> References: <7r3Q1iVJBkKuNW-AfXJPi47QmRLwj0R8p64OqEnMm1g=.46c80a2e-a3b3-4caa-b35a-6ce01644b1f7@github.com> Message-ID: On Mon, 13 Mar 2023 22:16:33 GMT, Roger Riggs wrote: > Correct incomplete copyright. Marked as reviewed by mchung (Committer). ------------- PR: https://git.openjdk.org/valhalla/pull/830 From rriggs at openjdk.org Mon Mar 13 22:50:14 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Mar 2023 22:50:14 GMT Subject: [lworld] Integrated: 8304084: [lworld] Fix copyright text in GensrcValueClasses.gmk In-Reply-To: <7r3Q1iVJBkKuNW-AfXJPi47QmRLwj0R8p64OqEnMm1g=.46c80a2e-a3b3-4caa-b35a-6ce01644b1f7@github.com> References: <7r3Q1iVJBkKuNW-AfXJPi47QmRLwj0R8p64OqEnMm1g=.46c80a2e-a3b3-4caa-b35a-6ce01644b1f7@github.com> Message-ID: On Mon, 13 Mar 2023 22:16:33 GMT, Roger Riggs wrote: > Correct incomplete copyright. This pull request has now been integrated. Changeset: a85a539a Author: Roger Riggs URL: https://git.openjdk.org/valhalla/commit/a85a539a59fca31922904e5a1725bcc47a09ef69 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8304084: [lworld] Fix copyright text in GensrcValueClasses.gmk Reviewed-by: mchung ------------- PR: https://git.openjdk.org/valhalla/pull/830 From rriggs at openjdk.org Tue Mar 14 18:57:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Mar 2023 18:57:06 GMT Subject: [lworld] RFR: 8304168: Modify CDS tests to disable -XX:-EnableValhalla with --enable-preview Message-ID: When --enable-preview is true, the patching of some java.base classes as value classes disables CDS. Subsequently the CDS tests fail. For a CDS and a JDI test, disable Valhalla when --enable-preview is set so java.base is not patched with value classes. ------------- Commit messages: - Modify CDS tests to disable -XX:-EnableValhalla with --enable-preview Changes: https://git.openjdk.org/valhalla/pull/832/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=832&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304168 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/832.diff Fetch: git fetch https://git.openjdk.org/valhalla pull/832/head:pull/832 PR: https://git.openjdk.org/valhalla/pull/832 From mchung at openjdk.org Tue Mar 14 19:10:28 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 14 Mar 2023 19:10:28 GMT Subject: [lworld] RFR: 8304168: Modify CDS tests to disable -XX:-EnableValhalla with --enable-preview In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 18:50:11 GMT, Roger Riggs wrote: > When --enable-preview is true, the patching of some java.base classes as value classes disables CDS. > Subsequently the CDS tests fail. > > For a CDS and a JDI test, disable Valhalla when --enable-preview is set so java.base is not patched with value classes. Is this just a temporary fix? We would need debugging to work with `--enable-preview`. For CDS, is it possible to have an alternative shared archive with the value classes and special case for `--enable-preview`? ------------- PR: https://git.openjdk.org/valhalla/pull/832 From rriggs at openjdk.org Tue Mar 14 20:34:07 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Mar 2023 20:34:07 GMT Subject: [lworld] RFR: 8304168: [lword] CDS tests fail with --enable-preview patched value classes In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 19:07:19 GMT, Mandy Chung wrote: > Is this just a temporary fix? We would need debugging to work with `--enable-preview`. For CDS, is it possible to have an alternative shared archive with the value classes and special case for `--enable-preview`? Temporary in the sense that until value classes are fully integrated, some mechanism is needed to include them when --enable-preview or not. And that optionality will need to work with CDS in some yet to be determined fashion. ------------- PR: https://git.openjdk.org/valhalla/pull/832 From rriggs at openjdk.org Wed Mar 15 19:29:07 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 15 Mar 2023 19:29:07 GMT Subject: [lworld] RFR: 8304168: [lword] CDS tests fail with --enable-preview patched value classes [v2] In-Reply-To: References: Message-ID: > When --enable-preview is true, the patching of some java.base classes as value classes disables CDS. > Subsequently the CDS tests fail. > > For a CDS, disable Valhalla when --enable-preview is set so java.base is not patched with value classes. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revert change to jdi TestScaffold ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/832/files - new: https://git.openjdk.org/valhalla/pull/832/files/f735b665..787b4456 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=832&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=832&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/832.diff Fetch: git fetch https://git.openjdk.org/valhalla pull/832/head:pull/832 PR: https://git.openjdk.org/valhalla/pull/832 From rriggs at openjdk.org Wed Mar 15 19:29:08 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 15 Mar 2023 19:29:08 GMT Subject: [lworld] RFR: 8304168: [lword] CDS tests fail with --enable-preview patched value classes In-Reply-To: References: Message-ID: On Tue, 14 Mar 2023 18:50:11 GMT, Roger Riggs wrote: > When --enable-preview is true, the patching of some java.base classes as value classes disables CDS. > Subsequently the CDS tests fail. > > For a CDS, disable Valhalla when --enable-preview is set so java.base is not patched with value classes. The test failures in jdi are not due to --enable-preview, for now only address the cds test failure. ------------- PR: https://git.openjdk.org/valhalla/pull/832 From mchung at openjdk.org Wed Mar 15 21:38:48 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 15 Mar 2023 21:38:48 GMT Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with --enable-preview patched value classes [v2] In-Reply-To: References: Message-ID: <-zSD9XNaxXNutreE9hTeUEnE04CDEz-5rY88f2oKqyA=.3f35a79f-2f29-452c-8373-41aad39a56e4@github.com> On Wed, 15 Mar 2023 19:29:07 GMT, Roger Riggs wrote: >> When --enable-preview is true, the patching of some java.base classes as value classes disables CDS. >> Subsequently the CDS tests fail. >> >> For a CDS, disable Valhalla when --enable-preview is set so java.base is not patched with value classes. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert change to jdi TestScaffold I think it may be better to problem list this test and create a JBS issue to follow up how CDS works with `--enable-preview` (that currently translates into `--patch-module` options). ------------- PR: https://git.openjdk.org/valhalla/pull/832 From jbhateja at openjdk.org Fri Mar 17 14:56:04 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 17 Mar 2023 14:56:04 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. Message-ID: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Please find below the summary of changes included with the patch: a) _ci Model:_ oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. b) _C1 compiler:_ Special handling to copy entire multifield bundle during withfield bytecode processing. c) _C2 compiler:_ VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. d) _Runtime:_ Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. More information can be found at following link [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) Please share your feedback and suggestions. Best Regards, Jatin ------------- Commit messages: - 8304310: Initial compilers and runtime handling for multifield backed vectors. Changes: https://git.openjdk.org/valhalla/pull/833/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304310 Stats: 1299 lines in 70 files changed: 941 ins; 31 del; 327 mod Patch: https://git.openjdk.org/valhalla/pull/833.diff Fetch: git fetch https://git.openjdk.org/valhalla pull/833/head:pull/833 PR: https://git.openjdk.org/valhalla/pull/833 From xgong at openjdk.org Mon Mar 20 02:48:38 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 20 Mar 2023 02:48:38 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Fri, 17 Mar 2023 14:49:24 GMT, Jatin Bhateja wrote: > Please find below the summary of changes included with the patch: > > a) _ci Model:_ > oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. > > b) _C1 compiler:_ > Special handling to copy entire multifield bundle during withfield bytecode processing. > > c) _C2 compiler:_ > VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. > > d) _Runtime:_ > Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. > > e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. > > Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. > > More information can be found at following link > [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) > > Please share your feedback and suggestions. > > Best Regards, > Jatin Really great work @jatin-bhateja ! I have not finished going through all the details by now. So only a question regarding to the vectorization of "MultiField" fields. Could we separate the detailed vector operations for "multi-fields" with "`InlineTypeNode`" ? Maybe we could add a new type or node for "mutli-field", and move the operations like load/store/replicate to the node itself. ------------- PR: https://git.openjdk.org/valhalla/pull/833 From xgong at openjdk.org Mon Mar 20 07:24:51 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 20 Mar 2023 07:24:51 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Fri, 17 Mar 2023 14:49:24 GMT, Jatin Bhateja wrote: > Please find below the summary of changes included with the patch: > > a) _ci Model:_ > oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. > > b) _C1 compiler:_ > Special handling to copy entire multifield bundle during withfield bytecode processing. > > c) _C2 compiler:_ > VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. > > d) _Runtime:_ > Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. > > e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. > > Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. > > More information can be found at following link > [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) > > Please share your feedback and suggestions. > > Best Regards, > Jatin src/hotspot/share/opto/inlinetypenode.cpp line 437: > 435: } else { > 436: value = kit->access_load_at(base, adr, adr_type, val_type, bt, decorators); > 437: } Per my understanding, method "`record_method_not_compilable()`" is used here to record the compilation cannot continued by C2, right? So why do we still need to generate a `LoadVectorNode` as the field value before the recording? Will it have any issues if this node is used after then? I'm not familiar with this method. So please feel free to correct me. src/hotspot/share/opto/inlinetypenode.cpp line 480: > 478: > 479: Node* store = kit->gvn().transform(StoreVectorNode::make(0, kit->control(), kit->memory(adr), adr, adr_type, value, vec_len)); > 480: kit->set_memory(store, adr_type); >From the `load` method, we know the `vec_len` of loaded vector type may be not the bundled size (i.e. the max vector size). So should the `vec_len` here come from the real bundled size instead of the vector type of the vector node? src/hotspot/share/opto/inlinetypenode.cpp line 518: > 516: // all the concrete vectors should be fully flattened. > 517: value = value->bottom_type()->isa_vect() ? value : kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, val_type, false)); > 518: assert(value->bottom_type()->isa_vect() && value->bottom_type()->is_vect()->length() == (uint)ft->bundle_size(), ""); Is it possible that not all the multi-field values are the `value` here? For example, if the multi-fields in the InlineTypeNode have been changed before. src/hotspot/share/opto/inlinetypenode.cpp line 725: > 723: Node* alloc = AllocateNode::Ideal_allocation(oop, phase); > 724: bool is_larval_alloc = alloc && alloc->as_Allocate()->_larval == true; > 725: if (!is_larval_alloc && is_default(phase) && inline_klass()->is_initialized() && The similar change is also merged into the valhalla mainline. See: https://github.com/openjdk/valhalla/pull/828. src/hotspot/share/opto/inlinetypenode.cpp line 851: > 849: } > 850: if (!gvn->type(value)->is_zero_type() && > 851: !VectorNode::is_all_zeros_vector(value)) { Better to merge `VectorNode::is_all_zeros_vector(value)` with `is_zero_type()`. But it seems we have to add the constants for vector type first. Not a block. src/hotspot/share/opto/vectornode.cpp line 861: > 859: return n->in(1)->bottom_type() == TypeF::ONE; > 860: case Op_ReplicateD: > 861: return n->in(1)->bottom_type() == TypeD::ONE; `is_all_ones_vector` here means all bits are `1` (i.e. `-1` for integer types). So `TypeF::ONE` is not the right value here? ------------- PR: https://git.openjdk.org/valhalla/pull/833 From xgong at openjdk.org Mon Mar 20 07:30:50 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 20 Mar 2023 07:30:50 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Fri, 17 Mar 2023 14:49:24 GMT, Jatin Bhateja wrote: > Please find below the summary of changes included with the patch: > > a) _ci Model:_ > oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. > > b) _C1 compiler:_ > Special handling to copy entire multifield bundle during withfield bytecode processing. > > c) _C2 compiler:_ > VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. > > d) _Runtime:_ > Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. > > e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. > > Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. > > More information can be found at following link > [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) > > Please share your feedback and suggestions. > > Best Regards, > Jatin src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 350: > 348: @MultiField(value = 8) > 349: byte mfield = 0; > 350: static long MFOFFSET = multiFieldOffset(VectorPayloadMF64B.class); Any reason that we have to define the basic elment type to `mfield` for different type of VectorPayloadMF? We can do the `byte` type vector operations in compiler for multi-fields. ------------- PR: https://git.openjdk.org/valhalla/pull/833 From jbhateja at openjdk.org Mon Mar 20 09:55:56 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 20 Mar 2023 09:55:56 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. In-Reply-To: References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Mon, 20 Mar 2023 06:55:55 GMT, Xiaohong Gong wrote: >> Please find below the summary of changes included with the patch: >> >> a) _ci Model:_ >> oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. >> >> b) _C1 compiler:_ >> Special handling to copy entire multifield bundle during withfield bytecode processing. >> >> c) _C2 compiler:_ >> VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. >> >> d) _Runtime:_ >> Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. >> >> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. >> >> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. >> >> More information can be found at following link >> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) >> >> Please share your feedback and suggestions. >> >> Best Regards, >> Jatin > > src/hotspot/share/opto/inlinetypenode.cpp line 437: > >> 435: } else { >> 436: value = kit->access_load_at(base, adr, adr_type, val_type, bt, decorators); >> 437: } > > Per my understanding, method "`record_method_not_compilable()`" is used here to record the compilation cannot continued by C2, right? So why do we still need to generate a `LoadVectorNode` as the field value before the recording? Will it have any issues if this node is used after then? I'm not familiar with this method. So please feel free to correct me. In the initial patch I am preventing [C2 compilation](https://github.com/openjdk/valhalla/pull/833/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aeaR433) and creating a dummy IR so that we can exit gracefully at a later point in compilation. We create Vector IR for loading/storing into multifield in a deeply nested routine. Ideally C2 should be compiling the fallback implementation but I do not think there is a way currently to ditch InlineType Node creation for value instances and treat them as regular identity instances. Other solution is to expose each ciFied separately to C2 compiler if target does not support specific vector size. As of now ci only expose base multi-field along with bundle size to ease Vector IR creation. > src/hotspot/share/opto/inlinetypenode.cpp line 518: > >> 516: // all the concrete vectors should be fully flattened. >> 517: value = value->bottom_type()->isa_vect() ? value : kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, val_type, false)); >> 518: assert(value->bottom_type()->isa_vect() && value->bottom_type()->is_vect()->length() == (uint)ft->bundle_size(), ""); > > Is it possible that not all the multi-field values are the `value` here? For example, if the multi-fields in the InlineTypeNode have been changed before. I do not fully follow your comment, multifield is not a value type to begin with, it the container VectorPayload* which is primitive class, for value types any change of field will result into creation of new InlineType, since values are immutable. > src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 350: > >> 348: @MultiField(value = 8) >> 349: byte mfield = 0; >> 350: static long MFOFFSET = multiFieldOffset(VectorPayloadMF64B.class); > > Any reason that we have to define the basic elment type to `mfield` for different type of VectorPayloadMF? We can do the `byte` type vector operations in compiler for multi-fields. This is done to streamline vector IR type creation and prevent adding special handling in compiler to append a reinterpret IR post LoadVector. I wanted to prevent introducing any special handling in C2 which does not comply with Java code e.g. Float256Vector is backed by VectorPayload256MF @multifield(value = 64) byte mfield;. ------------- PR: https://git.openjdk.org/valhalla/pull/833 From xgong at openjdk.org Tue Mar 21 02:04:01 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 21 Mar 2023 02:04:01 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. In-Reply-To: References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Mon, 20 Mar 2023 09:52:25 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/inlinetypenode.cpp line 518: >> >>> 516: // all the concrete vectors should be fully flattened. >>> 517: value = value->bottom_type()->isa_vect() ? value : kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, val_type, false)); >>> 518: assert(value->bottom_type()->isa_vect() && value->bottom_type()->is_vect()->length() == (uint)ft->bundle_size(), ""); >> >> Is it possible that not all the multi-field values are the `value` here? For example, if the multi-fields in the InlineTypeNode have been changed before. > > I do not fully follow your comment, multifield is not a value type to begin with, it the container VectorPayload* which is primitive class, for value types any change of field will result into creation of new InlineType, since values are immutable. I mean if the VectorPayload* is generated by calling APIs like "fromArray(), binaryOp(), etc.". So that not all the field values of the MultiField is the initial value (e.g. 0), and each field value (or lane) may be different. Since `scalar2vector` broadcasts the same value to each field (or lane), will this has issues? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1142827714 From xgong at openjdk.org Tue Mar 21 02:11:12 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 21 Mar 2023 02:11:12 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. In-Reply-To: References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Mon, 20 Mar 2023 09:49:41 GMT, Jatin Bhateja wrote: >> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 350: >> >>> 348: @MultiField(value = 8) >>> 349: byte mfield = 0; >>> 350: static long MFOFFSET = multiFieldOffset(VectorPayloadMF64B.class); >> >> Any reason that we have to define the basic elment type to `mfield` for different type of VectorPayloadMF? We can do the `byte` type vector operations in compiler for multi-fields. > > This is done to streamline vector IR type creation and prevent adding special handling in compiler to append a reinterpret IR post LoadVector. I wanted to prevent introducing any special handling in C2 which does not comply with Java code e.g. Float256Vector is backed by VectorPayload256MF @multifield(value = 64) byte mfield;. OK, make sense to me. Per my understanding, it currently only has `load/store/zero` vector operations for the multi-fields, right? Hence always using byte vector operations may also work well to me. But making the vector type accurate with the concrete vector class type is better for compiler. So this change is fine to me. Thanks! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1142830096 From xgong at openjdk.org Tue Mar 21 08:54:17 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 21 Mar 2023 08:54:17 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Fri, 17 Mar 2023 14:49:24 GMT, Jatin Bhateja wrote: > Please find below the summary of changes included with the patch: > > a) _ci Model:_ > oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. > > b) _C1 compiler:_ > Special handling to copy entire multifield bundle during withfield bytecode processing. > > c) _C2 compiler:_ > VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. > > d) _Runtime:_ > Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. > > e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. > > Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. > > More information can be found at following link > [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) > > Please share your feedback and suggestions. > > Best Regards, > Jatin src/hotspot/share/opto/vector.cpp line 401: > 399: buffer_adr_type, > 400: value, > 401: num_elem)); Can we simply call `InlineTypeNode::buffer()` here? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1143048258 From xgong at openjdk.org Tue Mar 21 09:24:18 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 21 Mar 2023 09:24:18 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Fri, 17 Mar 2023 14:49:24 GMT, Jatin Bhateja wrote: > Please find below the summary of changes included with the patch: > > a) _ci Model:_ > oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. > > b) _C1 compiler:_ > Special handling to copy entire multifield bundle during withfield bytecode processing. > > c) _C2 compiler:_ > VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. > > d) _Runtime:_ > Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. > > e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. > > Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. > > More information can be found at following link > [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) > > Please share your feedback and suggestions. > > Best Regards, > Jatin src/hotspot/share/opto/vector.cpp line 520: > 518: > 519: int elem_size = type2aelembytes(bt); > 520: Node* vec_val_load = get_loaded_payload(vec_unbox); We could also optimize the VectorUnbox to the vector node with `VectorUnbox::Identity()`. So `get_loaded_payload()` is needless? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1143082681 From jbhateja at openjdk.org Thu Mar 23 06:10:38 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 23 Mar 2023 06:10:38 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v2] In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: > Please find below the summary of changes included with the patch: > > a) _ci Model:_ > oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. > > b) _C1 compiler:_ > Special handling to copy entire multifield bundle during withfield bytecode processing. > > c) _C2 compiler:_ > VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. > > d) _Runtime:_ > Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. > > e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. > > Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. > > More information can be found at following link > [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) > > Please share your feedback and suggestions. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Fix incorrect type size computation during withfield handling in c1. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/833/files - new: https://git.openjdk.org/valhalla/pull/833/files/b9627b42..cdbffd65 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/833.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833 PR: https://git.openjdk.org/valhalla/pull/833 From tom_l64 at hotmail.com Thu Mar 23 19:06:58 2023 From: tom_l64 at hotmail.com (Tom L) Date: Thu, 23 Mar 2023 20:06:58 +0100 Subject: Error 404 on JEP Null-Restricted and Nullable Types (Preview) Message-ID: Hello, In the JEP 401, ?Null-Restricted Value Object Storage (Preview)??, there are several links to JEP https://openjdk.org/jeps/8303099 called ??Null-Restricted and Nullable Types (Preview)?? (from within JEP 401) But when I try to click on those links, I get an error 404, I don?t think that this is normal. Thank you in advance. Sincerely. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Thu Mar 23 22:43:51 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 23 Mar 2023 18:43:51 -0400 Subject: Error 404 on JEP Null-Restricted and Nullable Types (Preview) In-Reply-To: References: Message-ID: <483a2063-df30-37e5-4f08-bbb928ecdfe5@oracle.com> The link should be removed; the linked-to JEP is not complete yet. On 3/23/2023 3:06 PM, Tom L wrote: > > Hello, > > In the JEP 401, ?Null-Restricted Value Object Storage (Preview)??, > there are several links to JEP https://openjdk.org/jeps/8303099 called > ??Null-Restricted and Nullable Types (Preview)?? (from within JEP 401) > But when I try to click on those links, I get an error 404, I don?t > think that this is normal. > > Thank you in advance. > > Sincerely. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xgong at openjdk.org Fri Mar 24 02:20:05 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 24 Mar 2023 02:20:05 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v2] In-Reply-To: References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Thu, 23 Mar 2023 06:10:38 GMT, Jatin Bhateja wrote: >> Please find below the summary of changes included with the patch: >> >> a) _ci Model:_ >> oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. >> >> b) _C1 compiler:_ >> Special handling to copy entire multifield bundle during withfield bytecode processing. >> >> c) _C2 compiler:_ >> VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. >> >> d) _Runtime:_ >> Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. >> >> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. >> >> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. >> >> More information can be found at following link >> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) >> >> Please share your feedback and suggestions. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect type size computation during withfield handling in c1. Hi @jatin-bhateja , I ran an unit test on a ARM NEON system, and the jvm crashes with following log: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/loopnode.cpp:5871), pid=544741, tid=544757 # assert(false) failed: Bad graph detected in build_loop_late # # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-558fb2e03) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-558fb2e03, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x13b395c] PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x18c # # 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 /mnt/local/code/test/vector_api/aarch64/armie/core.544741) # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # And here is the call stack: --------------- T H R E A D --------------- Current thread (0x0000fffe0008dc80): JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=544757, stack(0x0000fffe24d00000,0x0000fffe24f00000)] Current CompileTask: C2: 377 172 jdk.incubator.vector.IntVector::fromArray0Template (39 bytes) Stack: [0x0000fffe24d00000,0x0000fffe24f00000], sp=0x0000fffe24ef9920, free space=2022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x13b395c] PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x18c (loopnode.cpp:5871) V [libjvm.so+0x13b4194] PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xd4 (loopnode.cpp:5775) V [libjvm.so+0x13b4aa4] PhaseIdealLoop::build_and_optimize()+0x4d0 (loopnode.cpp:4403) V [libjvm.so+0xa30f28] PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x1e8 (loopnode.hpp:1086) V [libjvm.so+0xa2be08] Compile::Optimize()+0x428 (compile.cpp:2828) V [libjvm.so+0xa2f10c] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x11ec (compile.cpp:842) V [libjvm.so+0x829cd4] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x3f0 (c2compiler.cpp:113) V [libjvm.so+0xa3c410] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbb0 (compileBroker.cpp:2237) V [libjvm.so+0xa3cd44] CompileBroker::compiler_thread_loop()+0x3f4 (compileBroker.cpp:1916) V [libjvm.so+0xf92068] JavaThread::thread_main_inner()+0x2f4 (javaThread.cpp:710) V [libjvm.so+0x1a3afb8] Thread::call_run()+0xf8 (thread.cpp:224) V [libjvm.so+0x15f6814] thread_native_entry(Thread*)+0x100 (os_linux.cpp:739) C [libc.so.6+0x7d5c8] The unit test is: static VectorSpecies I_SPECIES = IntVector.SPECIES_PREFERRED; for (int i = 0; i < LENGTH; i += vl) { var av = IntVector.fromArray(I_SPECIES, ia, i); var bv = IntVector.fromArray(I_SPECIES, ib, i); av.lanewise(VectorOperators.ADD, bv).intoArray(ic, i); } And I cannot reproduce the same issue on a X86 AVX-512 machine. But from the log, it seems not an AArch64 backend issue. So do you have any idea or met this issue before? BTW, is it possible to split this big patch into two parts: 1) multi-field vectorization part 2) hotspot compiler support for vector intrinsification part. This patch is too big which covers several compiler/runtime support parts. It's not so easy to analysis the issue to me once it happens. And I also tried to separate it by myself. But unfortunately, I also met another JVM crash issue which may related to the register allocation to vector registers on AArch64 when testing the "multi-fields" vectorization changes. I'm not sure whether I have missed something when doing the separation. But it will be helpful to look at the issue with your help. Thanks a lot! Best Regards, Xiaohong ------------- PR Comment: https://git.openjdk.org/valhalla/pull/833#issuecomment-1482157644 From xgong at openjdk.org Mon Mar 27 06:48:58 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 27 Mar 2023 06:48:58 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v2] In-Reply-To: References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Thu, 23 Mar 2023 06:10:38 GMT, Jatin Bhateja wrote: >> Please find below the summary of changes included with the patch: >> >> a) _ci Model:_ >> oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. >> >> b) _C1 compiler:_ >> Special handling to copy entire multifield bundle during withfield bytecode processing. >> >> c) _C2 compiler:_ >> VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. >> >> d) _Runtime:_ >> Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. >> >> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. >> >> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. >> >> More information can be found at following link >> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) >> >> Please share your feedback and suggestions. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Fix incorrect type size computation during withfield handling in c1. src/hotspot/share/opto/inlinetypenode.cpp line 430: > 428: vec_len = bundle_size_supported ? vec_len : Matcher::max_vector_size(elem_bt); > 429: > 430: value = kit->gvn().transform(LoadVectorNode::make(0, kit->control(), kit->memory(adr), adr, adr_type, vec_len, elem_bt)); A match rule supported op check is necessary as well. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1148849588 From jbhateja at openjdk.org Wed Mar 29 00:28:47 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 29 Mar 2023 00:28:47 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v3] In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: > Please find below the summary of changes included with the patch: > > a) _ci Model:_ > oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. > > b) _C1 compiler:_ > Special handling to copy entire multifield bundle during withfield bytecode processing. > > c) _C2 compiler:_ > VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. > > d) _Runtime:_ > Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. > > e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. > > Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. > > More information can be found at following link > [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) > > Please share your feedback and suggestions. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/833/files - new: https://git.openjdk.org/valhalla/pull/833/files/cdbffd65..62661134 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=01-02 Stats: 187 lines in 7 files changed: 100 ins; 60 del; 27 mod Patch: https://git.openjdk.org/valhalla/pull/833.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833 PR: https://git.openjdk.org/valhalla/pull/833 From xgong at openjdk.org Wed Mar 29 08:50:25 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 29 Mar 2023 08:50:25 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v3] In-Reply-To: References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Wed, 29 Mar 2023 00:28:47 GMT, Jatin Bhateja wrote: >> Please find below the summary of changes included with the patch: >> >> a) _ci Model:_ >> oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. >> >> b) _C1 compiler:_ >> Special handling to copy entire multifield bundle during withfield bytecode processing. >> >> c) _C2 compiler:_ >> VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. >> >> d) _Runtime:_ >> Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. >> >> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. >> >> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. >> >> More information can be found at following link >> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) >> >> Please share your feedback and suggestions. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size. src/hotspot/share/ci/ciField.hpp line 191: > 189: bool is_null_free () const { return _is_null_free; } > 190: bool is_multifield () const { return _is_multifield; } > 191: A duplicate method with line-111? src/hotspot/share/opto/inlinetypenode.hpp line 117: > 115: bool is_multifield(uint index) const; > 116: bool is_multifield_base(uint index) const; > 117: int secondary_field_count(uint index) const; Rename to `secondary_fields_count` ? Or is it possible getting the count from the field type like `type->bundle_size()`, so that this method can be removed? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1149983370 PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1151598280 From xgong at openjdk.org Thu Mar 30 03:45:45 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 30 Mar 2023 03:45:45 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v3] In-Reply-To: References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Wed, 29 Mar 2023 08:47:50 GMT, Xiaohong Gong wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size. > > src/hotspot/share/opto/inlinetypenode.hpp line 117: > >> 115: bool is_multifield(uint index) const; >> 116: bool is_multifield_base(uint index) const; >> 117: int secondary_field_count(uint index) const; > > Rename to `secondary_fields_count` ? Or is it possible getting the count from the field type like `type->bundle_size()`, so that this method can be removed? BTW, methods like `is_multifield, is_multifield_base` can be removed. `secondary_fields_count() > 1` can be used as a replacement to `is_multifield_base()`, right? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1152696987 From xgong at openjdk.org Thu Mar 30 04:11:11 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 30 Mar 2023 04:11:11 GMT Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v3] In-Reply-To: References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com> Message-ID: On Wed, 29 Mar 2023 00:28:47 GMT, Jatin Bhateja wrote: >> Please find below the summary of changes included with the patch: >> >> a) _ci Model:_ >> oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non - root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers. >> >> b) _C1 compiler:_ >> Special handling to copy entire multifield bundle during withfield bytecode processing. >> >> c) _C2 compiler:_ >> VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values. >> >> d) _Runtime:_ >> Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference. >> >> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible. >> >> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course. >> >> More information can be found at following link >> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx) >> >> Please share your feedback and suggestions. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size. src/hotspot/share/ci/ciField.hpp line 213: > 211: friend class ciInstanceKlass; > 212: > 213: GrowableArray* _secondary_fields; Style: GrowableArray* _secondary_fields; src/hotspot/share/ci/ciInlineKlass.hpp line 34: > 32: #include "ci/ciSymbol.hpp" > 33: #include "oops/inlineKlass.hpp" > 34: #include "ci/ciField.hpp" Style: please float this new "include" above line-30. src/hotspot/share/opto/inlinetypenode.cpp line 497: > 495: assert(is_java_primitive(bt) || adr->bottom_type()->is_ptr_to_narrowoop() == UseCompressedOops, "inconsistent"); > 496: if (value->bottom_type()->isa_vect()) { > 497: Node* store = kit->gvn().transform(StoreVectorNode::make(0, kit->control(), kit->memory(adr), adr, adr_type, value, vec_len)); Does it need to check the Op_StoreVector supported or not here? src/hotspot/share/opto/inlinetypenode.cpp line 773: > 771: } else { > 772: // scalar default value to match the bundle size will be returned in subsiquent calls to default_value. > 773: } Suggest to change to: BasicType bt = field_type->basic_type(); Node* value = gvn.zerocon(bt); if (field_type->bundle_size() > 1 && Matcher::match_rule_supported_vector(xxx, xxx, bt)) { value = gvn.transform(VectorNode::scalar2vector(value, ...)); } ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1152698744 PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1152699233 PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1152706204 PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1152707486