From xgong at openjdk.org Mon Dec 4 08:57:30 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 4 Dec 2023 08:57:30 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" Message-ID: Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. This patch fixes them with following main changes: 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the assertion failure [3]. When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the matched field value is expected to be a valid oop. The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1269 ------------- Commit messages: - 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" Changes: https://git.openjdk.org/valhalla/pull/958/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320815 Stats: 33 lines in 4 files changed: 14 ins; 14 del; 5 mod Patch: https://git.openjdk.org/valhalla/pull/958.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/958/head:pull/958 PR: https://git.openjdk.org/valhalla/pull/958 From thartmann at openjdk.org Mon Dec 4 09:47:28 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 4 Dec 2023 09:47:28 GMT Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted storage API points [v5] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 18:49:49 GMT, Frederic Parain wrote: >> Adding internal null-restricted storage API points > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fix EnableValhalla/EnablePrimitiveClasses flags on aarch64 Marked as reviewed by thartmann (Committer). Thanks Fred, I see that fixing the substitutability check is now tracked by [JDK-8321039](https://bugs.openjdk.org/browse/JDK-8321039). ------------- PR Review: https://git.openjdk.org/valhalla/pull/947#pullrequestreview-1761972595 PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1838177983 From thartmann at openjdk.org Mon Dec 4 09:47:31 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 4 Dec 2023 09:47:31 GMT Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted storage API points [v3] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 14:31:41 GMT, Frederic Parain wrote: >> test/hotspot/jtreg/runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java line 134: >> >>> 132: Asserts.assertTrue(e.getClass() == NoClassDefFoundError.class, "Must be a NoClassDefFoundError"); >>> 133: Asserts.assertTrue(e.getCause().getClass() == ExceptionInInitializerError.class, "Must be an ExceptionInInitializerError"); >>> 134: // Transition model (annotations and array factory) doesn't permit multi-dimentional arrays tests >> >> Shouldn't we support multi-dimensional arrays as well? Or are there any blockers? > > The new API to create flat arrays only supports single-dimension arrays. But because multi-dimensional arrays are basically a set of reference arrays with only the last-dimension array being an array of the element type, it is possible to create manually multi-dimensional arrays on top of this API. > Those tests were checking the behavior of `multianewarray` but with the removal of Q-descriptors, this bytecode cannot be used to create multi-dimensional arrays with a flat last-dimension array. Right, I got confused here. Thanks for the clarification! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1413608720 From fparain at openjdk.org Mon Dec 4 12:48:18 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 4 Dec 2023 12:48:18 GMT Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted storage API points [v5] In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 18:49:49 GMT, Frederic Parain wrote: >> Adding internal null-restricted storage API points > > Frederic Parain has updated the pull request incrementally with one additional commit since the last revision: > > Fix EnableValhalla/EnablePrimitiveClasses flags on aarch64 Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1838562685 From fparain at openjdk.org Mon Dec 4 12:51:19 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 4 Dec 2023 12:51:19 GMT Subject: [lworld] Integrated: 8320437: [lworld] Adding internal null-restricted storage API points In-Reply-To: References: Message-ID: On Tue, 7 Nov 2023 14:48:04 GMT, Frederic Parain wrote: > Adding internal null-restricted storage API points This pull request has now been integrated. Changeset: 73886921 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/738869210fdfc56f50e9044c41cf8cad7b65c8ca Stats: 1143 lines in 29 files changed: 1029 ins; 17 del; 97 mod 8320437: [lworld] Adding internal null-restricted storage API points Reviewed-by: thartmann, dsimms ------------- PR: https://git.openjdk.org/valhalla/pull/947 From fparain at openjdk.org Mon Dec 4 19:35:13 2023 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 4 Dec 2023 19:35:13 GMT Subject: [lworld] RFR: 8321293: [lworld] First batch of migrated runtime tests Message-ID: First batch of migrated runtime tests. ------------- Commit messages: - Migrate tests from using primitive classes to annotated value classes Changes: https://git.openjdk.org/valhalla/pull/959/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=959&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321293 Stats: 1136 lines in 32 files changed: 533 ins; 392 del; 211 mod Patch: https://git.openjdk.org/valhalla/pull/959.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/959/head:pull/959 PR: https://git.openjdk.org/valhalla/pull/959 From xgong at openjdk.org Tue Dec 5 03:41:03 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 5 Dec 2023 03:41:03 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 08:50:45 GMT, Xiaohong Gong wrote: > Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. > > This patch fixes them with following main changes: > > 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. > > 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. > > 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the > assertion failure [3]. > > When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a > flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field > value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the > matched field value is expected to be a valid oop. > > The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. > > 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. > > The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. > > Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. > > [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 > [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 > [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 > [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/in... src/hotspot/share/opto/macro.cpp line 861: > 859: sfpt->add_req(_igvn.intcon(alloc->_larval ? 1 : 0)); > 860: } > 861: @TobiHartmann , could you please help take a look at this change? I thought this should also fix at `lworld` branch, but currently I cannot reproduce it with a smaller case. Thanks so much! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/958#discussion_r1414832976 From mchung at openjdk.org Tue Dec 5 21:43:22 2023 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 5 Dec 2023 21:43:22 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations Message-ID: An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. ------------- Commit messages: - fix whitespace - null-restricted check not needed for VarhandleValues - clean up - Initial support of null-restricted field substitutability test Changes: https://git.openjdk.org/valhalla/pull/960/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=960&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321039 Stats: 489 lines in 32 files changed: 350 ins; 36 del; 103 mod Patch: https://git.openjdk.org/valhalla/pull/960.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/960/head:pull/960 PR: https://git.openjdk.org/valhalla/pull/960 From liach at openjdk.org Wed Dec 6 02:41:04 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 6 Dec 2023 02:41:04 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations In-Reply-To: References: Message-ID: <-HN4iuBeJfs_jY5moBfam1_sQLQZbTWafi7ynNokPRY=.c0a5a004-bcc1-4c07-92e5-104e08d7cbfa@github.com> On Tue, 5 Dec 2023 19:57:56 GMT, Mandy Chung wrote: > An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. > > This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. > > A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 689: > 687: boolean isValue, boolean isFlat, boolean isNullRestricted, Class ftype) { > 688: int ftypeKind = ftypeKind(ftype, isValue); > 689: int afIndex = afIndex(formOp, isVolatile, isFlat, ftypeKind); The null-restriction info should be encoded in the cache key too. src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template line 53: > 51: #end[Reference] > 52: > 53: FieldInstanceReadOnly(Class receiverType, long fieldOffset{#if[Object]?, Class fieldType, boolean nullRestricted}) { This `nullRestricted` can be conditional to references, too ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1416580334 PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1416581498 From rriggs at openjdk.org Wed Dec 6 16:03:57 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Dec 2023 16:03:57 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations In-Reply-To: References: Message-ID: On Tue, 5 Dec 2023 19:57:56 GMT, Mandy Chung wrote: > An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. > > This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. > > A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. make/data/hotspot-symbols/symbols-unix line 140: > 138: JVM_GetTemporaryDirectory > 139: JVM_GetVmArguments > 140: JVM_GetZeroInstance The naming of ZeroInstance and ImplicitlyConstructableClass could be more closely aligned. Perhaps GetImplicitlyConstructedInstance. src/hotspot/share/classfile/javaClasses.hpp line 1304: > 1302: MN_HIDDEN_MEMBER = 0x00400000, // @Hidden annotation detected > 1303: MN_FLAT_FIELD = 0x00800000, // flat field > 1304: MN_NULL_RESTRICTED_FIELD = 0x01000000, // null-restricted fiel typo in comment: "fiel". ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1417546559 PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1417532212 From fparain at openjdk.org Wed Dec 6 16:03:58 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 6 Dec 2023 16:03:58 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations In-Reply-To: References: Message-ID: <2Z9MfiLB_Ngt7kyqVCZKvfmfRp-DndjYrFyNw8JOlQc=.57d5990c-f194-4a36-b29b-c4defd8267d1@github.com> On Tue, 5 Dec 2023 19:57:56 GMT, Mandy Chung wrote: > An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. > > This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. > > A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. test/jdk/valhalla/valuetypes/NullRestrictedTest.java line 55: > 53: public void lazyInitializedDefaultValue() { > 54: // VM lazily sets the null-restricted non-flat field to zero default > 55: assertTrue(new EmptyContainer() == EmptyContainer.default); The `.default` syntax is translated to `aconst_init` which is going to be removed. May be use `ValueClass.zeroInstance(EmptyContainer.class)` instead. Applies to all `.default` usage in this file. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1417583647 From mchung at openjdk.org Wed Dec 6 18:00:10 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 18:00:10 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 15:44:58 GMT, Roger Riggs wrote: >> An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. >> >> This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. >> >> A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. > > make/data/hotspot-symbols/symbols-unix line 140: > >> 138: JVM_GetTemporaryDirectory >> 139: JVM_GetVmArguments >> 140: JVM_GetZeroInstance > > The naming of ZeroInstance and ImplicitlyConstructableClass could be more closely aligned. > Perhaps GetImplicitlyConstructedInstance. That's the term described in the JEP. I prefer to come back and do the renaming later once the APIs are defined. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1417761420 From mchung at openjdk.org Wed Dec 6 18:17:32 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 18:17:32 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v2] In-Reply-To: References: Message-ID: > An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. > > This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. > > A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/960/files - new: https://git.openjdk.org/valhalla/pull/960/files/724fbbc8..e216c78e Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=960&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=960&range=00-01 Stats: 14 lines in 4 files changed: 2 ins; 1 del; 11 mod Patch: https://git.openjdk.org/valhalla/pull/960.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/960/head:pull/960 PR: https://git.openjdk.org/valhalla/pull/960 From fparain at openjdk.org Wed Dec 6 18:17:32 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 6 Dec 2023 18:17:32 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v2] In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 18:14:47 GMT, Mandy Chung wrote: >> An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. >> >> This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. >> >> A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review comment Thank you for fixing this so quickly. ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/960#pullrequestreview-1768323639 From mchung at openjdk.org Wed Dec 6 18:17:36 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 18:17:36 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v2] In-Reply-To: References: Message-ID: <8EDD3vc0aKCoaBoJdqr16gkRGLjpc3A-0QuX8t0NlzI=.50be7af3-2e18-4fce-8cd1-bc60f13034d2@github.com> On Wed, 6 Dec 2023 15:41:08 GMT, Roger Riggs wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment > > src/hotspot/share/classfile/javaClasses.hpp line 1304: > >> 1302: MN_HIDDEN_MEMBER = 0x00400000, // @Hidden annotation detected >> 1303: MN_FLAT_FIELD = 0x00800000, // flat field >> 1304: MN_NULL_RESTRICTED_FIELD = 0x01000000, // null-restricted fiel > > typo in comment: "fiel". Fixed ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1417781845 From mchung at openjdk.org Wed Dec 6 18:17:39 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 18:17:39 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v2] In-Reply-To: <-HN4iuBeJfs_jY5moBfam1_sQLQZbTWafi7ynNokPRY=.c0a5a004-bcc1-4c07-92e5-104e08d7cbfa@github.com> References: <-HN4iuBeJfs_jY5moBfam1_sQLQZbTWafi7ynNokPRY=.c0a5a004-bcc1-4c07-92e5-104e08d7cbfa@github.com> Message-ID: <-B7u5Kj3wvV8Xal0Htmkku6MCgkOaMnXCJ3xb58lyTk=.df7877c1-bc4f-400b-bf78-3596ed721d71@github.com> On Wed, 6 Dec 2023 02:34:46 GMT, Chen Liang wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment > > src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 689: > >> 687: boolean isValue, boolean isFlat, boolean isNullRestricted, Class ftype) { >> 688: int ftypeKind = ftypeKind(ftype, isValue); >> 689: int afIndex = afIndex(formOp, isVolatile, isFlat, ftypeKind); > > The null-restriction info should be encoded in the cache key too. Fixed. > src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template line 53: > >> 51: #end[Reference] >> 52: >> 53: FieldInstanceReadOnly(Class receiverType, long fieldOffset{#if[Object]?, Class fieldType, boolean nullRestricted}) { > > This `nullRestricted` can be conditional to references, too I leave it as is. We will do more work in this file to support the null-restricted types. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1417784035 PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1417790045 From mchung at openjdk.org Wed Dec 6 18:17:42 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 18:17:42 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v2] In-Reply-To: <2Z9MfiLB_Ngt7kyqVCZKvfmfRp-DndjYrFyNw8JOlQc=.57d5990c-f194-4a36-b29b-c4defd8267d1@github.com> References: <2Z9MfiLB_Ngt7kyqVCZKvfmfRp-DndjYrFyNw8JOlQc=.57d5990c-f194-4a36-b29b-c4defd8267d1@github.com> Message-ID: On Wed, 6 Dec 2023 15:59:21 GMT, Frederic Parain wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment > > test/jdk/valhalla/valuetypes/NullRestrictedTest.java line 55: > >> 53: public void lazyInitializedDefaultValue() { >> 54: // VM lazily sets the null-restricted non-flat field to zero default >> 55: assertTrue(new EmptyContainer() == EmptyContainer.default); > > The `.default` syntax is translated to `aconst_init` which is going to be removed. > May be use `ValueClass.zeroInstance(EmptyContainer.class)` instead. > Applies to all `.default` usage in this file. Ok. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/960#discussion_r1417782983 From rriggs at openjdk.org Wed Dec 6 18:36:07 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Dec 2023 18:36:07 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v2] In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 18:17:32 GMT, Mandy Chung wrote: >> An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. >> >> This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. >> >> A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review comment LGTM ------------- Marked as reviewed by rriggs (Committer). PR Review: https://git.openjdk.org/valhalla/pull/960#pullrequestreview-1768359899 From mchung at openjdk.org Wed Dec 6 19:33:17 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 19:33:17 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v3] In-Reply-To: References: Message-ID: <0_26Fq4Tm3pnsIcuplL_N2IMObnlPzgrS4j1f8ZjQUw=.a5ed9506-3748-47b2-b54e-18f9437904a2@github.com> > An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. > > This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. > > A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Fix assertion check ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/960/files - new: https://git.openjdk.org/valhalla/pull/960/files/e216c78e..f1287a44 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=960&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=960&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/960.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/960/head:pull/960 PR: https://git.openjdk.org/valhalla/pull/960 From mchung at openjdk.org Wed Dec 6 22:55:47 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 22:55:47 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v4] In-Reply-To: References: Message-ID: <18ZcqPwsjkXCN4_sLW0cmzyA7abNh3WEb8ldHSUlKGE=.6f7ea726-d12f-458e-ad9d-5ee86333efb8@github.com> > An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. > > This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. > > A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Add back Unsafe::uninitializedDefaultValue used by serializatoin ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/960/files - new: https://git.openjdk.org/valhalla/pull/960/files/f1287a44..326d3fc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=960&range=03 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=960&range=02-03 Stats: 52 lines in 8 files changed: 23 ins; 26 del; 3 mod Patch: https://git.openjdk.org/valhalla/pull/960.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/960/head:pull/960 PR: https://git.openjdk.org/valhalla/pull/960 From mchung at openjdk.org Wed Dec 6 22:55:48 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 22:55:48 GMT Subject: [lworld] RFR: 8321039: [lworld] Substitutability code must recognize new annotations [v3] In-Reply-To: <0_26Fq4Tm3pnsIcuplL_N2IMObnlPzgrS4j1f8ZjQUw=.a5ed9506-3748-47b2-b54e-18f9437904a2@github.com> References: <0_26Fq4Tm3pnsIcuplL_N2IMObnlPzgrS4j1f8ZjQUw=.a5ed9506-3748-47b2-b54e-18f9437904a2@github.com> Message-ID: On Wed, 6 Dec 2023 19:33:17 GMT, Mandy Chung wrote: >> An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. >> >> This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. >> >> A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Fix assertion check I restored `Unsafe::uninitializedDefaultValue` which is used by serialization in the current prototype. Will revisit this in future work. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/960#issuecomment-1843813143 From mchung at openjdk.org Wed Dec 6 22:55:51 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Dec 2023 22:55:51 GMT Subject: [lworld] Integrated: 8321039: [lworld] Substitutability code must recognize new annotations In-Reply-To: References: Message-ID: On Tue, 5 Dec 2023 19:57:56 GMT, Mandy Chung wrote: > An initial implementation for substitutability test and partial method handle and var handle support for null-restricted types. JDK-8317767 will provide the full library support for null-restricted types. > > This patch handles null-restricted field reference declared in a non-flat class. The default value of that field is lazily set by VM on read access. `Unsafe::getReference` may return null for null-restricted non-flat field. > > A new `jdk.internal.value.ValueClass` is created to provide JVM entry points for value classes until public APIs are defined. `jdk.internal.misc.newNullRestrictedArray` method is moved as well. This pull request has now been integrated. Changeset: 8e0a09dd Author: Mandy Chung URL: https://git.openjdk.org/valhalla/commit/8e0a09ddebd736a8db19cdf99abfb14a0c4daccb Stats: 474 lines in 30 files changed: 341 ins; 30 del; 103 mod 8321039: [lworld] Substitutability code must recognize new annotations Reviewed-by: fparain, rriggs ------------- PR: https://git.openjdk.org/valhalla/pull/960 From jbhateja at openjdk.org Thu Dec 7 03:42:57 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 7 Dec 2023 03:42:57 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: References: Message-ID: <2cFbZG5oW3lPtC28G_eaJkzIDxvX91iMc04sRW6C1DI=.6da71e4d-ddc0-4f12-aff4-7be322de42a4@github.com> On Mon, 4 Dec 2023 08:50:45 GMT, Xiaohong Gong wrote: > Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. > > This patch fixes them with following main changes: > > 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. > > 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. > > 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the > assertion failure [3]. > > When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a > flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field > value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the > matched field value is expected to be a valid oop. > > The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. > > 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. > > The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. > > Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. > > [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 > [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 > [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 > [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/in... Hi @XiaohongGong , I am seeing following assertion failures in Vector API JTREG tests with flattening disabled, not yet spent time in root causing it. # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/jatinbha/sandboxes/lworld+vector/valhalla/src/hotspot/share/opto/narrowptrnode.cpp:45), pid=342594, tid=342623 # assert(t->isa_narrowoop()) failed: only narrowoop here # # JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-adhoc.root.valhalla) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-adhoc.root.valhalla, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x14a9044] DecodeNNode::Value(PhaseGVN*) const+0x124 # # 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/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/core.342594) # # An error report file with more information is saved as: # /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/hs_err_pid342594.log # # Compiler replay data is saved as: # /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/replay_pid342594.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ------------- PR Comment: https://git.openjdk.org/valhalla/pull/958#issuecomment-1844204851 From xgong at openjdk.org Thu Dec 7 03:52:57 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 7 Dec 2023 03:52:57 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: <2cFbZG5oW3lPtC28G_eaJkzIDxvX91iMc04sRW6C1DI=.6da71e4d-ddc0-4f12-aff4-7be322de42a4@github.com> References: <2cFbZG5oW3lPtC28G_eaJkzIDxvX91iMc04sRW6C1DI=.6da71e4d-ddc0-4f12-aff4-7be322de42a4@github.com> Message-ID: On Thu, 7 Dec 2023 03:39:44 GMT, Jatin Bhateja wrote: > Hi @XiaohongGong , > > I am seeing following assertion failures in Vector API JTREG tests with flattening disabled, not yet spent time in root causing it. > > ``` > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/jatinbha/sandboxes/lworld+vector/valhalla/src/hotspot/share/opto/narrowptrnode.cpp:45), pid=342594, tid=342623 > # assert(t->isa_narrowoop()) failed: only narrowoop here > # > # JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-adhoc.root.valhalla) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-adhoc.root.valhalla, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x14a9044] DecodeNNode::Value(PhaseGVN*) const+0x124 > # > # 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/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/core.342594) > # > # An error report file with more information is saved as: > # /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/hs_err_pid342594.log > # > # Compiler replay data is saved as: > # /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/replay_pid342594.log > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > ``` Thanks for reporting this issue. Seems the workaround for `VectorBox` in `LoadNode::Identity()` is not right, that if the value is `InlineType` field of `VectorBox`, it returned the `InlineType` not rightly. We should do nothing for such cases. Could you please help check whether it can be fixed by applying following change: diff --git a/src/hotspot/share/opto/memnode.cpp b/src/hotspot/share/opto/memnode.cpp index d88ff398e..3ecf780a7 100644 --- a/src/hotspot/share/opto/memnode.cpp +++ b/src/hotspot/share/opto/memnode.cpp @@ -1251,12 +1251,13 @@ Node* LoadNode::Identity(PhaseGVN* phase) { offset > oopDesc::klass_offset_in_bytes()) { Node* value = base->as_InlineType()->field_value_by_offset((int)offset, true); if (value != nullptr) { - if (Opcode() == Op_LoadN && !base->is_VectorBox()) { + if (Opcode() != Op_LoadN) { + return value; + } else if (!base->is_VectorBox()) { // Encode oop value if we are loading a narrow oop assert(!phase->type(value)->isa_narrowoop(), "should already be decoded"); - value = phase->transform(new EncodePNode(value, bottom_type())); + return phase->transform(new EncodePNode(value, bottom_type())); } - return value; } } Thanks so much in advance! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/958#issuecomment-1844223541 From fparain at openjdk.org Thu Dec 7 20:36:20 2023 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 7 Dec 2023 20:36:20 GMT Subject: [lworld] RFR: 8321293: [lworld] First batch of migrated runtime tests [v2] In-Reply-To: References: Message-ID: > First batch of migrated runtime tests. 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 three additional commits since the last revision: - Tests update and cleanup - Merge remote-tracking branch 'upstream/lworld' into migrate_tests - Migrate tests from using primitive classes to annotated value classes ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/959/files - new: https://git.openjdk.org/valhalla/pull/959/files/1b87a84a..0e5b490f Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=959&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=959&range=00-01 Stats: 612 lines in 52 files changed: 370 ins; 42 del; 200 mod Patch: https://git.openjdk.org/valhalla/pull/959.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/959/head:pull/959 PR: https://git.openjdk.org/valhalla/pull/959 From vromero at openjdk.org Thu Dec 7 21:03:42 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 7 Dec 2023 21:03:42 GMT Subject: Integrated: Merge lworld Message-ID: <6E57VLJyYTobOG4sAXk491cn_IyZAFBbJWmE4yv_1Nw=.fb28dafc-7481-49aa-bff6-67a3b1fa9ac0@github.com> Merge branch 'lworld' into lw5_merge_lworld # Conflicts: # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java # test/langtools/tools/javac/MethodParameters/AttributeVisitor.java ------------- Commit messages: - Merge branch 'lworld' into lw5_merge_lworld - Merge lworld - Merge lworld - 8318117: [lw5] create a switch for null-restricted types - 8316628: [lw5] remove vnew, aconst_init, and withfield - Merge lworld - 8316561: [lw5] class file attribute NullRestricted shouldn't be generated for arrays - 8316325: [lw5] sync javac with the current JVMS, particularly assertions on new class attributes - Merge lworld - Merge lworld - ... and 26 more: https://git.openjdk.org/valhalla/compare/8e0a09dd...57d4db7e The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/valhalla/pull/961/files Stats: 8244 lines in 293 files changed: 4473 ins; 2614 del; 1157 mod Patch: https://git.openjdk.org/valhalla/pull/961.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/961/head:pull/961 PR: https://git.openjdk.org/valhalla/pull/961 From vromero at openjdk.org Thu Dec 7 21:03:44 2023 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 7 Dec 2023 21:03:44 GMT Subject: Integrated: Merge lworld In-Reply-To: <6E57VLJyYTobOG4sAXk491cn_IyZAFBbJWmE4yv_1Nw=.fb28dafc-7481-49aa-bff6-67a3b1fa9ac0@github.com> References: <6E57VLJyYTobOG4sAXk491cn_IyZAFBbJWmE4yv_1Nw=.fb28dafc-7481-49aa-bff6-67a3b1fa9ac0@github.com> Message-ID: <9HrTLZDYs5JjIuZBerIY0_LImEu8YFNtPF_iiR1IBG0=.b68c65b5-356b-4a5d-82f8-9e26efda9199@github.com> On Thu, 7 Dec 2023 20:57:17 GMT, Vicente Romero wrote: > Merge branch 'lworld' into lw5_merge_lworld > # Conflicts: > # src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java > # test/langtools/tools/javac/MethodParameters/AttributeVisitor.java This pull request has now been integrated. Changeset: cbeea29d Author: Vicente Romero URL: https://git.openjdk.org/valhalla/commit/cbeea29da0ea549239e81ad21c25915fdf82f29e Stats: 53884 lines in 2250 files changed: 32992 ins; 12516 del; 8376 mod Merge lworld ------------- PR: https://git.openjdk.org/valhalla/pull/961 From jbhateja at openjdk.org Fri Dec 8 09:13:41 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 8 Dec 2023 09:13:41 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: References: Message-ID: <767sGvjDZFdm1hHt8Y1qhD8GA3YT_I8D8nC43c9axSE=.327a2e47-ca30-4fd2-9bba-f07773c6a926@github.com> On Mon, 4 Dec 2023 08:50:45 GMT, Xiaohong Gong wrote: > Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. > > This patch fixes them with following main changes: > > 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. > > 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. > > 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the > assertion failure [3]. > > When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a > flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field > value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the > matched field value is expected to be a valid oop. > > The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. > > 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. > > The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. > > Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. > > [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 > [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 > [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 > [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/in... src/hotspot/share/opto/inlinetypenode.cpp line 319: > 317: } else if (is_vector_payload(vk)) { > 318: assert(field_value(0)->as_InlineType()->field_count() == nfields, ""); > 319: } Its not very clear, why will these assertions offend because C2 IR is in synchronism with ci Model. Also given that C2 always creates a InlineTypeNode for a value object. Even for a non-flattened field compile injects a re-materializing InlineTypeNode from the loaded value oop. src/hotspot/share/opto/macro.cpp line 860: > 858: sfpt->add_req(_igvn.intcon(1)); > 859: sfpt->add_req(_igvn.intcon(alloc->_larval ? 1 : 0)); > 860: } We have a separate pass ["process_inline_types"](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/compile.cpp#L1977), which walks over _inline_type_nodes and scalarizes them at safe points. I think we can even skip over doing any special handling for InlineTypeNodes in regular escape analysis. WDYT ? ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/958#discussion_r1420127683 PR Review Comment: https://git.openjdk.org/valhalla/pull/958#discussion_r1420149389 From xgong at openjdk.org Mon Dec 11 02:01:38 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 11 Dec 2023 02:01:38 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: <767sGvjDZFdm1hHt8Y1qhD8GA3YT_I8D8nC43c9axSE=.327a2e47-ca30-4fd2-9bba-f07773c6a926@github.com> References: <767sGvjDZFdm1hHt8Y1qhD8GA3YT_I8D8nC43c9axSE=.327a2e47-ca30-4fd2-9bba-f07773c6a926@github.com> Message-ID: On Fri, 8 Dec 2023 09:00:52 GMT, Jatin Bhateja wrote: >> Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. >> >> This patch fixes them with following main changes: >> >> 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. >> >> 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. >> >> 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the >> assertion failure [3]. >> >> When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a >> flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field >> value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the >> matched field value is expected to be a valid oop. >> >> The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. >> >> 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. >> >> The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. >> >> Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. >> >> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 >> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 >> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 >> [4] https://github.com/openjdk... > > src/hotspot/share/opto/inlinetypenode.cpp line 319: > >> 317: } else if (is_vector_payload(vk)) { >> 318: assert(field_value(0)->as_InlineType()->field_count() == nfields, ""); >> 319: } > > Its not very clear, why will these assertions offend because C2 IR is in synchronism with ci Model. Also given that C2 always creates a InlineTypeNode for a value object. Even for a non-flattened field compile injects a re-materializing InlineTypeNode from the loaded value oop. The assertion fails on line 318. Use `Int256Vector` as an example, if the payload is not flattened and the multifields are not vectorized, `field_value(0)->as_InlineType()->field_count()` should be 8, while the `nfields` of the vector value object is 1. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/958#discussion_r1421876773 From xgong at openjdk.org Mon Dec 11 02:16:44 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 11 Dec 2023 02:16:44 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: <767sGvjDZFdm1hHt8Y1qhD8GA3YT_I8D8nC43c9axSE=.327a2e47-ca30-4fd2-9bba-f07773c6a926@github.com> References: <767sGvjDZFdm1hHt8Y1qhD8GA3YT_I8D8nC43c9axSE=.327a2e47-ca30-4fd2-9bba-f07773c6a926@github.com> Message-ID: On Fri, 8 Dec 2023 09:10:19 GMT, Jatin Bhateja wrote: >> Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. >> >> This patch fixes them with following main changes: >> >> 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. >> >> 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. >> >> 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the >> assertion failure [3]. >> >> When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a >> flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field >> value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the >> matched field value is expected to be a valid oop. >> >> The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. >> >> 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. >> >> The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. >> >> Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. >> >> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 >> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 >> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 >> [4] https://github.com/openjdk... > > src/hotspot/share/opto/macro.cpp line 860: > >> 858: sfpt->add_req(_igvn.intcon(1)); >> 859: sfpt->add_req(_igvn.intcon(alloc->_larval ? 1 : 0)); >> 860: } > > We have a separate pass ["process_inline_types"](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/compile.cpp#L1977), which walks over _inline_type_nodes and scalarizes them at safe points. I think we can even skip over doing any special handling for InlineTypeNodes in regular escape analysis. WDYT ? This issue happens when scalarizing an merging allocation which has inlinetype, instead of scalarizing a single `InlineTypeNode`. Skiping over doing this optimization for InlineTypeNode may lose some optimization oppportunity? @TobiHartmann , could you please help check this change or give any suggestion on that? Thanks so much! ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/958#discussion_r1421881873 From jbhateja at openjdk.org Mon Dec 11 07:08:46 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 11 Dec 2023 07:08:46 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: References: <767sGvjDZFdm1hHt8Y1qhD8GA3YT_I8D8nC43c9axSE=.327a2e47-ca30-4fd2-9bba-f07773c6a926@github.com> Message-ID: On Mon, 11 Dec 2023 01:59:15 GMT, Xiaohong Gong wrote: >> src/hotspot/share/opto/inlinetypenode.cpp line 319: >> >>> 317: } else if (is_vector_payload(vk)) { >>> 318: assert(field_value(0)->as_InlineType()->field_count() == nfields, ""); >>> 319: } >> >> Its not very clear, why will these assertions offend because C2 IR is in synchronism with ci Model. Also given that C2 always creates a InlineTypeNode for a value object. Even for a non-flattened field compile injects a re-materializing InlineTypeNode from the loaded value oop. > > The assertion fails on line 318. Use `Int256Vector` as an example, if the payload is not flattened and the multifields are not vectorized, `field_value(0)->as_InlineType()->field_count()` should be 8, while the `nfields` of the vector value object is 1. Thanks for explanation, agree to this change. > This issue happens when scalarizing an merging allocation which has inlinetype, instead of scalarizing a single `InlineTypeNode`. Skiping over doing this optimization for InlineTypeNode may lose some optimization oppportunity? Thanks @XiaohongGong , IIRC compiler allocates a buffer for an InlineTypeNode **if and only iff** it has a non-flattened user, this mean allocated buffers are non-eliminatable, and regular escape analysis will not able to remove allocations and perform scalar replacements. In principle we do need to pass larval state for value object reconstruction during de-optimization, so additional booking for larval state is correct. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/958#discussion_r1422010486 PR Review Comment: https://git.openjdk.org/valhalla/pull/958#discussion_r1422010280 From zjx001202 at gmail.com Mon Dec 11 12:15:25 2023 From: zjx001202 at gmail.com (Glavo) Date: Mon, 11 Dec 2023 20:15:25 +0800 Subject: More APIs based on MemorySegment In-Reply-To: References: Message-ID: Sorry, I fell asleep while sending the email, so I sent it to the wrong mailing list. It should be sent to panama-dev. Glavo On Sun, Dec 10, 2023 at 7:45?PM Glavo wrote: > Hi, > > I'm hoping to get the following new API which will help some programs > escape the 2GiB limit: > > > 1. X-Buffer::get(int, MemorySegment, long, long) > 2. X-Buffer::put(int, MemorySegment, long, long) > 3. ReadableByteChannel::read(MemorySegment, long, long) > 4. WritableByteChannel::write(MemorySegment, long, long) > 5. InputStream::read(MemorySegment, long, long) > 6. OutputStream::write(MemorySegment, long, long) > 7. Checksum::update(MemorySegment, long, long) > 8. Deflater::setInput(MemorySegment, long, long) > 9. Deflater::deflate(MemorySegment, long, long) > 10. Inflater::setInput(MemorySegment, long, long) > 11. Inflater::inflate(MemorySegment, long, long) > 12. Files.readAllBytesToNative(Path): MemorySegment > 13. Files.write(Path, MemorySegment, OpenOpetion...) > > Do you have plans to offer them in the future? > > Glavo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Dec 11 12:59:22 2023 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 11 Dec 2023 12:59:22 +0000 Subject: More APIs based on MemorySegment In-Reply-To: References: Message-ID: <7c2c14d2-b189-4e96-9cea-3b9dbea8f39e@oracle.com> Hi Glavo, we do not have plans to update these APIs at the moment. It is possible to map a segment into a bytebuffer and then to use existing methods. Of course, as you mention, this will suffer from issues if the segment is too big to fit in to a buffer, but I guess we'd like to assess how big of an issue that is, what kind of workaround would clients need to write etc. before doing a blanket sprinkling of MS in the entire JDK. Looking at your list, concretely: > 1. X-Buffer::get(int, MemorySegment, long, long) > 2. X-Buffer::put(int, MemorySegment, long, long) > 3. ReadableByteChannel::read(MemorySegment, long, long) > 4. WritableByteChannel::write(MemorySegment, long, long) > 5. InputStream::read(MemorySegment, long, long) > 6. OutputStream::write(MemorySegment, long, long) > 7. Checksum::update(MemorySegment, long, long) > 8. Deflater::setInput(MemorySegment, long, long) > 9. Deflater::deflate(MemorySegment, long, long) > 10. Inflater::setInput(MemorySegment, long, long) > 11. Inflater::inflate(MemorySegment, long, long) > 12. Files.readAllBytesToNative(Path): MemorySegment > 13. Files.write(Path, MemorySegment, OpenOpetion...) > It seems like you are conflating two aspects: * there are some methods that are accepting a ByteBuffer today, so the question is whether they should accept a MS in the future (3, 4, 7, 8, 9, 10, 11) * there are other methods that are accepting a byte[] today, the question is whether we want to enhance them to work on buffer/segments (1, 2, 5, 6, 12, 13) IMHO, the first group has a somewhat higher priority than the second (methods in that group don't even work with BB today, is there really a demand to have them working with MS?) And, in the first group, my hunch is that doing Readable/WriteableFileChannel will address 80% of the use cases? Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From thartmann at openjdk.org Mon Dec 11 16:51:48 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 11 Dec 2023 16:51:48 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 08:50:45 GMT, Xiaohong Gong wrote: > Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. > > This patch fixes them with following main changes: > > 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. > > 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. > > 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the > assertion failure [3]. > > When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a > flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field > value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the > matched field value is expected to be a valid oop. > > The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. > > 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. > > The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. > > Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. > > [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 > [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 > [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 > [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/in... Sorry for the delay, I'm swamped with other tasks but I'll get back to this later this week. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/958#issuecomment-1850467073 From xgong at openjdk.org Tue Dec 12 03:30:44 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 12 Dec 2023 03:30:44 GMT Subject: [lworld+vector] RFR: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: <2cFbZG5oW3lPtC28G_eaJkzIDxvX91iMc04sRW6C1DI=.6da71e4d-ddc0-4f12-aff4-7be322de42a4@github.com> References: <2cFbZG5oW3lPtC28G_eaJkzIDxvX91iMc04sRW6C1DI=.6da71e4d-ddc0-4f12-aff4-7be322de42a4@github.com> Message-ID: On Thu, 7 Dec 2023 03:39:44 GMT, Jatin Bhateja wrote: >> Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. >> >> This patch fixes them with following main changes: >> >> 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. >> >> 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. >> >> 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the >> assertion failure [3]. >> >> When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a >> flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field >> value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the >> matched field value is expected to be a valid oop. >> >> The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. >> >> 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. >> >> The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. >> >> Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. >> >> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 >> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 >> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 >> [4] https://github.com/openjdk... > > Hi @XiaohongGong , > > I am seeing following assertion failures in Vector API JTREG tests with flattening disabled, not yet spent time in root causing it. > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/jatinbha/sandboxes/lworld+vector/valhalla/src/hotspot/share/opto/narrowptrnode.cpp:45), pid=342594, tid=342623 > # assert(t->isa_narrowoop()) failed: only narrowoop here > # > # JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-adhoc.root.valhalla) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-adhoc.root.valhalla, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x14a9044] DecodeNNode::Value(PhaseGVN*) const+0x124 > # > # 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/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/core.342594) > # > # An error report file with more information is saved as: > # /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/hs_err_pid342594.log > # > # Compiler replay data is saved as: > # /home/jatinbha/sandboxes/lworld+vector/valhalla/build/linux-x86_64-server-fastdebug/test-support/jtreg_test_jdk_jdk_incubator_vector/scratch/1/replay_pid342594.log > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # Sorry for cannot continuing on this PR. I have to close it. @jatin-bhateja may create another PR for it. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/958#issuecomment-1851242103 From xgong at openjdk.org Tue Dec 12 03:30:44 2023 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 12 Dec 2023 03:30:44 GMT Subject: [lworld+vector] Withdrawn: 8320815: [lworld+vector] Fix vector API jtreg crashes with "-XX:InlineFieldMaxFlatSize=0" In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 08:50:45 GMT, Xiaohong Gong wrote: > Current Vector API jtreg crashes with `-XX:InlineFieldMaxFlatSize=0` with several kinds of issues. This option makes all the value object fields can not be flattened. > > This patch fixes them with following main changes: > > 1) Remove the fields count check for `Vector/VectorPayload` objects when scalaring the value objects across safepoints. The check on vector objects fails when its payload field is not flattened (see [1]). The check is not right and can be removed. > > 2) Insert two additional inputs of `InlineTypeNode` to safepoint when creating the `SafePointScalarObjectNode` for a value object. This is missing when compiler handles an allocation merge with inline type. It causes the assertion [2] fails. > > 3) Forbit optimizing a `LoadN` to `EncodeP (InlineType)`, if the `InlineType` is the payload field of `VectorBox`. This fixes the > assertion failure [3]. > > When loading from an `InlineType`, C2 compiler tries to look for its field value with the matching offset. If the matched field is a > flattened value object, its field with the matching offset is searched recursively. Otherwise, the field itself is used. After the field > value is found, the load can be saved, and the field value is used as the replacement. If it is an object loading (i.e. `LoadN`), the > matched field value is expected to be a valid oop. > > The issue happens when the address base is `VectorBox` and the matched field is a non-flattened `InlineType`. Since `VectorBox` is expanded lately, its memory and the memory for the field are not allocated at this moment. Optimizing `LoadN` to `EncodeP` with the un-allocated `InlineType` makes it possible to the miss the buffer. > > 4) Explicitly check whether the payload field is flattened when expanding `VectorBox`. Allocate the buffer and store the vector value to the memory if the payload is not flattened. > > The similar operations are handled in `InlineTypeNode::store()` before. But the graph is more complex and not right for some vector API cases. We hit assertion [4]. > > Tests: All tests pass with `-XX:InlineFieldMaxFlatSize=0` now. And no new regressions are found. > > [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L318 > [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/output.cpp#L812 > [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/compile.cpp#L2050 > [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/in... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/valhalla/pull/958 From mchung at openjdk.org Wed Dec 13 01:36:34 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 13 Dec 2023 01:36:34 GMT Subject: [lworld] RFR: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types Message-ID: Migrate test/jdk/valhalla/valuetypes tests to use null-restricted types instead. ------------- Commit messages: - more clean up - clean up - Migrate tests to value types (part 2) - Replace Unsafe::getNullRestrictedReference and call zeroInstance directly in LF - Migrate libraries tests to null-restricted (part 1) Changes: https://git.openjdk.org/valhalla/pull/963/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=963&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321941 Stats: 3600 lines in 37 files changed: 475 ins; 2645 del; 480 mod Patch: https://git.openjdk.org/valhalla/pull/963.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/963/head:pull/963 PR: https://git.openjdk.org/valhalla/pull/963 From liach at openjdk.org Wed Dec 13 02:35:12 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 13 Dec 2023 02:35:12 GMT Subject: [lworld] RFR: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 01:28:58 GMT, Mandy Chung wrote: > Migrate test/jdk/valhalla/valuetypes tests to use null-restricted types instead. src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 830: > 828: final int ZERO_INSTANCE = (needsZeroInstance && isGetter ? nameCursor++ : -1); > 829: final int POST_CAST = (needsCast && isGetter ? nameCursor++ : -1); > 830: final int RESULT = nameCursor-1; // either the call or the cast Outdated comment, should be // the call, the zero instance, or the cast ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/963#discussion_r1424776266 From rriggs at openjdk.org Wed Dec 13 17:40:17 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 13 Dec 2023 17:40:17 GMT Subject: [lworld] RFR: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 01:28:58 GMT, Mandy Chung wrote: > Migrate test/jdk/valhalla/valuetypes tests to use null-restricted types instead. test/jdk/valhalla/valuetypes/ArrayElementVarHandleTest.java line 28: > 26: * @test > 27: * @summary test VarHandle on value class array > 28: * @compile -XDenablePrimitiveClasses ArrayElementVarHandleTest.java It looks like the compiler does not need -XDenablePrimitiveClasses. Except in RecursiveValueClass.java that still has a primitive class declaration. test/jdk/valhalla/valuetypes/ArrayElementVarHandleTest.java line 30: > 28: * @compile -XDenablePrimitiveClasses ArrayElementVarHandleTest.java > 29: * @run junit/othervm -XX:+EnableValhalla -XX:FlatArrayElementMaxSize=-1 ArrayElementVarHandleTest > 30: * @run testng/othervm -XX:+EnableValhalla -XX:FlatArrayElementMaxSize=0 ArrayElementVarHandleTest junit here too? test/jdk/valhalla/valuetypes/ObjectMethods.java line 119: > 117: static Stream identitiesData() { > 118: return Stream.of( > 119: Arguments.of(new Object(), false, false), The JEP doesn't say this (yet) but `new Object()` is an identity instance. java.util.Objects.isIdentityObject() and .isValueObject() will need to be updated too. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/963#discussion_r1425671316 PR Review Comment: https://git.openjdk.org/valhalla/pull/963#discussion_r1425624039 PR Review Comment: https://git.openjdk.org/valhalla/pull/963#discussion_r1425642915 From mchung at openjdk.org Wed Dec 13 18:10:18 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 13 Dec 2023 18:10:18 GMT Subject: [lworld] RFR: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types [v2] In-Reply-To: References: Message-ID: <4KCYuT5omFGupOrjbJ4Er6ZBLiKAXe6vyMaBzDEB-Yc=.b5e6d3c8-8a8f-41e3-b47e-4a4cdedb8eb2@github.com> > Migrate test/jdk/valhalla/valuetypes tests to use null-restricted types instead. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Remove @compile ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/963/files - new: https://git.openjdk.org/valhalla/pull/963/files/d8e9e683..d8683abd Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=963&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=963&range=00-01 Stats: 40 lines in 18 files changed: 11 ins; 27 del; 2 mod Patch: https://git.openjdk.org/valhalla/pull/963.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/963/head:pull/963 PR: https://git.openjdk.org/valhalla/pull/963 From mchung at openjdk.org Wed Dec 13 18:10:18 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 13 Dec 2023 18:10:18 GMT Subject: [lworld] RFR: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types [v2] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 17:26:17 GMT, Roger Riggs wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove @compile > > test/jdk/valhalla/valuetypes/ArrayElementVarHandleTest.java line 28: > >> 26: * @test >> 27: * @summary test VarHandle on value class array >> 28: * @compile -XDenablePrimitiveClasses ArrayElementVarHandleTest.java > > It looks like the compiler does not need -XDenablePrimitiveClasses. > Except in RecursiveValueClass.java that still has a primitive class declaration. Updated. > test/jdk/valhalla/valuetypes/ObjectMethods.java line 119: > >> 117: static Stream identitiesData() { >> 118: return Stream.of( >> 119: Arguments.of(new Object(), false, false), > > The JEP doesn't say this (yet) but `new Object()` is an identity instance. java.util.Objects.isIdentityObject() and .isValueObject() will need to be updated too. It already handles that. The two arguments specify if the class of the instance is identity class or value class. The test special cases to verify if the class is `Object.class`, it's an identity object. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/963#discussion_r1425713015 PR Review Comment: https://git.openjdk.org/valhalla/pull/963#discussion_r1425714513 From rriggs at openjdk.org Wed Dec 13 21:19:00 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 13 Dec 2023 21:19:00 GMT Subject: [lworld] RFR: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types [v2] In-Reply-To: <4KCYuT5omFGupOrjbJ4Er6ZBLiKAXe6vyMaBzDEB-Yc=.b5e6d3c8-8a8f-41e3-b47e-4a4cdedb8eb2@github.com> References: <4KCYuT5omFGupOrjbJ4Er6ZBLiKAXe6vyMaBzDEB-Yc=.b5e6d3c8-8a8f-41e3-b47e-4a4cdedb8eb2@github.com> Message-ID: On Wed, 13 Dec 2023 18:10:18 GMT, Mandy Chung wrote: >> Migrate test/jdk/valhalla/valuetypes tests to use null-restricted types instead. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Remove @compile Marked as reviewed by rriggs (Committer). test/jdk/valhalla/valuetypes/LambdaMetaFactory/LambdaTest.java line 26: > 24: /* > 25: * @test > 26: * @run junit/othervm -XX:+EnableValhalla LambdaTest Just style suggestion in the order of jtreg tags, @summary should come before @run ------------- PR Review: https://git.openjdk.org/valhalla/pull/963#pullrequestreview-1780498389 PR Review Comment: https://git.openjdk.org/valhalla/pull/963#discussion_r1425890156 From mchung at openjdk.org Wed Dec 13 22:10:11 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 13 Dec 2023 22:10:11 GMT Subject: [lworld] RFR: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types [v2] In-Reply-To: References: <4KCYuT5omFGupOrjbJ4Er6ZBLiKAXe6vyMaBzDEB-Yc=.b5e6d3c8-8a8f-41e3-b47e-4a4cdedb8eb2@github.com> Message-ID: On Wed, 13 Dec 2023 21:12:37 GMT, Roger Riggs wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove @compile > > test/jdk/valhalla/valuetypes/LambdaMetaFactory/LambdaTest.java line 26: > >> 24: /* >> 25: * @test >> 26: * @run junit/othervm -XX:+EnableValhalla LambdaTest > > Just style suggestion in the order of jtreg tags, @summary should come before @run Hmm... we have a mixture of style. The jtreg document states `@summary` comes before the action. I will update them. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/963#discussion_r1425935340 From mchung at openjdk.org Wed Dec 13 22:15:19 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 13 Dec 2023 22:15:19 GMT Subject: [lworld] RFR: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types [v3] In-Reply-To: References: Message-ID: > Migrate test/jdk/valhalla/valuetypes tests to use null-restricted types instead. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: move @summary before @run ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/963/files - new: https://git.openjdk.org/valhalla/pull/963/files/d8683abd..1eb6a6da Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=963&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=963&range=01-02 Stats: 43 lines in 19 files changed: 21 ins; 21 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/963.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/963/head:pull/963 PR: https://git.openjdk.org/valhalla/pull/963 From roland at openjdk.org Thu Dec 14 08:51:24 2023 From: roland at openjdk.org (Roland Westrelin) Date: Thu, 14 Dec 2023 08:51:24 GMT Subject: [lworld] RFR: 8320296: [lworld] Fix profiling at array store subtype checks in Valhalla Message-ID: The issue is that the way valhalla collects profile data at `aastore` is different from what mainline does. It used to not matter because mainline didn't use part of the data it collects but that has changed. In mainline, no profile data is collected for `aaload` and every `aastore` has a `ReceiverTypeData` entry. In valhalla, `aaload` and `aastore` both make use of a `ArrayLoadStoreData` that's unrelated to `ReceiverTypeData`. What I propose to fix this is that `aaload` and `aastore` each have their own profile data structure: `ArrayLoadData` and `ArrayStoreData` . `ArrayLoadData` is identical to `ArrayLoadStoreData` so there's no change to profile collection code for `aaload`. `ArrayStoreData` is a subclass of `ReceiverTypeData` so profile data collection has to be adjusted. The reason for not having the same data structure for `aaload` and `aastore` is that it made fixing the profile collection code easier and increasing the number of types collected by `ReceiverTypeData` (if we ever want to do that) would not cause a lot of unused data to be collected at `aaload`. ------------- Commit messages: - another jvmci fix - jvmci fix - remove problem listed test - more - aarch64 fix - x86 fix Changes: https://git.openjdk.org/valhalla/pull/962/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=962&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320296 Stats: 389 lines in 19 files changed: 252 ins; 19 del; 118 mod Patch: https://git.openjdk.org/valhalla/pull/962.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/962/head:pull/962 PR: https://git.openjdk.org/valhalla/pull/962 From mchung at openjdk.org Thu Dec 14 17:19:05 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 14 Dec 2023 17:19:05 GMT Subject: [lworld] Integrated: 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 01:28:58 GMT, Mandy Chung wrote: > Migrate test/jdk/valhalla/valuetypes tests to use null-restricted types instead. This pull request has now been integrated. Changeset: 2dc05aa9 Author: Mandy Chung URL: https://git.openjdk.org/valhalla/commit/2dc05aa9c4bf47baf60b091c42cb4f9784e6d374 Stats: 3621 lines in 41 files changed: 478 ins; 2664 del; 479 mod 8321941: Migrate test/jdk/valhalla/valuetypes from primitive classes to null-restricted types Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/valhalla/pull/963 From thartmann at openjdk.org Fri Dec 15 12:50:12 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 15 Dec 2023 12:50:12 GMT Subject: [lworld] RFR: 8320296: [lworld] Fix profiling at array store subtype checks in Valhalla In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 08:59:52 GMT, Roland Westrelin wrote: > The issue is that the way valhalla collects profile data at `aastore` is different from what mainline does. It used to not matter because mainline didn't use part of the data it collects but that has changed. In mainline, no profile data is collected for `aaload` and every `aastore` has a `ReceiverTypeData` entry. In valhalla, `aaload` and `aastore` both make use of a `ArrayLoadStoreData` that's unrelated to `ReceiverTypeData`. What I propose to fix this is that `aaload` and `aastore` each have their own profile data structure: `ArrayLoadData` and `ArrayStoreData` . `ArrayLoadData` is identical to `ArrayLoadStoreData` so there's no change to profile collection code for `aaload`. `ArrayStoreData` is a subclass of `ReceiverTypeData` so profile data collection has to be adjusted. The reason for not having the same data structure for `aaload` and `aastore` is that it made fixing the profile collection code easier and increasing the number of types collected by `ReceiverTypeData` (if we ever want to do that) would not cause a lot of unused data to be collected at `aaload`. Looks good to me. Thanks for taking care of this, Roland! ------------- Marked as reviewed by thartmann (Committer). PR Review: https://git.openjdk.org/valhalla/pull/962#pullrequestreview-1783895541 From roland at openjdk.org Fri Dec 15 14:40:07 2023 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 15 Dec 2023 14:40:07 GMT Subject: [lworld] RFR: 8320296: [lworld] Fix profiling at array store subtype checks in Valhalla In-Reply-To: References: Message-ID: <2gYnv640yhkSLn8oByBSzwOqNKpUhY-1E2EZ8OlN6Tc=.532eb6fa-a967-49b6-b078-ca2a3d04e896@github.com> On Fri, 15 Dec 2023 12:47:09 GMT, Tobias Hartmann wrote: >> The issue is that the way valhalla collects profile data at `aastore` is different from what mainline does. It used to not matter because mainline didn't use part of the data it collects but that has changed. In mainline, no profile data is collected for `aaload` and every `aastore` has a `ReceiverTypeData` entry. In valhalla, `aaload` and `aastore` both make use of a `ArrayLoadStoreData` that's unrelated to `ReceiverTypeData`. What I propose to fix this is that `aaload` and `aastore` each have their own profile data structure: `ArrayLoadData` and `ArrayStoreData` . `ArrayLoadData` is identical to `ArrayLoadStoreData` so there's no change to profile collection code for `aaload`. `ArrayStoreData` is a subclass of `ReceiverTypeData` so profile data collection has to be adjusted. The reason for not having the same data structure for `aaload` and `aastore` is that it made fixing the profile collection code easier and increasing the number of types collected by `ReceiverTypeData` (if we ever want to do that) would not cause a lot of unused data to be collected at `aaload`. > > Looks good to me. Thanks for taking care of this, Roland! @TobiHartmann thanks for the review ------------- PR Comment: https://git.openjdk.org/valhalla/pull/962#issuecomment-1857985215 From roland at openjdk.org Fri Dec 15 14:43:06 2023 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 15 Dec 2023 14:43:06 GMT Subject: [lworld] Integrated: 8320296: [lworld] Fix profiling at array store subtype checks in Valhalla In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 08:59:52 GMT, Roland Westrelin wrote: > The issue is that the way valhalla collects profile data at `aastore` is different from what mainline does. It used to not matter because mainline didn't use part of the data it collects but that has changed. In mainline, no profile data is collected for `aaload` and every `aastore` has a `ReceiverTypeData` entry. In valhalla, `aaload` and `aastore` both make use of a `ArrayLoadStoreData` that's unrelated to `ReceiverTypeData`. What I propose to fix this is that `aaload` and `aastore` each have their own profile data structure: `ArrayLoadData` and `ArrayStoreData` . `ArrayLoadData` is identical to `ArrayLoadStoreData` so there's no change to profile collection code for `aaload`. `ArrayStoreData` is a subclass of `ReceiverTypeData` so profile data collection has to be adjusted. The reason for not having the same data structure for `aaload` and `aastore` is that it made fixing the profile collection code easier and increasing the number of types collected by `ReceiverTypeData` (if we ever want to do that) would not cause a lot of unused data to be collected at `aaload`. This pull request has now been integrated. Changeset: 814a5e93 Author: Roland Westrelin URL: https://git.openjdk.org/valhalla/commit/814a5e93cb392a77a43550bf8dab5ab9d52bdcfd Stats: 389 lines in 19 files changed: 252 ins; 19 del; 118 mod 8320296: [lworld] Fix profiling at array store subtype checks in Valhalla Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/valhalla/pull/962 From jbhateja at openjdk.org Wed Dec 20 13:39:13 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 20 Dec 2023 13:39:13 GMT Subject: [lworld] RFR: 8239003: [lworld] C2 should respect larval state when scalarizing Message-ID: <16qIwcpMwfghKHL2RR1lEsLJpBCgzuSe0ddBYD82MdM=.6339369a-ba8f-43da-beed-28525704e289@github.com> Hi All, Patch addresses the issue seen around unsafe updates to value objects within a loop. Since Unsafe.put* APIs returns a void, hence it does not alter JVM state. Due to this ciTypeFlow dataflow analysis does not encounter an inductive definition corresponding to updated value object within the loop, due to this C2 parser misses creating an inductive phi node on encountering loop header block. In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls. New behavior of unsafe inline expanders * makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state. * finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state. This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid. In addition compiler is now preventing elimination of allocation in larval state. Validation Status:- All the Valhalla JTREG tests are passing at various AVX level with / wo -XX:+DoptimizeALot. Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - 8239003: [lworld] C2 should respect larval state when scalarizing Changes: https://git.openjdk.org/valhalla/pull/964/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=964&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8239003 Stats: 176 lines in 8 files changed: 112 ins; 32 del; 32 mod Patch: https://git.openjdk.org/valhalla/pull/964.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/964/head:pull/964 PR: https://git.openjdk.org/valhalla/pull/964 From dsimms at openjdk.org Wed Dec 20 18:25:03 2023 From: dsimms at openjdk.org (David Simms) Date: Wed, 20 Dec 2023 18:25:03 GMT Subject: [lworld] RFR: 8321293: [lworld] First batch of migrated runtime tests [v2] In-Reply-To: References: Message-ID: On Thu, 7 Dec 2023 20:36:20 GMT, Frederic Parain wrote: >> First batch of migrated runtime tests. > > 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 three additional commits since the last revision: > > - Tests update and cleanup > - Merge remote-tracking branch 'upstream/lworld' into migrate_tests > - Migrate tests from using primitive classes to annotated value classes LGTM ------------- Marked as reviewed by dsimms (Committer). PR Review: https://git.openjdk.org/valhalla/pull/959#pullrequestreview-1791438949 From fparain at openjdk.org Wed Dec 20 20:47:00 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 20 Dec 2023 20:47:00 GMT Subject: [lworld] RFR: 8321293: [lworld] First batch of migrated runtime tests [v2] In-Reply-To: References: Message-ID: On Thu, 7 Dec 2023 20:36:20 GMT, Frederic Parain wrote: >> First batch of migrated runtime tests. > > 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 three additional commits since the last revision: > > - Tests update and cleanup > - Merge remote-tracking branch 'upstream/lworld' into migrate_tests > - Migrate tests from using primitive classes to annotated value classes Thank you for the review. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/959#issuecomment-1865112399 From fparain at openjdk.org Wed Dec 20 20:47:02 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 20 Dec 2023 20:47:02 GMT Subject: [lworld] Integrated: 8321293: [lworld] First batch of migrated runtime tests In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 19:27:45 GMT, Frederic Parain wrote: > First batch of migrated runtime tests. This pull request has now been integrated. Changeset: 1f9544e6 Author: Frederic Parain URL: https://git.openjdk.org/valhalla/commit/1f9544e6f53312ec908599b2de465716ecd22530 Stats: 1166 lines in 38 files changed: 550 ins; 392 del; 224 mod 8321293: [lworld] First batch of migrated runtime tests Reviewed-by: dsimms ------------- PR: https://git.openjdk.org/valhalla/pull/959 From mchung at openjdk.org Wed Dec 20 23:34:13 2023 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 20 Dec 2023 23:34:13 GMT Subject: [lworld] RFR: 8322573: [lworld] Add null-restricted value class array support in core reflection Message-ID: This patch fixes `Array::set` that if `null` is set on an element of a null-restricted arra, NPE will be thrown. ------------- Commit messages: - test clean up - 8322573: [lworld] Add null-restricted value class array support in core reflection Changes: https://git.openjdk.org/valhalla/pull/965/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=965&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322573 Stats: 103 lines in 3 files changed: 64 ins; 5 del; 34 mod Patch: https://git.openjdk.org/valhalla/pull/965.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/965/head:pull/965 PR: https://git.openjdk.org/valhalla/pull/965 From jbhateja at openjdk.org Thu Dec 21 06:46:17 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 21 Dec 2023 06:46:17 GMT Subject: [lworld] RFR: 8239003: [lworld] C2 should respect larval state when scalarizing [v2] In-Reply-To: <16qIwcpMwfghKHL2RR1lEsLJpBCgzuSe0ddBYD82MdM=.6339369a-ba8f-43da-beed-28525704e289@github.com> References: <16qIwcpMwfghKHL2RR1lEsLJpBCgzuSe0ddBYD82MdM=.6339369a-ba8f-43da-beed-28525704e289@github.com> Message-ID: > Hi All, > > Patch addresses the issue seen around unsafe updates to value objects within a loop. > > Since Unsafe.put* APIs returns a void, hence it does not alter JVM state. Due to this ciTypeFlow dataflow analysis does > not encounter an inductive definition corresponding to updated value object within the loop, due to this C2 parser misses > creating an inductive phi node on encountering loop header block. > > In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish > private buffer calls. > > New behavior of unsafe inline expanders > > * makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state. > * finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state. > This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode > and other is a buffer of compatible value type, but the IR still remains valid. > > In addition compiler is now preventing elimination of allocation in larval state. > > Validation Status:- > > All the Valhalla JTREG tests are passing at various AVX level with / wo -XX:+DoptimizeALot. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Minor modification in test case. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/964/files - new: https://git.openjdk.org/valhalla/pull/964/files/76b47a18..32721ea2 Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=964&range=01 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=964&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/964.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/964/head:pull/964 PR: https://git.openjdk.org/valhalla/pull/964 From fparain at openjdk.org Thu Dec 21 17:39:02 2023 From: fparain at openjdk.org (Frederic Parain) Date: Thu, 21 Dec 2023 17:39:02 GMT Subject: [lworld] RFR: 8322573: [lworld] Add null-restricted value class array support in core reflection In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 23:28:44 GMT, Mandy Chung wrote: > This patch fixes `Array::set` that if `null` is set on an element of a null-restricted arra, NPE will be thrown. LGTM ------------- Marked as reviewed by fparain (Committer). PR Review: https://git.openjdk.org/valhalla/pull/965#pullrequestreview-1793415298 From rriggs at openjdk.org Thu Dec 21 17:45:01 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Dec 2023 17:45:01 GMT Subject: [lworld] RFR: 8322573: [lworld] Add null-restricted value class array support in core reflection In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 23:28:44 GMT, Mandy Chung wrote: > This patch fixes `Array::set` that if `null` is set on an element of a null-restricted arra, NPE will be thrown. LGTM ------------- Marked as reviewed by rriggs (Committer). PR Review: https://git.openjdk.org/valhalla/pull/965#pullrequestreview-1793421081 From mchung at openjdk.org Thu Dec 21 17:45:02 2023 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 21 Dec 2023 17:45:02 GMT Subject: [lworld] Integrated: 8322573: [lworld] Add null-restricted value class array support in core reflection In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 23:28:44 GMT, Mandy Chung wrote: > This patch fixes `Array::set` that if `null` is set on an element of a null-restricted arra, NPE will be thrown. This pull request has now been integrated. Changeset: 474f876f Author: Mandy Chung URL: https://git.openjdk.org/valhalla/commit/474f876f63329e96596e9bdfbff7061e11f03f7c Stats: 103 lines in 3 files changed: 64 ins; 5 del; 34 mod 8322573: [lworld] Add null-restricted value class array support in core reflection Reviewed-by: fparain, rriggs ------------- PR: https://git.openjdk.org/valhalla/pull/965 From jbhateja at openjdk.org Fri Dec 22 06:45:29 2023 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 22 Dec 2023 06:45:29 GMT Subject: [lworld] RFR: 8239003: [lworld] C2 should respect larval state when scalarizing [v3] In-Reply-To: <16qIwcpMwfghKHL2RR1lEsLJpBCgzuSe0ddBYD82MdM=.6339369a-ba8f-43da-beed-28525704e289@github.com> References: <16qIwcpMwfghKHL2RR1lEsLJpBCgzuSe0ddBYD82MdM=.6339369a-ba8f-43da-beed-28525704e289@github.com> Message-ID: <9bTUTq3OcPuUSEMSh2zg8Ocl4o5prln0zT_c1KRUr2U=.05c667b6-14cc-4f0d-bf1a-5b2a2eab87af@github.com> > Hi All, > > Patch addresses issues around unsafe updates to value objects within a loop and larval state preservation by suppressing > scalarization of value objects in larval state. > > Since Unsafe.put* APIs returns a void, hence it does not alter JVM state. Due to this ciTypeFlow dataflow analysis does > not encounter an inductive definition corresponding to updated value object within the loop, due to this C2 parser misses > creating an inductive phi node on encountering loop header block. > > In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish > private buffer calls. > > New behavior of unsafe inline expanders > > * makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state. > * finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state. > This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode > and other is a buffer of compatible value type, but the IR still remains valid. > > In addition compiler is now preventing elimination of allocation in larval state. > > Validation Status:- > > All the Valhalla JTREG tests are passing at various AVX level with / wo -XX:+DoptimizeALot. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Handling for passing larval state value objects across method calls. ------------- Changes: - all: https://git.openjdk.org/valhalla/pull/964/files - new: https://git.openjdk.org/valhalla/pull/964/files/32721ea2..8eb0b01e Webrevs: - full: https://webrevs.openjdk.org/?repo=valhalla&pr=964&range=02 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=964&range=01-02 Stats: 110 lines in 3 files changed: 106 ins; 0 del; 4 mod Patch: https://git.openjdk.org/valhalla/pull/964.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/964/head:pull/964 PR: https://git.openjdk.org/valhalla/pull/964