From xgong at openjdk.org  Mon Apr  3 06:42:47 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 3 Apr 2023 06:42:47 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v3]
In-Reply-To: <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
Message-ID: <awLkaSBECZxAtr1DRFie-TstsIMtTrqzVHBgNZrpjRc=.797282ed-313c-403f-b260-574383770689@github.com>

On Wed, 29 Mar 2023 00:28:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size.

src/hotspot/share/opto/inlinetypenode.cpp line 492:

> 490:       if (ary_type != NULL) {
> 491:         decorators |= IS_ARRAY;
> 492:       }

These code could be removed to the `else` branch in line-499.

src/hotspot/share/opto/inlinetypenode.cpp line 497:

> 495:       assert(is_java_primitive(bt) || adr->bottom_type()->is_ptr_to_narrowoop() == UseCompressedOops, "inconsistent");
> 496:       if (value->bottom_type()->isa_vect()) {
> 497:         Node* store = kit->gvn().transform(StoreVectorNode::make(0, kit->control(), kit->memory(adr), adr, adr_type, value, vec_len));

Why not keeping "bundle_size() > 1" as the condition, and adding the original assertion like before ?

assert(value->bottom_type()->isa_vect() && value->bottom_type()->is_vect()->length() == (uint)ft->bundle_size(), "");

Or maybe at least add an assertion like:

assert(value->bottom_type()->is_vect()->length() == (uint)ft->bundle_size(), "");

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1155533103
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1155536605

From xgong at openjdk.org  Mon Apr  3 08:10:53 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 3 Apr 2023 08:10:53 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v3]
In-Reply-To: <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
Message-ID: <uFae7yPcEKf7QxS3oiGlII5cJMqwNNB-1S2rFF2PKuY=.644cb673-3f08-4e0e-b9fe-fec0296ef250@github.com>

On Wed, 29 Mar 2023 00:28:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size.

src/hotspot/share/runtime/deoptimization.cpp line 1395:

> 1393:   while (ik != NULL) {
> 1394:     for (AllFieldStream fs(ik); !fs.done(); fs.next()) {
> 1395:       if (!fs.access_flags().is_static() && !fs.is_multifield() && (!skip_internal || !fs.access_flags().is_internal())) {

Does it need special handling for the vectorized multifield base?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1155619063

From xgong at openjdk.org  Tue Apr  4 07:31:38 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 4 Apr 2023 07:31:38 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v3]
In-Reply-To: <uFae7yPcEKf7QxS3oiGlII5cJMqwNNB-1S2rFF2PKuY=.644cb673-3f08-4e0e-b9fe-fec0296ef250@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
 <uFae7yPcEKf7QxS3oiGlII5cJMqwNNB-1S2rFF2PKuY=.644cb673-3f08-4e0e-b9fe-fec0296ef250@github.com>
Message-ID: <KE0oJ7KxebUrssWUzkZADKFWmpc3KteRKz8BLYhC88U=.2401202a-2eb0-482e-9a3a-4976b8a7bfad@github.com>

On Mon, 3 Apr 2023 08:07:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size.
>
> src/hotspot/share/runtime/deoptimization.cpp line 1395:
> 
>> 1393:   while (ik != NULL) {
>> 1394:     for (AllFieldStream fs(ik); !fs.done(); fs.next()) {
>> 1395:       if (!fs.access_flags().is_static() && !fs.is_multifield() && (!skip_internal || !fs.access_flags().is_internal())) {
> 
> Does it need special handling for the vectorized multifield base?

I think it needs the special handling for vectorized multifield. I ran a simple case with `-XX:+DeoptimizeALot`, and it shows the crash:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/runtime/stackValue.cpp:194), pid=373245, tid=373246
#  Error: ShouldNotReachHere()
#
# JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-3cf3c3d81)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-3cf3c3d81, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x1937848]  StackValue* StackValue::create_stack_value<RegisterMap>(frame const*, RegisterMap const*, ScopeValue*) [clone .localalias]+0x2c8
#
# Core dump will be written. Default location: /tmp/core.373245
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -XX:CompileCommand=print,Test.func -XX:+UnlockDiagnosticVMOptions -XX:-DebugNonSafepoints -XX:-TieredCompilation -XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport -XX:+DeoptimizeALot --add-modules=jdk.incubator.vector Test

Host: xiagon01-01-arm-vm, AArch64, 160 cores, 190G, Ubuntu 22.04.1 LTS
Time: Tue Apr  4 07:14:11 2023 UTC elapsed time: 1.133206 seconds (0d 0h 0m 1s)

---------------  T H R E A D  ---------------

Current thread (0x0000fffdfc02b200):  JavaThread "main" [_thread_in_vm, id=373246, stack(0x0000fffe03820000,0x0000fffe03a20000)]

Stack: [0x0000fffe03820000,0x0000fffe03a20000],  sp=0x0000fffe03a1c850,  free space=2034k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1937848]  StackValue* StackValue::create_stack_value<RegisterMap>(frame const*, RegisterMap const*, ScopeValue*) [clone .localalias]+0x2c8  (stackValue.cpp:194)
V  [libjvm.so+0xb31b58]  reassign_fields_by_klass(InstanceKlass*, frame*, RegisterMap*, ObjectValue*, int, oop, bool, int, JavaThread*)+0x418  (deoptimization.cpp:1425)
V  [libjvm.so+0xb34398]  Deoptimization::reassign_fields(frame*, RegisterMap*, GrowableArray<ScopeValue*>*, bool, bool, JavaThread*)+0x3b4  (deoptimization.cpp:1568)
V  [libjvm.so+0xb3709c]  rematerialize_objects(JavaThread*, int, CompiledMethod*, frame&, RegisterMap&, GrowableArray<compiledVFrame*>*, bool&)+0x74c  (deoptimization.cpp:283)
V  [libjvm.so+0xb39324]  Deoptimization::fetch_unroll_info_helper(JavaThread*, int)+0x404  (deoptimization.cpp:438)
V  [libjvm.so+0xb3a740]  Deoptimization::fetch_unroll_info(JavaThread*, int)+0xc0  (deoptimization.cpp:176)
v  ~DeoptimizationBlob 0x0000fffe0087d900
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~DeoptimizationBlob 0x0000fffe0087d900
J 176 c2 jdk.incubator.vector.IntVector$$Lambda$38+0x0000000801064bc0.load(Ljava/lang/Object;JLjdk/internal/vm/vector/VectorSupport$VectorSpecies;)Ljdk/internal/vm/vector/VectorSupport$VectorPayload; jdk.incubator.vector at 21-internal (17 bytes) @ 0x0000fffe008e9cec [0x0000fffe008e9980+0x000000000000036c]
J 204 c2 Test.func(Z)V (145 bytes) @ 0x0000fffe00900ef0 [0x0000fffe00900cc0+0x0000000000000230]
j  Test.main([Ljava/lang/String;)V+22
v  ~StubRoutines::call_stub 0x0000fffe0079017c

Fixing is not urgent. We can fix this part after the basic support is merged. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1156841049

From xgong at openjdk.org  Tue Apr  4 08:28:38 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 4 Apr 2023 08:28:38 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v3]
In-Reply-To: <KE0oJ7KxebUrssWUzkZADKFWmpc3KteRKz8BLYhC88U=.2401202a-2eb0-482e-9a3a-4976b8a7bfad@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
 <uFae7yPcEKf7QxS3oiGlII5cJMqwNNB-1S2rFF2PKuY=.644cb673-3f08-4e0e-b9fe-fec0296ef250@github.com>
 <KE0oJ7KxebUrssWUzkZADKFWmpc3KteRKz8BLYhC88U=.2401202a-2eb0-482e-9a3a-4976b8a7bfad@github.com>
Message-ID: <twJdqYffsyBh43P1Aqh2oJx5K1ZzbW3ps1ZLuEiwtGE=.7b5fb786-90d4-4b33-9ddb-ec03ac33d081@github.com>

On Tue, 4 Apr 2023 07:28:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/runtime/deoptimization.cpp line 1395:
>> 
>>> 1393:   while (ik != NULL) {
>>> 1394:     for (AllFieldStream fs(ik); !fs.done(); fs.next()) {
>>> 1395:       if (!fs.access_flags().is_static() && !fs.is_multifield() && (!skip_internal || !fs.access_flags().is_internal())) {
>> 
>> Does it need special handling for the vectorized multifield base?
>
> I think it needs the special handling for vectorized multifield. I ran a simple case with `-XX:+DeoptimizeALot`, and it shows the crash:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/runtime/stackValue.cpp:194), pid=373245, tid=373246
> #  Error: ShouldNotReachHere()
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-3cf3c3d81)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-3cf3c3d81, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # V  [libjvm.so+0x1937848]  StackValue* StackValue::create_stack_value<RegisterMap>(frame const*, RegisterMap const*, ScopeValue*) [clone .localalias]+0x2c8
> #
> # Core dump will be written. Default location: /tmp/core.373245
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> ---------------  S U M M A R Y ------------
> 
> Command Line: -XX:CompileCommand=print,Test.func -XX:+UnlockDiagnosticVMOptions -XX:-DebugNonSafepoints -XX:-TieredCompilation -XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport -XX:+DeoptimizeALot --add-modules=jdk.incubator.vector Test
> 
> Host: xiagon01-01-arm-vm, AArch64, 160 cores, 190G, Ubuntu 22.04.1 LTS
> Time: Tue Apr  4 07:14:11 2023 UTC elapsed time: 1.133206 seconds (0d 0h 0m 1s)
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x0000fffdfc02b200):  JavaThread "main" [_thread_in_vm, id=373246, stack(0x0000fffe03820000,0x0000fffe03a20000)]
> 
> Stack: [0x0000fffe03820000,0x0000fffe03a20000],  sp=0x0000fffe03a1c850,  free space=2034k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1937848]  StackValue* StackValue::create_stack_value<RegisterMap>(frame const*, RegisterMap const*, ScopeValue*) [clone .localalias]+0x2c8  (stackValue.cpp:194)
> V  [libjvm.so+0xb31b58]  reassign_fields_by_klass(InstanceKlass*, frame*, RegisterMap*, ObjectValue*, int, oop, bool, int, JavaThread*)+0x418  (deoptimization.cpp:1425)
> V  [libjvm.so+0xb34398]  Deoptimization::reassign_fields(frame*, RegisterMap*, GrowableArray<ScopeValue*>*, bool, bool, JavaThread*)+0x3b4  (deoptimization.cpp:1568)
> V  [libjvm.so+0xb3709c]  rematerialize_objects(JavaThread*, int, CompiledMethod*, frame&, RegisterMap&, GrowableArray<compiledVFrame*>*, bool&)+0x74c  (deoptimization.cpp:283)
> V  [libjvm.so+0xb39324]  Deoptimization::fetch_unroll_info_helper(JavaThread*, int)+0x404  (deoptimization.cpp:438)
> V  [libjvm.so+0xb3a740]  Deoptimization::fetch_unroll_info(JavaThread*, int)+0xc0  (deoptimization.cpp:176)
> v  ~DeoptimizationBlob 0x0000fffe0087d900
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> v  ~DeoptimizationBlob 0x0000fffe0087d900
> J 176 c2 jdk.incubator.vector.IntVector$$Lambda$38+0x0000000801064bc0.load(Ljava/lang/Object;JLjdk/internal/vm/vector/VectorSupport$VectorSpecies;)Ljdk/internal/vm/vector/VectorSupport$VectorPayload; jdk.incubator.vector at 21-internal (17 bytes) @ 0x0000fffe008e9cec [0x0000fffe008e9980+0x000000000000036c]
> J 204 c2 Test.func(Z)V (145 bytes) @ 0x0000fffe00900ef0 [0x0000fffe00900cc0+0x0000000000000230]
> j  Test.main([Ljava/lang/String;)V+22
> v  ~StubRoutines::call_stub 0x0000fffe0079017c
> 
> Fixing is not urgent. We can fix this part after the basic support is merged. Thanks!

I created a prototype fix based on my local changes. Please see: https://github.com/XiaohongGong/valhalla/pull/2/commits/a17ed7d4364bb6408c29655996794640694e0ea5
Hope this could help. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1156905128

From jbhateja at openjdk.org  Tue Apr  4 08:41:27 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 4 Apr 2023 08:41:27 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v4]
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <aohxoAA_lpTSsVYgCvXc5QCys91AkHP0kx3ZEqIcekc=.4ecc2d82-cc83-4306-85ef-212ad3674562@github.com>

> Please find below the summary of changes included with the patch:
>   
> a) _ci Model:_
>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
> 
> b) _C1 compiler:_
>    Special handling to copy entire multifield bundle during withfield bytecode processing.
> 
> c) _C2 compiler:_
>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
> 
> d) _Runtime:_
>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
> 
> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
> 
> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
> 
> More information can be found at following link
> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
> 
> Please share your feedback and suggestions.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Fix initialization of @Stable annotated dummyVectorMF field, it enabled logic folding in dummyVectorMF() method and reduced overall JIT code size.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/62661134..6a213f94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/833.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833

PR: https://git.openjdk.org/valhalla/pull/833

From jbhateja at openjdk.org  Thu Apr  6 08:58:21 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 6 Apr 2023 08:58:21 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>

> Please find below the summary of changes included with the patch:
>   
> a) _ci Model:_
>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
> 
> b) _C1 compiler:_
>    Special handling to copy entire multifield bundle during withfield bytecode processing.
> 
> c) _C2 compiler:_
>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
> 
> d) _Runtime:_
>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
> 
> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
> 
> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
> 
> More information can be found at following link
> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
> 
> Please share your feedback and suggestions.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup vector box expansion handling to leverage existing InlineTypeNode storage and flow merging routines.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/6a213f94..9d777691

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=04
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=03-04

  Stats: 197 lines in 4 files changed: 14 ins; 166 del; 17 mod
  Patch: https://git.openjdk.org/valhalla/pull/833.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833

PR: https://git.openjdk.org/valhalla/pull/833

From xgong at openjdk.org  Thu Apr  6 09:51:45 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 6 Apr 2023 09:51:45 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
Message-ID: <9MMxKiLj2syhAMQ47VbVilzrF-D-XKaUvu5sb9-4FPs=.6612dfb4-f600-4f9e-8e60-a86fcbc307d3@github.com>

On Thu, 6 Apr 2023 08:58:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup vector box expansion handling to leverage existing InlineTypeNode storage and flow merging routines.

Thanks for the updating! So the correspond `expand_vunbox_node` can also be implemented by calling `InlineTypeNode::make_from_oop` ?

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/833#issuecomment-1498784430

From davidalayachew at gmail.com  Thu Apr  6 23:19:26 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 6 Apr 2023 19:19:26 -0400
Subject: Trying to understand atomicity from the new valhalla-spec-observers
 post
Message-ID: <CAA9v-_PCa+8m7XHVnh8tBOxEuPf1GjgZS-ocQ661hB5Jig8nDA@mail.gmail.com>

Hello Valhalla Dev Team,

The post I am referring to is this one.

https://mail.openjdk.org/pipermail/valhalla-spec-observers/2023-March/002206.html

Specifically, the quote I want to highlight is this one.

> Framed this way, the Valhalla performance story
> simplifies to:
>
>   - Give up identity, get flattening on the stack;
>   - Further give up explicit initialization, get
>         flattening for small objects on the heap;
>   - Further give up atomicity, get flattening for
>         larger objects on the heap.

I have a basic understanding of atomicity -- you can see/interact with the
before and after, but not the in between. However, if I want to change an
object out to use another one, I have to replace it incrementally since it
is a larger object, as mentioned. As a result, if I don't have atomicity,
then someone might be able to see the in between -- when part of the object
is old data and some of the object is new data. Even if I zero out the data
before doing so, that just widens my chance of running into the same
problem, but for different combinations of data.

Now, if the data we are working with is unchanging after initialization,
then I see the value in this. Let's say I construct a List whose types are
these non-atomic objects. Well, as long as all data contained within that
List never changes, then I am still safe. And when I say never changes, I
mean the List containing the objects, the components of each object, and
even the components components, etc all the way down to the leaf nodes of
each component of each object in the List, never change.

But the post seems to say something different. It seems to say that
atomicity can be given up, even when dealing with mutability.

My question is, in what situation would we want to give up atomicity while
still maintaining mutability? And that goes triple when dealing with larger
objects.

I want to use and test this feature myself, but I can't think of a
situation where I would use it with mutability because I fear shooting
myself in the foot when I accidentally read and write at the same time. How
do I give up atomicity and keep mutability without shooting myself in the
foot?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230406/f3d1fe4c/attachment-0001.htm>

From liangchenblue at gmail.com  Thu Apr  6 23:34:58 2023
From: liangchenblue at gmail.com (-)
Date: Thu, 6 Apr 2023 18:34:58 -0500
Subject: Trying to understand atomicity from the new
 valhalla-spec-observers post
In-Reply-To: <CAA9v-_PCa+8m7XHVnh8tBOxEuPf1GjgZS-ocQ661hB5Jig8nDA@mail.gmail.com>
References: <CAA9v-_PCa+8m7XHVnh8tBOxEuPf1GjgZS-ocQ661hB5Jig8nDA@mail.gmail.com>
Message-ID: <CABe8uE2ycFCYOQ4ie4TpWs41oTWo80=+3W9LDLUoSHUXedkAeA@mail.gmail.com>

An example may be a Vector of 3 integers representing a coordinate in a 3d
voxel game. In such a case, each of the 3 integers has independent min and
max bounds, so tear among the 3 values doesn't create invalid coordinates.
This value can thus give up atomicity; it's up to users to access such a
value in the correct program order (like with volatile, synchronization)
shall they share it across threads.

On Thu, Apr 6, 2023, 6:19 PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Valhalla Dev Team,
>
> The post I am referring to is this one.
>
>
> https://mail.openjdk.org/pipermail/valhalla-spec-observers/2023-March/002206.html
>
> Specifically, the quote I want to highlight is this one.
>
> > Framed this way, the Valhalla performance story
> > simplifies to:
> >
> >   - Give up identity, get flattening on the stack;
> >   - Further give up explicit initialization, get
> >         flattening for small objects on the heap;
> >   - Further give up atomicity, get flattening for
> >         larger objects on the heap.
>
> I have a basic understanding of atomicity -- you can see/interact with the
> before and after, but not the in between. However, if I want to change an
> object out to use another one, I have to replace it incrementally since it
> is a larger object, as mentioned. As a result, if I don't have atomicity,
> then someone might be able to see the in between -- when part of the object
> is old data and some of the object is new data. Even if I zero out the data
> before doing so, that just widens my chance of running into the same
> problem, but for different combinations of data.
>
> Now, if the data we are working with is unchanging after initialization,
> then I see the value in this. Let's say I construct a List whose types are
> these non-atomic objects. Well, as long as all data contained within that
> List never changes, then I am still safe. And when I say never changes, I
> mean the List containing the objects, the components of each object, and
> even the components components, etc all the way down to the leaf nodes of
> each component of each object in the List, never change.
>
> But the post seems to say something different. It seems to say that
> atomicity can be given up, even when dealing with mutability.
>
> My question is, in what situation would we want to give up atomicity while
> still maintaining mutability? And that goes triple when dealing with larger
> objects.
>
> I want to use and test this feature myself, but I can't think of a
> situation where I would use it with mutability because I fear shooting
> myself in the foot when I accidentally read and write at the same time. How
> do I give up atomicity and keep mutability without shooting myself in the
> foot?
>
> Thank you for your time and help!
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230406/5896931d/attachment.htm>

From jbhateja at openjdk.org  Fri Apr  7 00:33:10 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Apr 2023 00:33:10 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <Oy421JGZIXUSyP15tcCLAYlSR46bPaSAhL5B-QrwTOc=.b9ba5c8b-2760-4ddc-93db-a63cbc40e46d@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
 <rGkJDs-gULgPWzj82dy9vssTNjulizUg8uWoZvt7cg8=.64449792-5e5e-42da-9713-9167b4cff3bc@github.com>
 <Oy421JGZIXUSyP15tcCLAYlSR46bPaSAhL5B-QrwTOc=.b9ba5c8b-2760-4ddc-93db-a63cbc40e46d@github.com>
Message-ID: <GOxWMj8GnUAFZ9CuDekmOEq2-fa3GqMjjbFgr2zaCsg=.5abdf835-3263-4869-b156-220031304973@github.com>

On Thu, 30 Mar 2023 03:42:51 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> BTW, methods like `is_multifield, is_multifield_base` can be removed. `secondary_fields_count() > 1` can be used as a replacement to `is_multifield_base()`, right?

It should add value to still keep is_multifield and is_multifield_base since it allows skipping over synthetic fields (non-base) at places.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160352423

From jbhateja at openjdk.org  Fri Apr  7 00:33:11 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Apr 2023 00:33:11 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <cFR2Xopmhln3Jl9k2nofLJd6fDnQIAqsZ811lM0gq7U=.7429c49d-3cd9-40ef-b599-6535b39f6545@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <cFR2Xopmhln3Jl9k2nofLJd6fDnQIAqsZ811lM0gq7U=.7429c49d-3cd9-40ef-b599-6535b39f6545@github.com>
Message-ID: <AMT3NWnSFBFcwyRFdQuuzCM8f387NQn0BT7Myx38Sz8=.5b989e84-8ed0-492e-bb2f-02ebe361b6c9@github.com>

On Tue, 21 Mar 2023 08:50:57 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup vector box expansion handling to leverage existing InlineTypeNode storage and flow merging routines.
>
> src/hotspot/share/opto/vector.cpp line 401:
> 
>> 399:                                                      buffer_adr_type,
>> 400:                                                      value,
>> 401:                                                      num_elem));
> 
> Can we simply call `InlineTypeNode::buffer()` here?

Logic is now simplified, vector box IR also comply with the composition of concrete vector class which is a value type encapsulating primitive type payload.
![image](https://user-images.githubusercontent.com/59989778/230422964-80eb40cc-0162-4de2-9c61-e5a42495fd1e.png)

This allows direct usage of InlineTypeNode::store routine which does a recursive field traversal to store scalarized fields into buffer.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160351999

From davidalayachew at gmail.com  Fri Apr  7 00:37:07 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 6 Apr 2023 20:37:07 -0400
Subject: Trying to understand atomicity from the new
 valhalla-spec-observers post
Message-ID: <CAA9v-_OaXxnuwuKh5DhVhFmCxx5zJBRKBem2mEb5e_uviZ-Sog@mail.gmail.com>

Hello,

Thank you for responding!

> An example may be a Vector of 3 integers representing
> a coordinate in a 3d voxel game. In such a case, each
> of the 3 integers has independent min and max bounds,
> so tear among the 3 values doesn't create invalid
> coordinates.

Well, independent min and max bounds would just make it harder to get an
illegal coordinate, but it wouldn't prevent it entirely, correct?

And either way, illegal or not, the tearing could still end up with
coordinates that should not have been given in the first place.

Following your analogy, if I have the player go up and forward in (what
should be an atomic) single step, then tearing may result in the player
momentarily going only forward or only up. Maybe that is a bad example, but
hopefully my point is clear.

> This value can thus give up atomicity; it's up to
> users to access such a value in the correct program
> order (like with volatile, synchronization) shall
> they share it across threads.

I see, ok. Also, I think this part of your comment addresses the issues I
had with the first part of your comment. Maybe you were trying to say
something that I didn't understand, but these solutions fully address my
concerns.

But ok. So, when giving up atomicity, possible solutions can be volatile,
synchronization, amongst others to prevent damage caused by mutability.

So, it sounds like the exact same solutions that allow me to stay safe when
I mix mutability with concurrency are the exact same solutions that allow
me to stay safe when mixing mutability non-atomicity?

Thank you for your help and insight!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230406/1ef4c2a2/attachment-0001.htm>

From davidalayachew at gmail.com  Fri Apr  7 00:39:36 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 6 Apr 2023 20:39:36 -0400
Subject: Trying to understand atomicity from the new
 valhalla-spec-observers post
In-Reply-To: <CABe8uE2ycFCYOQ4ie4TpWs41oTWo80=+3W9LDLUoSHUXedkAeA@mail.gmail.com>
References: <CAA9v-_PCa+8m7XHVnh8tBOxEuPf1GjgZS-ocQ661hB5Jig8nDA@mail.gmail.com>
 <CABe8uE2ycFCYOQ4ie4TpWs41oTWo80=+3W9LDLUoSHUXedkAeA@mail.gmail.com>
Message-ID: <CAA9v-_PdvPA4XEY52KUVaH9oGg3ws0wAUY-Ke3VwCE0sAvGe+Q@mail.gmail.com>

Hello,

Thank you for responding! (Sorry for triple sending, mailing lists are
difficult for me to navigate, so I keep making this mistake)

> An example may be a Vector of 3 integers representing
> a coordinate in a 3d voxel game. In such a case, each
> of the 3 integers has independent min and max bounds,
> so tear among the 3 values doesn't create invalid
> coordinates.

Well, independent min and max bounds would just make it harder to get an
illegal coordinate, but it wouldn't prevent it entirely, correct?

And either way, illegal or not, the tearing could still end up with
coordinates that should not have been given in the first place.

Following your analogy, if I have the player go up and forward in (what
should be an atomic) single step, then tearing may result in the player
momentarily going only forward or only up. Maybe that is a bad example, but
hopefully my point is clear.

> This value can thus give up atomicity; it's up to
> users to access such a value in the correct program
> order (like with volatile, synchronization) shall
> they share it across threads.

I see, ok. Also, I think this part of your comment addresses the issues I
had with the first part of your comment. Maybe you were trying to say
something that I didn't understand, but these solutions fully address them.

But ok. So, when giving up atomicity, possible solutions can be volatile,
synchronization, amongst others to prevent damage caused by mutability.

So, it sounds like the exact same solutions that allow me to stay safe when
I mix mutability with concurrency are the exact same solutions that allow
me to stay safe when mixing mutability non-atomicity?

Thank you for your help and insight!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230406/7cae4cff/attachment.htm>

From jbhateja at openjdk.org  Fri Apr  7 00:44:13 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Apr 2023 00:44:13 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v6]
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <JRpDpClF_izwVLEyQI90YUR298WfnDv2gJYpPuuiODQ=.9348c8f7-cc71-43e9-8bae-f2960f4919cc@github.com>

> Please find below the summary of changes included with the patch:
>   
> a) _ci Model:_
>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
> 
> b) _C1 compiler:_
>    Special handling to copy entire multifield bundle during withfield bytecode processing.
> 
> c) _C2 compiler:_
>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
> 
> d) _Runtime:_
>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
> 
> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
> 
> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
> 
> More information can be found at following link
> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
> 
> Please share your feedback and suggestions.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/9d777691..c1bb7fd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=05
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=04-05

  Stats: 27 lines in 6 files changed: 6 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/833.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833

PR: https://git.openjdk.org/valhalla/pull/833

From jbhateja at openjdk.org  Fri Apr  7 00:44:14 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Apr 2023 00:44:14 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v3]
In-Reply-To: <awLkaSBECZxAtr1DRFie-TstsIMtTrqzVHBgNZrpjRc=.797282ed-313c-403f-b260-574383770689@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
 <awLkaSBECZxAtr1DRFie-TstsIMtTrqzVHBgNZrpjRc=.797282ed-313c-403f-b260-574383770689@github.com>
Message-ID: <CxYiGXCVcFcjzYwuzc0yVeUFsFAA3j32TSqCmxxcyF8=.240ca6ad-295b-4588-8ea4-5fccd80e8e7d@github.com>

On Mon, 3 Apr 2023 06:34:49 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size.
>
> src/hotspot/share/opto/inlinetypenode.cpp line 492:
> 
>> 490:       if (ary_type != NULL) {
>> 491:         decorators |= IS_ARRAY;
>> 492:       }
> 
> These code could be removed to the `else` branch in line-499.

Done

> src/hotspot/share/opto/inlinetypenode.cpp line 497:
> 
>> 495:       assert(is_java_primitive(bt) || adr->bottom_type()->is_ptr_to_narrowoop() == UseCompressedOops, "inconsistent");
>> 496:       if (value->bottom_type()->isa_vect()) {
>> 497:         Node* store = kit->gvn().transform(StoreVectorNode::make(0, kit->control(), kit->memory(adr), adr, adr_type, value, vec_len));
> 
> Why not keeping "bundle_size() > 1" as the condition, and adding the original assertion like before ?
> 
> assert(value->bottom_type()->isa_vect() && value->bottom_type()->is_vect()->length() == (uint)ft->bundle_size(), "");
> 
> Or maybe at least add an assertion like:
> 
> assert(value->bottom_type()->is_vect()->length() == (uint)ft->bundle_size(), "");

Done

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160355120
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160354992

From jbhateja at openjdk.org  Fri Apr  7 00:44:14 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Apr 2023 00:44:14 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v6]
In-Reply-To: <BGPveSkACVXdmJU_wYCB2OaO9cKEJ8-U_Kzs1GtLmNE=.0a489d1c-2d17-40a9-8bb6-55aed8b96cb9@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <BGPveSkACVXdmJU_wYCB2OaO9cKEJ8-U_Kzs1GtLmNE=.0a489d1c-2d17-40a9-8bb6-55aed8b96cb9@github.com>
Message-ID: <nN7mlQXkSo5R63Zk6FOGbAb5jmqSefDRevOi46EnPCo=.662340b0-33ac-4286-b7aa-1dc9cd01e9be@github.com>

On Tue, 21 Mar 2023 09:21:06 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/share/opto/vector.cpp line 520:
> 
>> 518: 
>> 519:     int elem_size = type2aelembytes(bt);
>> 520:     Node* vec_val_load = get_loaded_payload(vec_unbox);
> 
> We could also optimize the VectorUnbox to the vector node with `VectorUnbox::Identity()`. So `get_loaded_payload()` is needless?

> Thanks for the updating! So the correspond `expand_vunbox_node` can also be implemented by calling `InlineTypeNode::make_from_oop` ?

Yes, every time C2 sees an value instance it does create an InlineTypeNode IR by loading the appropriate fields from object using InlineTypeNode::make_from_oop,

> Hi @jatin-bhateja ,
> 
> I ran an unit test on a ARM NEON system, and the jvm crashes with following log:
> 
> ```
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/loopnode.cpp:5871), pid=544741, tid=544757
> #  assert(false) failed: Bad graph detected in build_loop_late
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-558fb2e03)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-558fb2e03, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # V  [libjvm.so+0x13b395c]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x18c
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /mnt/local/code/test/vector_api/aarch64/armie/core.544741)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> ```
> 
> And here is the call stack:
> 
> ```
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x0000fffe0008dc80):  JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=544757, stack(0x0000fffe24d00000,0x0000fffe24f00000)]
> 
> 
> Current CompileTask:
> C2:    377  172             jdk.incubator.vector.IntVector::fromArray0Template (39 bytes)
> 
> Stack: [0x0000fffe24d00000,0x0000fffe24f00000],  sp=0x0000fffe24ef9920,  free space=2022k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x13b395c]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x18c  (loopnode.cpp:5871)
> V  [libjvm.so+0x13b4194]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xd4  (loopnode.cpp:5775)
> V  [libjvm.so+0x13b4aa4]  PhaseIdealLoop::build_and_optimize()+0x4d0  (loopnode.cpp:4403)
> V  [libjvm.so+0xa30f28]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x1e8  (loopnode.hpp:1086)
> V  [libjvm.so+0xa2be08]  Compile::Optimize()+0x428  (compile.cpp:2828)
> V  [libjvm.so+0xa2f10c]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x11ec  (compile.cpp:842)
> V  [libjvm.so+0x829cd4]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x3f0  (c2compiler.cpp:113)
> V  [libjvm.so+0xa3c410]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbb0  (compileBroker.cpp:2237)
> V  [libjvm.so+0xa3cd44]  CompileBroker::compiler_thread_loop()+0x3f4  (compileBroker.cpp:1916)
> V  [libjvm.so+0xf92068]  JavaThread::thread_main_inner()+0x2f4  (javaThread.cpp:710)
> V  [libjvm.so+0x1a3afb8]  Thread::call_run()+0xf8  (thread.cpp:224)
> V  [libjvm.so+0x15f6814]  thread_native_entry(Thread*)+0x100  (os_linux.cpp:739)
> C  [libc.so.6+0x7d5c8]
> ```
> 
> The unit test is:
> 
> ```
> static VectorSpecies<Integer> I_SPECIES = IntVector.SPECIES_PREFERRED;
> 
> for (int i = 0; i < LENGTH; i += vl) {
>             var av = IntVector.fromArray(I_SPECIES, ia, i);
>             var bv = IntVector.fromArray(I_SPECIES, ib, i);
>             av.lanewise(VectorOperators.ADD, bv).intoArray(ic, i);
> }
> ```
> 
> And I cannot reproduce the same issue on a X86 AVX-512 machine. But from the log, it seems not an AArch64 backend issue. So do you have any idea or met this issue before?
> 
> BTW, is it possible to split this big patch into two parts: 1) multi-field vectorization part 2) hotspot compiler support for vector intrinsification part. This patch is too big which covers several compiler/runtime support parts. It's not so easy to analysis the issue to me once it happens. And I also tried to separate it by myself. But unfortunately, I also met another JVM crash issue which may related to the register allocation to vector registers on AArch64 when testing the "multi-fields" vectorization changes. I'm not sure whether I have missed something when doing the separation. But it will be helpful to look at the issue with your help. Thanks a lot!
> 
> Best Regards, Xiaohong

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160355296

From jbhateja at openjdk.org  Fri Apr  7 00:53:11 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Apr 2023 00:53:11 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v3]
In-Reply-To: <ND2ouYVXCdcrOqV_Qzo2xyTDdh-hHEEx5-dXZrAHd1c=.ee217506-4f7f-4964-9010-2cb068fd1eca@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
 <ND2ouYVXCdcrOqV_Qzo2xyTDdh-hHEEx5-dXZrAHd1c=.ee217506-4f7f-4964-9010-2cb068fd1eca@github.com>
Message-ID: <nfbFBSqHA9Ej4lFvVzE4Sr7XkhxdSn0pDqcwqfvtPvY=.01169300-545e-4125-af3e-b34326742213@github.com>

On Thu, 30 Mar 2023 04:03:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extend ci model to capture synthetic multi-fields, these are used for scalarization if target does not support load/store bundle size.
>
> src/hotspot/share/opto/inlinetypenode.cpp line 497:
> 
>> 495:       assert(is_java_primitive(bt) || adr->bottom_type()->is_ptr_to_narrowoop() == UseCompressedOops, "inconsistent");
>> 496:       if (value->bottom_type()->isa_vect()) {
>> 497:         Node* store = kit->gvn().transform(StoreVectorNode::make(0, kit->control(), kit->memory(adr), adr, adr_type, value, vec_len));
> 
> Does it need to check the Op_StoreVector supported or not here?

Checks are done at the time of inline type IR creation. 

> Thanks for the updating! So the correspond `expand_vunbox_node` can also be implemented by calling `InlineTypeNode::make_from_oop` ?

You are correct, every time C2 see a value/primitive instance it does create an InlineTypeNode IR by loading each fields from oop using make_from_oop, thus vector inline expanders should always receive a InlineType node.

![image](https://user-images.githubusercontent.com/59989778/230518631-279a76a4-0cc3-41ca-ba03-f9e8d04c975b.png)

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160358295

From xgong at openjdk.org  Fri Apr  7 02:27:09 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 7 Apr 2023 02:27:09 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v6]
In-Reply-To: <nN7mlQXkSo5R63Zk6FOGbAb5jmqSefDRevOi46EnPCo=.662340b0-33ac-4286-b7aa-1dc9cd01e9be@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <BGPveSkACVXdmJU_wYCB2OaO9cKEJ8-U_Kzs1GtLmNE=.0a489d1c-2d17-40a9-8bb6-55aed8b96cb9@github.com>
 <nN7mlQXkSo5R63Zk6FOGbAb5jmqSefDRevOi46EnPCo=.662340b0-33ac-4286-b7aa-1dc9cd01e9be@github.com>
Message-ID: <-NQczPxxNaXgEtKLdJSGtWCZLbWTfAFCF4gFDJqjHm4=.f6b42dfb-2d6c-4437-a8ff-6f51101e9f96@github.com>

On Fri, 7 Apr 2023 00:39:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vector.cpp line 520:
>> 
>>> 518: 
>>> 519:     int elem_size = type2aelembytes(bt);
>>> 520:     Node* vec_val_load = get_loaded_payload(vec_unbox);
>> 
>> We could also optimize the VectorUnbox to the vector node with `VectorUnbox::Identity()`. So `get_loaded_payload()` is needless?
>
>> Thanks for the updating! So the correspond `expand_vunbox_node` can also be implemented by calling `InlineTypeNode::make_from_oop` ?
> 
> Yes, every time C2 sees an value instance it does create an InlineTypeNode IR by loading the appropriate fields from object using InlineTypeNode::make_from_oop,
> 
>> Hi @jatin-bhateja ,
>> 
>> I ran an unit test on a ARM NEON system, and the jvm crashes with following log:
>> 
>> ```
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/loopnode.cpp:5871), pid=544741, tid=544757
>> #  assert(false) failed: Bad graph detected in build_loop_late
>> #
>> # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-558fb2e03)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-558fb2e03, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>> # Problematic frame:
>> # V  [libjvm.so+0x13b395c]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x18c
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /mnt/local/code/test/vector_api/aarch64/armie/core.544741)
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> ```
>> 
>> And here is the call stack:
>> 
>> ```
>> ---------------  T H R E A D  ---------------
>> 
>> Current thread (0x0000fffe0008dc80):  JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=544757, stack(0x0000fffe24d00000,0x0000fffe24f00000)]
>> 
>> 
>> Current CompileTask:
>> C2:    377  172             jdk.incubator.vector.IntVector::fromArray0Template (39 bytes)
>> 
>> Stack: [0x0000fffe24d00000,0x0000fffe24f00000],  sp=0x0000fffe24ef9920,  free space=2022k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x13b395c]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x18c  (loopnode.cpp:5871)
>> V  [libjvm.so+0x13b4194]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xd4  (loopnode.cpp:5775)
>> V  [libjvm.so+0x13b4aa4]  PhaseIdealLoop::build_and_optimize()+0x4d0  (loopnode.cpp:4403)
>> V  [libjvm.so+0xa30f28]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x1e8  (loopnode.hpp:1086)
>> V  [libjvm.so+0xa2be08]  Compile::Optimize()+0x428  (compile.cpp:2828)
>> V  [libjvm.so+0xa2f10c]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x11ec  (compile.cpp:842)
>> V  [libjvm.so+0x829cd4]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x3f0  (c2compiler.cpp:113)
>> V  [libjvm.so+0xa3c410]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbb0  (compileBroker.cpp:2237)
>> V  [libjvm.so+0xa3cd44]  CompileBroker::compiler_thread_loop()+0x3f4  (compileBroker.cpp:1916)
>> V  [libjvm.so+0xf92068]  JavaThread::thread_main_inner()+0x2f4  (javaThread.cpp:710)
>> V  [libjvm.so+0x1a3afb8]  Thread::call_run()+0xf8  (thread.cpp:224)
>> V  [libjvm.so+0x15f6814]  thread_native_entry(Thread*)+0x100  (os_linux.cpp:739)
>> C  [libc.so.6+0x7d5c8]
>> ```
>> 
>> The unit test is:
>> 
>> ```
>> static VectorSpecies<Integer> I_SPECIES = IntVector.SPECIES_PREFERRED;
>> 
>> for (int i = 0; i < LENGTH; i += vl) {
>>             var av = IntVector.fromArray(I_SPECIES, ia, i);
>>             var bv = IntVector.fromArray(I_SPECIES, ib, i);
>>             av.lanewise(VectorOperators.ADD, bv).intoArray(ic, i);
>> }
>> ```
>> 
>> And I cannot reproduce the same issue on a X86 AVX-512 machine. But from the log, it seems not an AArch64 backend issue. So do you have any idea or met this issue before?
>> 
>> BTW, is it possible to split this big patch into two parts: 1) multi-field vectorization part 2) hotspot compiler support for vector intrinsification part. This patch is too big which covers several compiler/runtime support parts. It's not so easy to analysis the issue to me once it happens. And I also tried to separate it by myself. But unfortunately, I also met another JVM crash issue which may related to the register allocation to vector registers on AArch64 when testing the "multi-fields" vectorization changes. I'm not sure whether I have missed something when doing the separation. But it will be helpful to look at the issue with your help. Thanks a lot!
>> 
>> Best Regards, Xiaohong
> 
> Fixed.

Tests on ARM NEON passed with the new fix. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160388746

From xgong at openjdk.org  Fri Apr  7 02:32:12 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 7 Apr 2023 02:32:12 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v6]
In-Reply-To: <GOxWMj8GnUAFZ9CuDekmOEq2-fa3GqMjjbFgr2zaCsg=.5abdf835-3263-4869-b156-220031304973@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <utLv6UOKf5UPv8kgkwjmO1pk1xkQg4wCW2DQP43-uQ8=.228584ed-0328-4c2b-886c-7a8c2aad3407@github.com>
 <rGkJDs-gULgPWzj82dy9vssTNjulizUg8uWoZvt7cg8=.64449792-5e5e-42da-9713-9167b4cff3bc@github.com>
 <Oy421JGZIXUSyP15tcCLAYlSR46bPaSAhL5B-QrwTOc=.b9ba5c8b-2760-4ddc-93db-a63cbc40e46d@github.com>
 <GOxWMj8GnUAFZ9CuDekmOEq2-fa3GqMjjbFgr2zaCsg=.5abdf835-3263-4869-b156-220031304973@github.com>
Message-ID: <leMf1rM2Ivgad8za4g4hZ6Q1spdi4XOv3Pquh92_pHs=.2429a8dd-0954-41c4-b48a-89f8eda3db0a@github.com>

On Fri, 7 Apr 2023 00:30:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> BTW, methods like `is_multifield, is_multifield_base` can be removed. `secondary_fields_count() > 1` can be used as a replacement to `is_multifield_base()`, right?
>
>> BTW, methods like `is_multifield, is_multifield_base` can be removed. `secondary_fields_count() > 1` can be used as a replacement to `is_multifield_base()`, right?
> 
> It should add value to still keep is_multifield and is_multifield_base since it allows skipping over synthetic fields (non-base) at places.

I'm sorry that I don't understand quite well. At least, `is_multifield()` is not used now. So I guess it can be removed?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160390363

From xgong at openjdk.org  Mon Apr 10 08:03:11 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 10 Apr 2023 08:03:11 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <V01Ttrs4tqmBgxXqsA225G2mdHhkTDMCEa7CNPnhH1c=.5159bc8a-bf63-4562-8fc6-0785e44e23d7@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
 <V01Ttrs4tqmBgxXqsA225G2mdHhkTDMCEa7CNPnhH1c=.5159bc8a-bf63-4562-8fc6-0785e44e23d7@github.com>
Message-ID: <8Z10tn_bgDN9XXlW2Bs_1DY8TQJKm0v3RrkV9t5bXLI=.687951e0-463d-442a-afba-4287f319d849@github.com>

On Mon, 10 Apr 2023 07:59:21 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup vector box expansion handling to leverage existing InlineTypeNode storage and flow merging routines.
>
> src/hotspot/share/opto/vectornode.hpp line 1689:
> 
>> 1687:     payload_value->as_InlineType()->set_field_value(0, val);
>> 1688:     payload_value = gvn.transform(payload_value);
>> 1689:     VectorBoxNode* box_node = new VectorBoxNode(vk, box, false, vk->is_empty() && vk->is_initialized());
> 
> I think we have to keep the `val` as the input of the new `VectorBoxNode`, and moving the payload creating code to the `expand_vbox_node` as before.  `VectorBoxNode` is a macro node for a vector. So it's more reasonable it only contains the vbox and vec parts. The payload creating should belong to the extension stage like before. Besides, some transformation applied to `PhiNode` may expect one of the input of  `VectorBoxNode` is a vector type?
> 
> I met a jvm crash issue with following test case on ARM NEON system:
> 
>  var av = IntVector.fromArray(I_SPECIES, ia, 0);
>  for (int i = 0; i < LENGTH; i += vl) {
>        var bv = IntVector.fromArray(I_SPECIES, ib, i);
>        av = av.and(bv);
>  }
>  av.intoArray(ic, 0);
> 
> The log shows it crashes when the type is not mismatch at a `PhiNode`.  One is `TypeVectX`, and another is `TypePtr`. I didn't dig into the `cfgnode.cpp` to see what is wrong. But as a try, I moved this code to the expanding stage, the issue is gone.

Here is the changes in `vector.cpp`:

diff --git a/src/hotspot/share/opto/vector.cpp b/src/hotspot/share/opto/vector.cpp
index d7329e72c..524791ea8 100644
--- a/src/hotspot/share/opto/vector.cpp
+++ b/src/hotspot/share/opto/vector.cpp
@@ -322,9 +322,18 @@ void PhaseVector::expand_vbox_node(VectorBoxNode* vec_box) {
     GraphKit kit(jvms);

     ciInlineKlass* vk = vec_box->inline_klass();
+    ciInlineKlass* payload = vk->declared_nonstatic_field_at(0)->type()->as_inline_klass();
+    Node* payload_value = InlineTypeNode::make_uninitialized(kit.gvn(), payload, true);
+    payload_value->as_InlineType()->set_field_value(0, vec_box->get_vec());
+    payload_value = kit.gvn().transform(payload_value);
+
+    InlineTypeNode* vector = InlineTypeNode::make_uninitialized(kit.gvn(), vk, false);
+    vector->set_field_value(0, payload_value);
+    vector = kit.gvn().transform(vector)->as_InlineType();
+
     Node* klass_node = kit.makecon(TypeKlassPtr::make(vk));
-    Node* alloc_oop  = kit.new_instance(klass_node, NULL, NULL, /* deoptimize_on_exception */ true);
-    vec_box->store(&kit, alloc_oop, alloc_oop, vk);
+    Node* alloc_oop  = kit.new_instance(klass_node, NULL, NULL, /* deoptimize_on_exception */ true, vector);
+    vector->store(&kit, alloc_oop, alloc_oop, vk);

     // Do not let stores that initialize this buffer be reordered with a subsequent
     // store that would make this buffer accessible by other threads.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1161523573

From xgong at openjdk.org  Mon Apr 10 08:03:11 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 10 Apr 2023 08:03:11 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
Message-ID: <V01Ttrs4tqmBgxXqsA225G2mdHhkTDMCEa7CNPnhH1c=.5159bc8a-bf63-4562-8fc6-0785e44e23d7@github.com>

On Thu, 6 Apr 2023 08:58:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup vector box expansion handling to leverage existing InlineTypeNode storage and flow merging routines.

src/hotspot/share/opto/vectornode.hpp line 1689:

> 1687:     payload_value->as_InlineType()->set_field_value(0, val);
> 1688:     payload_value = gvn.transform(payload_value);
> 1689:     VectorBoxNode* box_node = new VectorBoxNode(vk, box, false, vk->is_empty() && vk->is_initialized());

I think we have to keep the `val` as the input of the new `VectorBoxNode`, and moving the payload creating code to the `expand_vbox_node` as before.  `VectorBoxNode` is a macro node for a vector. So it's more reasonable it only contains the vbox and vec parts. The payload creating should belong to the extension stage like before. Besides, some transformation applied to `PhiNode` may expect one of the input of  `VectorBoxNode` is a vector type?

I met a jvm crash issue with following test case on ARM NEON system:

 var av = IntVector.fromArray(I_SPECIES, ia, 0);
 for (int i = 0; i < LENGTH; i += vl) {
       var bv = IntVector.fromArray(I_SPECIES, ib, i);
       av = av.and(bv);
 }
 av.intoArray(ic, 0);

The log shows it crashes when the type is not mismatch at a `PhiNode`.  One is `TypeVectX`, and another is `TypePtr`. I didn't dig into the `cfgnode.cpp` to see what is wrong. But as a try, I moved this code to the expanding stage, the issue is gone.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1161522886

From xgong at openjdk.org  Mon Apr 10 08:11:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 10 Apr 2023 08:11:15 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
Message-ID: <m2foG7aUB10-A8ZLYq9Cx_czMKeR9tw_TsbVeUsXg_E=.59250a30-eee3-4826-9f13-da91479a1a53@github.com>

On Thu, 6 Apr 2023 08:58:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup vector box expansion handling to leverage existing InlineTypeNode storage and flow merging routines.

src/hotspot/share/opto/vector.cpp line 318:

> 316:   if (vec_box->outcnt() > 0) {
> 317:     Node* vbox_alloc = vec_box->get_oop();
> 318:     assert(vbox_alloc->is_Proj() && vbox_alloc->in(0)->isa_VectorBoxAllocate(), "");

Before we have the `PhiNode` as the oop and vect inputs, which are from the transformations like `merge_through_phi`, but now the oop is only the VBA?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1161526611

From xgong at openjdk.org  Mon Apr 10 08:42:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 10 Apr 2023 08:42:15 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v6]
In-Reply-To: <JRpDpClF_izwVLEyQI90YUR298WfnDv2gJYpPuuiODQ=.9348c8f7-cc71-43e9-8bae-f2960f4919cc@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <JRpDpClF_izwVLEyQI90YUR298WfnDv2gJYpPuuiODQ=.9348c8f7-cc71-43e9-8bae-f2960f4919cc@github.com>
Message-ID: <eBJeoq241NB97siESc9uCwhuKD6RvpXSMjXVYITzXB4=.81fddfbf-bfca-4191-b217-77311fae3ac5@github.com>

On Fri, 7 Apr 2023 00:44:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/share/prims/vectorSupport.cpp line 345:

> 343:     if (location.type() == Location::vector) {
> 344:       // Vector payload value in an aligned adjacent tuple (8, 16, 32 or 64 bytes).
> 345:       return allocate_vector_payload_helper(ik, num_elem, T_BYTE, fr, reg_map, location, THREAD); // safepoint

Should `T_BYTE` be `elem_bt` instead?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1161545209

From anhmdq at gmail.com  Mon Apr 10 09:28:49 2023
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Mon, 10 Apr 2023 17:28:49 +0800
Subject: Trying to understand atomicity from the new
 valhalla-spec-observers post
In-Reply-To: <CAA9v-_PCa+8m7XHVnh8tBOxEuPf1GjgZS-ocQ661hB5Jig8nDA@mail.gmail.com>
References: <CAA9v-_PCa+8m7XHVnh8tBOxEuPf1GjgZS-ocQ661hB5Jig8nDA@mail.gmail.com>
Message-ID: <CAPvyiyK0JmZcaXSBEfUmTxN6QqFpYk3XGTA5AJByKyYb-em2gA@mail.gmail.com>

Hi,

Atomicity is the behaviours of memory reads/writes under race conditions.
If there is no race condition (the variable is not accessed from multiple
threads or protected properly by locks) then the observed value is always
the latest written one. As a result, if you serialise your accesses
properly, there is no need to worry about atomicity. And in general, it
should be rare that you want to access variables without proper
synchronisations, and you should not do so.

As this is rather uncommon and requires you doing clever things for it to
make differences. Other languages often do not worry giving up this
property. C and C++ straight invalidate your entire program, Go and C# give
you unspecified result when accessing variables larger than machine word.

In conclusion, you will most likely not observe the non-atomicity of any
variable, except when you are trying to do clever things (accessing
variables racily) and in those cases, you need to carefully study the Java
memory model.

To quote from the Go memory model: Don't be clever.

Best regards,
Quan Anh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230410/a7f3d700/attachment-0001.htm>

From davidalayachew at gmail.com  Mon Apr 10 10:11:18 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Apr 2023 06:11:18 -0400
Subject: Trying to understand atomicity from the new
 valhalla-spec-observers post
In-Reply-To: <CAPvyiyK0JmZcaXSBEfUmTxN6QqFpYk3XGTA5AJByKyYb-em2gA@mail.gmail.com>
References: <CAA9v-_PCa+8m7XHVnh8tBOxEuPf1GjgZS-ocQ661hB5Jig8nDA@mail.gmail.com>
 <CAPvyiyK0JmZcaXSBEfUmTxN6QqFpYk3XGTA5AJByKyYb-em2gA@mail.gmail.com>
Message-ID: <CAA9v-_MX-si9zuKR-8D85JdvQ7s0G-PmyoKt=vxd9uh5PdP1Ow@mail.gmail.com>

Hello Quan Anh,

Thank you for your response!

> Hi,
>
> Atomicity is the behaviours of memory reads/writes under
> race conditions. If there is no race condition (the
> variable is not accessed from multiple threads or
> protected properly by locks) then the observed value is
> always the latest written one. As a result, if you
> serialise your accesses properly, there is no need to
> worry about atomicity. And in general, it should be rare
> that you want to access variables without proper
> synchronisations, and you should not do so.

Beautiful. That spelled it out perfectly for me.

Something like object tearing sounds scary and unpredictable, but knowing
that it can ONLY occur when dealing with multiple threads accessing the
same field makes me much more comfortable. That means that this is nothing
more than a race condition with a much bigger punishment if you get it
wrong. Beautiful, ty vm.

> As this is rather uncommon and requires you doing clever
> things for it to make differences. Other languages often
> do not worry giving up this property. C and C++ straight
> invalidate your entire program, Go and C# give you
> unspecified result when accessing variables larger than
> machine word.
>
> In conclusion, you will most likely not observe the
> non-atomicity of any variable, except when you are trying
> to do clever things (accessing variables racily) and in
> those cases, you need to carefully study the Java memory
> model.
>
> To quote from the Go memory model: Don't be clever.

I can definitely see what you mean. At this point, I have no desire at all
to ever let any of my tearable objects ever leave the boundaries of my
synchronization tools.

Let me ask this though. If I apply synchronization or some other concurrent
access tool to my tearable object, do I still get to keep all of the large
object inlining that I made it tearable for in the first place? If so, then
that leads me to want to dive into the concurrency model so that I can
safely get the performance I want.

Thank you for the insight and clarification!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230410/b2cce0f0/attachment.htm>

From jbhateja at openjdk.org  Mon Apr 10 16:58:16 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 10 Apr 2023 16:58:16 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <m2foG7aUB10-A8ZLYq9Cx_czMKeR9tw_TsbVeUsXg_E=.59250a30-eee3-4826-9f13-da91479a1a53@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
 <m2foG7aUB10-A8ZLYq9Cx_czMKeR9tw_TsbVeUsXg_E=.59250a30-eee3-4826-9f13-da91479a1a53@github.com>
Message-ID: <7cSSMwCywEvKXE3hEongxZlXA5JG9g2xEjFObBWJb9k=.32c870b1-056f-4215-8e3c-1380a92d4fb8@github.com>

On Mon, 10 Apr 2023 08:05:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Before we have the `PhiNode` as the oop and vect inputs, which are from the transformations like `merge_through_phi`, but now the oop is only the VBA?

I am banking on InlineTypeNode::merge_with to handle convergence cases instead of introducing special phi handling in box expansion.

https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.hpp#L91

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1161892670

From davidalayachew at gmail.com  Mon Apr 10 17:13:29 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 10 Apr 2023 13:13:29 -0400
Subject: Trying to understand atomicity from the new
 valhalla-spec-observers post
In-Reply-To: <CAPvyiyLrjQFoq6ndLHDgMRydKK7JUv+QkD9Kk+jo_79Uk8=YZg@mail.gmail.com>
References: <CAA9v-_PCa+8m7XHVnh8tBOxEuPf1GjgZS-ocQ661hB5Jig8nDA@mail.gmail.com>
 <CAPvyiyK0JmZcaXSBEfUmTxN6QqFpYk3XGTA5AJByKyYb-em2gA@mail.gmail.com>
 <CAA9v-_MX-si9zuKR-8D85JdvQ7s0G-PmyoKt=vxd9uh5PdP1Ow@mail.gmail.com>
 <CAPvyiyLrjQFoq6ndLHDgMRydKK7JUv+QkD9Kk+jo_79Uk8=YZg@mail.gmail.com>
Message-ID: <CAA9v-_OVBNiXKfSv5OtNR6G1Zei9mphqVjBp5rheteO01t2mQw@mail.gmail.com>

Ok, perfect. This puts all of my concerns to rest. Thank you so much!

On Mon, Apr 10, 2023 at 6:34?AM Qu?n Anh Mai <anhmdq at gmail.com> wrote:

> Yes, the usage of synchronisation mechanisms is not likely to affect the
> layout of the non-atomic object in local variables and in the heap.
>
> On Mon, 10 Apr 2023 at 18:11, David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Hello Quan Anh,
>>
>> Thank you for your response!
>>
>> > Hi,
>> >
>> > Atomicity is the behaviours of memory reads/writes under
>> > race conditions. If there is no race condition (the
>> > variable is not accessed from multiple threads or
>> > protected properly by locks) then the observed value is
>> > always the latest written one. As a result, if you
>> > serialise your accesses properly, there is no need to
>> > worry about atomicity. And in general, it should be rare
>> > that you want to access variables without proper
>> > synchronisations, and you should not do so.
>>
>> Beautiful. That spelled it out perfectly for me.
>>
>> Something like object tearing sounds scary and unpredictable, but knowing
>> that it can ONLY occur when dealing with multiple threads accessing the
>> same field makes me much more comfortable. That means that this is nothing
>> more than a race condition with a much bigger punishment if you get it
>> wrong. Beautiful, ty vm.
>>
>> > As this is rather uncommon and requires you doing clever
>> > things for it to make differences. Other languages often
>> > do not worry giving up this property. C and C++ straight
>> > invalidate your entire program, Go and C# give you
>> > unspecified result when accessing variables larger than
>> > machine word.
>> >
>> > In conclusion, you will most likely not observe the
>> > non-atomicity of any variable, except when you are trying
>> > to do clever things (accessing variables racily) and in
>> > those cases, you need to carefully study the Java memory
>> > model.
>> >
>> > To quote from the Go memory model: Don't be clever.
>>
>> I can definitely see what you mean. At this point, I have no desire at
>> all to ever let any of my tearable objects ever leave the boundaries of my
>> synchronization tools.
>>
>> Let me ask this though. If I apply synchronization or some other
>> concurrent access tool to my tearable object, do I still get to keep all of
>> the large object inlining that I made it tearable for in the first place?
>> If so, then that leads me to want to dive into the concurrency model so
>> that I can safely get the performance I want.
>>
>> Thank you for the insight and clarification!
>>
>> David Alayachew
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230410/981f4208/attachment-0001.htm>

From jbhateja at openjdk.org  Tue Apr 11 00:42:01 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Apr 2023 00:42:01 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <m2foG7aUB10-A8ZLYq9Cx_czMKeR9tw_TsbVeUsXg_E=.59250a30-eee3-4826-9f13-da91479a1a53@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
 <m2foG7aUB10-A8ZLYq9Cx_czMKeR9tw_TsbVeUsXg_E=.59250a30-eee3-4826-9f13-da91479a1a53@github.com>
Message-ID: <VMkoJlrsGsxqzQPmpuslUGtVUVIBYxrhwdRDj5jWt1c=.f8a3fc50-0b88-4b8b-8ef0-22c8e7cf9c8e@github.com>

On Mon, 10 Apr 2023 08:05:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup vector box expansion handling to leverage existing InlineTypeNode storage and flow merging routines.
>
> src/hotspot/share/opto/vector.cpp line 318:
> 
>> 316:   if (vec_box->outcnt() > 0) {
>> 317:     Node* vbox_alloc = vec_box->get_oop();
>> 318:     assert(vbox_alloc->is_Proj() && vbox_alloc->in(0)->isa_VectorBoxAllocate(), "");
> 
> Before we have the `PhiNode` as the oop and vect inputs, which are from the transformations like `merge_through_phi`, but now the oop is only the VBA?

I wanted to get away with VectorBoxAllocateNode (a macro node) in a subsequent patch, I kept it currently because it being a SafePoint node carries JVMState for re-initialization of GraphKit during expansion, this helps in accessing control and memory edges needed during new_instance creation for vector_boxes.

Otherwise, InlineTypeNode handle control flow merges inherently.
https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.hpp#L91

What do you think ?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1162192666

From xgong at openjdk.org  Wed Apr 12 07:08:05 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 12 Apr 2023 07:08:05 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v6]
In-Reply-To: <JRpDpClF_izwVLEyQI90YUR298WfnDv2gJYpPuuiODQ=.9348c8f7-cc71-43e9-8bae-f2960f4919cc@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <JRpDpClF_izwVLEyQI90YUR298WfnDv2gJYpPuuiODQ=.9348c8f7-cc71-43e9-8bae-f2960f4919cc@github.com>
Message-ID: <aZKbq0BvrInvirXD0CPAwBK-4UJ3yUgXiMLR24LCohQ=.ac345124-529c-4844-bc38-14b0be06b0b6@github.com>

On Fri, 7 Apr 2023 00:44:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

Hi Jatin,

I forked your hotspot changes to finish the vector box/unbox expanding, together with several fixing changes to make some more complex test cases work well.  It is worth mentioning that one of the change is to fix a jdk/mainline bug: https://bugs.openjdk.org/browse/JDK-8304948, which my colleague is working on and will push it to jdk/mainline in a few days.

Please see the whole changes here: https://github.com/XiaohongGong/valhalla/pull/4/commits. Hope this could provide any help and promote this PR. Thanks!

Best Regards,
Xiaohong

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/833#issuecomment-1504770846

From jbhateja at openjdk.org  Fri Apr 14 07:03:11 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 14 Apr 2023 07:03:11 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v7]
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <2gO4ioPnyK0ya6aCMBnRL8nWXhmkKJyirJdo1inii4s=.41ad7b82-dbba-40e6-b182-14b500627d3c@github.com>

> Please find below the summary of changes included with the patch:
>   
> a) _ci Model:_
>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
> 
> b) _C1 compiler:_
>    Special handling to copy entire multifield bundle during withfield bytecode processing.
> 
> c) _C2 compiler:_
>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
> 
> d) _Runtime:_
>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
> 
> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
> 
> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
> 
> More information can be found at following link
> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
> 
> Please share your feedback and suggestions.
> 
> Best Regards,
> Jatin

Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:

 - Extend box forwarding transformation across Phi nodes.
 - Code refactoring around vector boxing/unboxing.
 - Review comments resolutions.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/c1bb7fd5..b5dd30a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=06
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=05-06

  Stats: 322 lines in 8 files changed: 250 ins; 26 del; 46 mod
  Patch: https://git.openjdk.org/valhalla/pull/833.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833

PR: https://git.openjdk.org/valhalla/pull/833

From jbhateja at openjdk.org  Fri Apr 14 07:17:03 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 14 Apr 2023 07:17:03 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v5]
In-Reply-To: <VMkoJlrsGsxqzQPmpuslUGtVUVIBYxrhwdRDj5jWt1c=.f8a3fc50-0b88-4b8b-8ef0-22c8e7cf9c8e@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <oiS1aKxxZ7hokV6fos6Ack50MrlxJ1UsghJMl7pAQ3Y=.1768f3a3-6f6c-4fb8-999b-0e471f8e8692@github.com>
 <m2foG7aUB10-A8ZLYq9Cx_czMKeR9tw_TsbVeUsXg_E=.59250a30-eee3-4826-9f13-da91479a1a53@github.com>
 <VMkoJlrsGsxqzQPmpuslUGtVUVIBYxrhwdRDj5jWt1c=.f8a3fc50-0b88-4b8b-8ef0-22c8e7cf9c8e@github.com>
Message-ID: <3CWp0FiHkA-uE2rVLQoy4Ozq0MwMuKKj2U3PfkajiY8=.65cb4455-0f1b-4f79-89a0-cae0d9346a85@github.com>

On Tue, 11 Apr 2023 00:39:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vector.cpp line 318:
>> 
>>> 316:   if (vec_box->outcnt() > 0) {
>>> 317:     Node* vbox_alloc = vec_box->get_oop();
>>> 318:     assert(vbox_alloc->is_Proj() && vbox_alloc->in(0)->isa_VectorBoxAllocate(), "");
>> 
>> Before we have the `PhiNode` as the oop and vect inputs, which are from the transformations like `merge_through_phi`, but now the oop is only the VBA?
>
> I wanted to get away with VectorBoxAllocateNode (a macro node) in a subsequent patch, I kept it currently because it being a SafePoint node carries JVMState for re-initialization of GraphKit during expansion, this helps in accessing control and memory edges needed during new_instance creation for vector_boxes.
> 
> Otherwise, InlineTypeNode handle control flow merges inherently.
> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.hpp#L91
> 
> But since JVMState of merging control flow will be different hence we will need to create a different allocation in each incoming control flow as was done previously.

**Issue around early VectorBoxAllocate expansions: -**

 
![image](https://user-images.githubusercontent.com/59989778/231967490-e0c699b7-d9c1-4998-916e-67fcfce543c1.png)


_Q. Why do we need an explicit  VectorBoxAllocate IR along with VectorBox?_

_A. This is because we need memory and control edges to stitch the graph pallet created after buffering, VectorBoxAllocate is a Safepoint node carrying JVMstate and other relevant edges thus re-initializing GraphKit corresponding to a given JVM state is seamless._ 

_Other possible solution could be to associate memory and control edges with VectorBox nodes OR bookkeep entire JVMState into VectorBox for a later use, but this will pose issues at convergence points where VectorBoxes coming from different control flow merge and so does current  VBAs and this is augmented by PhaseVector::expand_vbox_node_helper which processes each incoming VectorBoxAllocate separately._

_If we just preserve JVMState for a VectorBox then we need to have a synthetic IR for bookkeeping it since box forwarding across PhiNode result into creation of just one VectorBox at converge point, so keeping VBA looks relevant and clean solution for the time being._

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1166386677

From thartmann at openjdk.org  Tue Apr 18 11:22:25 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Apr 2023 11:22:25 GMT
Subject: [lworld] RFR: 8301007: [lworld] Handle mismatches of the preload
 attribute in the calling convention
Message-ID: <JOcxjxPwX23hZ16i8c8ydNhwnO6HPW1c4C4JuiV7Ufk=.cfbac6de-42ed-47f0-bead-6070938108ec@github.com>

[Don't be afraid by the ~4,700 LOC, it's mostly tests ?]

C2 passes value class arguments in scalarized form if the calling convention of the resolved method supports this. This requires that the calling conventions of all overriding methods need to agree on which arguments are passed in scalarized form. Since the preload attribute added with [JDK-8281116](https://bugs.openjdk.org/browse/JDK-8281116) does not guarantee any consistency between the overridden and overriding method, we need to handle mismatches at runtime. The same applies to returning value classes in scalarized form.

[JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) discusses several options for handling mismatches. Unfortunately, they are either very complex to implement (mismatch detection in the callee leading to deoptimization and re-execution in the caller) and/or have a significant impact on performance/footprint (global dictionary), sometimes even affecting methods not participating in the mismatch.

After several iterations of thinking and prototyping, I came up with the following solution.

**Scalarized calls:**
The calling convention is determined per method at link time. Mismatches can always be detected at that point by walking up the chain of overridden methods and checking if their calling conventions match for each argument with what we would like to set up for the to-be-linked method. In most of the cases, we can handle a mismatch by simply sticking to the calling convention that the super method uses. I.e., if the super method uses a non-scalarized calling convention because the argument was not yet loaded at link time due to a missing preload attribute, we don't scalarize that argument of the overriding method(s) either. In fact, a fallback to the non-scalarized calling convention is always sufficient because it can't happen that the argument type was loaded when the super method was linked and is not loaded now that an overriding method is linked.

However, this does not work in the following case of multiple inheritance where `MyValue` was not yet loaded when `I1::m` was linked but was loaded when `I2::m` was linked. Since the interfaces are completely independent, we scalarize the argument for `I2::m` but not for `I1::m`:


interface I1 {
  void m(LMyValue arg); // Non-scalarized due to missing preload attribute
}

interface I2 {
  void m(LMyValue arg); // Scalarized due to preload attribute
}

class C implements I1, I2 {
  void m(LMyValue arg) { }
}


Now once `C::m` is linked, we can't simply fall back to the non-scalarized calling convention because the method can still be called with a scalarized calling convention through `I2::m`. We mark such "offending" methods, in this case only `I2::m`, in the overriding chain as mismatched, deoptimize all C2 compiled methods that include a scalarized call via that method and re-compile them by using the non-scalarized calling convention. To do that, we register an evol dependency when compiling a scalarized call site (via `C->dependencies()->assert_evol_method(call->method())`) and deoptimize all dependent nmethods via `CodeCache::flush_dependents_on_method` after mismatch detection.

**Scalarized returns:**
Due to the lack of adapters on returns, value objects are always (from interpreter, C1 and C2) returned in scalarized form if the return type is a value class. Similar to scalarized calls, an issue occurs when overridden and overriding methods do not agree if the return value should be passed in scalarized form. For example, we might compile a call to a method with an unloaded return type. Later, the return type is loaded and the method (or an overriding method) returns a value in scalarized form that the previously compiled caller can't handle.

Since the interpreter always checks if a to-be-returned value or a value returned from a call is in scalarized form, we only need additional handling in C1 and C2. For C2, we replace the null assert, that is added after a call site with an unloaded return type, by a full-blown trap. This should have minimal impact and will be further improved (see remaining work section below). For C1, we need additional checks when returning an unloaded type and after invoking a method with an unloaded type. In both cases, the overhead is negligible because it boils down to a bit-check on a register to determine if we need to go to the slow path to handle a scalarized return.

**Other changes:**
- Lots of tests relying on jasm to introduce preload attribute mismatches.
- Extended the `StressCallingConvention` flag to stress test new code paths.
- Some refactoring/cleanup of related code.

Since this change became quite large, I'm postponing the following remaining work to [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443):
- A static call to a mismatched method should still be scalarized, we currently fall back to the non-scalarized calling convention even for static calls.
- If C2 compiles a call with an unloaded return type, a trap is added. We can do better here by adding a null assert and handling scalarized returns similar to the `PhaseMacroExpand::expand_mh_intrinsic_return` logic.
- Enable `StressCallingConvention` in `InterpreterMacroAssembler::remove_activation`, this still triggers some issues.
- The calling convention should only be computed once, it's currently re-computed during C1 compilation.

Thanks,
Tobias

-------------

Commit messages:
 - Skipping package private methods. Disabled stress options for interpreter returns for now
 - AArch64 stress flag fix
 - Test fixes
 - Support for default methods + test. Fix to stress option
 - Small cleanup
 - Improved test comment
 - More tests, more issues, more fixes. I'm happy with the design :)
 - More fixes
 - Removed trailing whitespace
 - First prototype

Changes: https://git.openjdk.org/valhalla/pull/834/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=834&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301007
  Stats: 4751 lines in 30 files changed: 4626 ins; 13 del; 112 mod
  Patch: https://git.openjdk.org/valhalla/pull/834.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/834/head:pull/834

PR: https://git.openjdk.org/valhalla/pull/834

From dsimms at openjdk.org  Tue Apr 18 12:31:07 2023
From: dsimms at openjdk.org (David Simms)
Date: Tue, 18 Apr 2023 12:31:07 GMT
Subject: [lworld] RFR: 8301007: [lworld] Handle mismatches of the preload
 attribute in the calling convention
In-Reply-To: <JOcxjxPwX23hZ16i8c8ydNhwnO6HPW1c4C4JuiV7Ufk=.cfbac6de-42ed-47f0-bead-6070938108ec@github.com>
References: <JOcxjxPwX23hZ16i8c8ydNhwnO6HPW1c4C4JuiV7Ufk=.cfbac6de-42ed-47f0-bead-6070938108ec@github.com>
Message-ID: <7W3N2HE_6MVqBN9y73sG7z0OBbyyIzTvNednG0ntTYo=.bbf413a8-eab9-406e-b669-f134acda76ab@github.com>

On Tue, 18 Apr 2023 11:12:13 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [Don't be afraid by the ~4,700 LOC, it's mostly tests ?]
> 
> C2 passes value class arguments in scalarized form if the calling convention of the resolved method supports this. This requires that the calling conventions of all overriding methods need to agree on which arguments are passed in scalarized form. Since the preload attribute added with [JDK-8281116](https://bugs.openjdk.org/browse/JDK-8281116) does not guarantee any consistency between the overridden and overriding method, we need to handle mismatches at runtime. The same applies to returning value classes in scalarized form.
> 
> [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) discusses several options for handling mismatches. Unfortunately, they are either very complex to implement (mismatch detection in the callee leading to deoptimization and re-execution in the caller) and/or have a significant impact on performance/footprint (global dictionary), sometimes even affecting methods not participating in the mismatch.
> 
> After several iterations of thinking and prototyping, I came up with the following solution.
> 
> **Scalarized calls:**
> The calling convention is determined per method at link time. Mismatches can always be detected at that point by walking up the chain of overridden methods and checking if their calling conventions match for each argument with what we would like to set up for the to-be-linked method. In most of the cases, we can handle a mismatch by simply sticking to the calling convention that the super method uses. I.e., if the super method uses a non-scalarized calling convention because the argument was not yet loaded at link time due to a missing preload attribute, we don't scalarize that argument of the overriding method(s) either. In fact, a fallback to the non-scalarized calling convention is always sufficient because it can't happen that the argument type was loaded when the super method was linked and is not loaded now that an overriding method is linked.
> 
> However, this does not work in the following case of multiple inheritance where `MyValue` was not yet loaded when `I1::m` was linked but was loaded when `I2::m` was linked. Since the interfaces are completely independent, we scalarize the argument for `I2::m` but not for `I1::m`:
> 
> 
> interface I1 {
>   void m(LMyValue arg); // Non-scalarized due to missing preload attribute
> }
> 
> interface I2 {
>   void m(LMyValue arg); // Scalarized due to preload attribute
> }
> 
> class C implements I1, I2 {
>   void m(LMyValue arg) { }
> }
> 
> 
> Now once `C::m` is linked, we can't simply fall back to the non-scalarized calling convention because the method can still be called with a scalarized calling convention through `I2::m`. We mark such "offending" methods, in this case only `I2::m`, in the overriding chain as mismatched, deoptimize all C2 compiled methods that include a scalarized call via that method and re-compile them by using the non-scalarized calling convention. To do that, we register an evol dependency when compiling a scalarized call site (via `C->dependencies()->assert_evol_method(call->method())`) and deoptimize all dependent nmethods via `CodeCache::flush_dependents_on_method` after mismatch detection.
> 
> **Scalarized returns:**
> Due to the lack of adapters on returns, value objects are always (from interpreter, C1 and C2) returned in scalarized form if the return type is a value class. Similar to scalarized calls, an issue occurs when overridden and overriding methods do not agree if the return value should be passed in scalarized form. For example, we might compile a call to a method with an unloaded return type. Later, the return type is loaded and the method (or an overriding method) returns a value in scalarized form that the previously compiled caller can't handle.
> 
> Since the interpreter always checks if a to-be-returned value or a value returned from a call is in scalarized form, we only need additional handling in C1 and C2. For C2, we replace the null assert, that is added after a call site with an unloaded return type, by a full-blown trap. This should have minimal impact and will be further improved (see remaining work section below). For C1, we need additional checks when returning an unloaded type and after invoking a method with an unloaded type. In both cases, the overhead is negligible because it boils down to a bit-check on a register to determine if we need to go to the slow path to handle a scalarized return.
> 
> **Other changes:**
> - Lots of tests relying on jasm to introduce preload attribute mismatches.
> - Extended the `StressCallingConvention` flag to stress test new code paths.
> - Some refactoring/cleanup of related code.
> 
> Since this change became quite large, I'm postponing the following remaining work to [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443):
> - A static call to a mismatched method should still be scalarized, we currently fall back to the non-scalarized calling convention even for static calls.
> - If C2 compiles a call with an unloaded return type, a trap is added. We can do better here by adding a null assert and handling scalarized returns similar to the `PhaseMacroExpand::expand_mh_intrinsic_return` logic.
> - Enable `StressCallingConvention` in `InterpreterMacroAssembler::remove_activation`, this still triggers some issues.
> - The calling convention should only be computed once, it's currently re-computed during C1 compilation.
> 
> Thanks,
> Tobias

Runtime bits look good, thanks for the cleanups along the way

-------------

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/834#pullrequestreview-1390002683

From thartmann at openjdk.org  Tue Apr 18 12:54:20 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Apr 2023 12:54:20 GMT
Subject: [lworld] RFR: 8301007: [lworld] Handle mismatches of the preload
 attribute in the calling convention
In-Reply-To: <7W3N2HE_6MVqBN9y73sG7z0OBbyyIzTvNednG0ntTYo=.bbf413a8-eab9-406e-b669-f134acda76ab@github.com>
References: <JOcxjxPwX23hZ16i8c8ydNhwnO6HPW1c4C4JuiV7Ufk=.cfbac6de-42ed-47f0-bead-6070938108ec@github.com>
 <7W3N2HE_6MVqBN9y73sG7z0OBbyyIzTvNednG0ntTYo=.bbf413a8-eab9-406e-b669-f134acda76ab@github.com>
Message-ID: <zuR30JDxOmrqQkgaZTGqGenN-MVMehzh7JvY70gnm6g=.11788859-ab72-497e-8270-fc7d232093fa@github.com>

On Tue, 18 Apr 2023 12:28:12 GMT, David Simms <dsimms at openjdk.org> wrote:

>> [Don't be afraid by the ~4,700 LOC, it's mostly tests ?]
>> 
>> C2 passes value class arguments in scalarized form if the calling convention of the resolved method supports this. This requires that the calling conventions of all overriding methods need to agree on which arguments are passed in scalarized form. Since the preload attribute added with [JDK-8281116](https://bugs.openjdk.org/browse/JDK-8281116) does not guarantee any consistency between the overridden and overriding method, we need to handle mismatches at runtime. The same applies to returning value classes in scalarized form.
>> 
>> [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) discusses several options for handling mismatches. Unfortunately, they are either very complex to implement (mismatch detection in the callee leading to deoptimization and re-execution in the caller) and/or have a significant impact on performance/footprint (global dictionary), sometimes even affecting methods not participating in the mismatch.
>> 
>> After several iterations of thinking and prototyping, I came up with the following solution.
>> 
>> **Scalarized calls:**
>> The calling convention is determined per method at link time. Mismatches can always be detected at that point by walking up the chain of overridden methods and checking if their calling conventions match for each argument with what we would like to set up for the to-be-linked method. In most of the cases, we can handle a mismatch by simply sticking to the calling convention that the super method uses. I.e., if the super method uses a non-scalarized calling convention because the argument was not yet loaded at link time due to a missing preload attribute, we don't scalarize that argument of the overriding method(s) either. In fact, a fallback to the non-scalarized calling convention is always sufficient because it can't happen that the argument type was loaded when the super method was linked and is not loaded now that an overriding method is linked.
>> 
>> However, this does not work in the following case of multiple inheritance where `MyValue` was not yet loaded when `I1::m` was linked but was loaded when `I2::m` was linked. Since the interfaces are completely independent, we scalarize the argument for `I2::m` but not for `I1::m`:
>> 
>> 
>> interface I1 {
>>   void m(LMyValue arg); // Non-scalarized due to missing preload attribute
>> }
>> 
>> interface I2 {
>>   void m(LMyValue arg); // Scalarized due to preload attribute
>> }
>> 
>> class C implements I1, I2 {
>>   void m(LMyValue arg) { }
>> }
>> 
>> 
>> Now once `C::m` is linked, we can't simply fall back to the non-scalarized calling convention because the method can still be called with a scalarized calling convention through `I2::m`. We mark such "offending" methods, in this case only `I2::m`, in the overriding chain as mismatched, deoptimize all C2 compiled methods that include a scalarized call via that method and re-compile them by using the non-scalarized calling convention. To do that, we register an evol dependency when compiling a scalarized call site (via `C->dependencies()->assert_evol_method(call->method())`) and deoptimize all dependent nmethods via `CodeCache::flush_dependents_on_method` after mismatch detection.
>> 
>> **Scalarized returns:**
>> Due to the lack of adapters on returns, value objects are always (from interpreter, C1 and C2) returned in scalarized form if the return type is a value class. Similar to scalarized calls, an issue occurs when overridden and overriding methods do not agree if the return value should be passed in scalarized form. For example, we might compile a call to a method with an unloaded return type. Later, the return type is loaded and the method (or an overriding method) returns a value in scalarized form that the previously compiled caller can't handle.
>> 
>> Since the interpreter always checks if a to-be-returned value or a value returned from a call is in scalarized form, we only need additional handling in C1 and C2. For C2, we replace the null assert, that is added after a call site with an unloaded return type, by a full-blown trap. This should have minimal impact and will be further improved (see remaining work section below). For C1, we need additional checks when returning an unloaded type and after invoking a method with an unloaded type. In both cases, the overhead is negligible because it boils down to a bit-check on a register to determine if we need to go to the slow path to handle a scalarized return.
>> 
>> **Other changes:**
>> - Lots of tests relying on jasm to introduce preload attribute mismatches.
>> - Extended the `StressCallingConvention` flag to stress test new code paths.
>> - Some refactoring/cleanup of related code.
>> 
>> Since this change became quite large, I'm postponing the following remaining work to [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443):
>> - A static call to a mismatched method should still be scalarized, we currently fall back to the non-scalarized calling convention even for static calls.
>> - If C2 compiles a call with an unloaded return type, a trap is added. We can do better here by adding a null assert and handling scalarized returns similar to the `PhaseMacroExpand::expand_mh_intrinsic_return` logic.
>> - Enable `StressCallingConvention` in `InterpreterMacroAssembler::remove_activation`, this still triggers some issues.
>> - The calling convention should only be computed once, it's currently re-computed during C1 compilation.
>> 
>> Thanks,
>> Tobias
>
> Runtime bits look good, thanks for the cleanups along the way

Thanks for the review, @MrSimms!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/834#issuecomment-1513067641

From thartmann at openjdk.org  Tue Apr 18 14:43:02 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Apr 2023 14:43:02 GMT
Subject: [lworld] RFR: 8306301: [lworld] Circular dependency when unpacking
Message-ID: <5n7gWp8kafl2QsyGUAfxi8SHLLiOk8SpoNfGu62uobY=.f42bd84d-2b37-4e8d-8f21-300d5fb7de46@github.com>

The enhanced `StressCallingConvention` option from [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) triggered a spurious assert due to an unresolvable circular dependency between register/stack slots when emitting code for unpacking. The root cause is that `v0` is used as spill register on aarch64 but that register is also used for arguments and therefore not able to resolve all circular dependencies. We should use `v8` instead which is also save on call for Java.

Thanks,
Tobias

-------------

Commit messages:
 - 8306301: [lworld] Circular dependency when unpacking

Changes: https://git.openjdk.org/valhalla/pull/835/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=835&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306301
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/835.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/835/head:pull/835

PR: https://git.openjdk.org/valhalla/pull/835

From thartmann at openjdk.org  Tue Apr 18 16:58:14 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Apr 2023 16:58:14 GMT
Subject: [lworld] Integrated: 8306301: [lworld] Circular dependency when
 unpacking
In-Reply-To: <5n7gWp8kafl2QsyGUAfxi8SHLLiOk8SpoNfGu62uobY=.f42bd84d-2b37-4e8d-8f21-300d5fb7de46@github.com>
References: <5n7gWp8kafl2QsyGUAfxi8SHLLiOk8SpoNfGu62uobY=.f42bd84d-2b37-4e8d-8f21-300d5fb7de46@github.com>
Message-ID: <oFDTXe9CUpBNXq3vsASRESnF7qOt3q5nylvzzFG5gpo=.882fcc65-0ebe-4f59-bd71-67bcf5e7ba8b@github.com>

On Tue, 18 Apr 2023 14:35:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The enhanced `StressCallingConvention` option from [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) triggered a spurious assert due to an unresolvable circular dependency between register/stack slots when emitting code for unpacking. The root cause is that `v0` is used as spill register on aarch64 but that register is also used for arguments and therefore not able to resolve all circular dependencies. We should use `v8` instead which is also save on call for Java.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 27cde0aa
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/27cde0aa962037f61ce2248be5e7f43fcbc94563
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8306301: [lworld] Circular dependency when unpacking

-------------

PR: https://git.openjdk.org/valhalla/pull/835

From jbhateja at openjdk.org  Wed Apr 19 02:37:09 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 19 Apr 2023 02:37:09 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v8]
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <G953Jq0RiYxXXo6MktLW_eYiRVRmYEBISc0iTrxYkBU=.faa4a47d-0bc7-4e1e-a798-637380724f53@github.com>

> Please find below the summary of changes included with the patch:
>   
> a) _ci Model:_
>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
> 
> b) _C1 compiler:_
>    Special handling to copy entire multifield bundle during withfield bytecode processing.
> 
> c) _C2 compiler:_
>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
> 
> d) _Runtime:_
>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
> 
> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
> 
> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
> 
> More information can be found at following link
> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
> 
> Please share your feedback and suggestions.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Fix ciType creation for multifield.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/b5dd30a0..6e735913

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=07
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=06-07

  Stats: 10 lines in 4 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/833.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833

PR: https://git.openjdk.org/valhalla/pull/833

From thartmann at openjdk.org  Wed Apr 19 07:53:15 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Apr 2023 07:53:15 GMT
Subject: [lworld] Integrated: 8301007: [lworld] Handle mismatches of the
 preload attribute in the calling convention
In-Reply-To: <JOcxjxPwX23hZ16i8c8ydNhwnO6HPW1c4C4JuiV7Ufk=.cfbac6de-42ed-47f0-bead-6070938108ec@github.com>
References: <JOcxjxPwX23hZ16i8c8ydNhwnO6HPW1c4C4JuiV7Ufk=.cfbac6de-42ed-47f0-bead-6070938108ec@github.com>
Message-ID: <E82HaFUwLp6T75xyRK7BS8wvvu6aPtzAXbJ7Ons1cbc=.167b5ac2-2c3b-4d87-8136-a6bc0f4ed4df@github.com>

On Tue, 18 Apr 2023 11:12:13 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [Don't be afraid by the ~4,700 LOC, it's mostly tests ?]
> 
> C2 passes value class arguments in scalarized form if the calling convention of the resolved method supports this. This requires that the calling conventions of all overriding methods need to agree on which arguments are passed in scalarized form. Since the preload attribute added with [JDK-8281116](https://bugs.openjdk.org/browse/JDK-8281116) does not guarantee any consistency between the overridden and overriding method, we need to handle mismatches at runtime. The same applies to returning value classes in scalarized form.
> 
> [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) discusses several options for handling mismatches. Unfortunately, they are either very complex to implement (mismatch detection in the callee leading to deoptimization and re-execution in the caller) and/or have a significant impact on performance/footprint (global dictionary), sometimes even affecting methods not participating in the mismatch.
> 
> After several iterations of thinking and prototyping, I came up with the following solution.
> 
> **Scalarized calls:**
> The calling convention is determined per method at link time. Mismatches can always be detected at that point by walking up the chain of overridden methods and checking if their calling conventions match for each argument with what we would like to set up for the to-be-linked method. In most of the cases, we can handle a mismatch by simply sticking to the calling convention that the super method uses. I.e., if the super method uses a non-scalarized calling convention because the argument was not yet loaded at link time due to a missing preload attribute, we don't scalarize that argument of the overriding method(s) either. In fact, a fallback to the non-scalarized calling convention is always sufficient because it can't happen that the argument type was loaded when the super method was linked and is not loaded now that an overriding method is linked.
> 
> However, this does not work in the following case of multiple inheritance where `MyValue` was not yet loaded when `I1::m` was linked but was loaded when `I2::m` was linked. Since the interfaces are completely independent, we scalarize the argument for `I2::m` but not for `I1::m`:
> 
> 
> interface I1 {
>   void m(LMyValue arg); // Non-scalarized due to missing preload attribute
> }
> 
> interface I2 {
>   void m(LMyValue arg); // Scalarized due to preload attribute
> }
> 
> class C implements I1, I2 {
>   void m(LMyValue arg) { }
> }
> 
> 
> Now once `C::m` is linked, we can't simply fall back to the non-scalarized calling convention because the method can still be called with a scalarized calling convention through `I2::m`. We mark such "offending" methods, in this case only `I2::m`, in the overriding chain as mismatched, deoptimize all C2 compiled methods that include a scalarized call via that method and re-compile them by using the non-scalarized calling convention. To do that, we register an evol dependency when compiling a scalarized call site (via `C->dependencies()->assert_evol_method(call->method())`) and deoptimize all dependent nmethods via `CodeCache::flush_dependents_on_method` after mismatch detection.
> 
> **Scalarized returns:**
> Due to the lack of adapters on returns, value objects are always (from interpreter, C1 and C2) returned in scalarized form if the return type is a value class. Similar to scalarized calls, an issue occurs when overridden and overriding methods do not agree if the return value should be passed in scalarized form. For example, we might compile a call to a method with an unloaded return type. Later, the return type is loaded and the method (or an overriding method) returns a value in scalarized form that the previously compiled caller can't handle.
> 
> Since the interpreter always checks if a to-be-returned value or a value returned from a call is in scalarized form, we only need additional handling in C1 and C2. For C2, we replace the null assert, that is added after a call site with an unloaded return type, by a full-blown trap. This should have minimal impact and will be further improved (see remaining work section below). For C1, we need additional checks when returning an unloaded type and after invoking a method with an unloaded type. In both cases, the overhead is negligible because it boils down to a bit-check on a register to determine if we need to go to the slow path to handle a scalarized return.
> 
> **Other changes:**
> - Lots of tests relying on jasm to introduce preload attribute mismatches.
> - Extended the `StressCallingConvention` flag to stress test new code paths.
> - Some refactoring/cleanup of related code.
> 
> Since this change became quite large, I'm postponing the following remaining work to [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443):
> - A static call to a mismatched method should still be scalarized, we currently fall back to the non-scalarized calling convention even for static calls.
> - If C2 compiles a call with an unloaded return type, a trap is added. We can do better here by adding a null assert and handling scalarized returns similar to the `PhaseMacroExpand::expand_mh_intrinsic_return` logic.
> - Enable `StressCallingConvention` in `InterpreterMacroAssembler::remove_activation`, this still triggers some issues.
> - The calling convention should only be computed once, it's currently re-computed during C1 compilation.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 6b0631cc
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6b0631ccc0d4aaa05177b643b69c2177b2887c61
Stats:     4751 lines in 30 files changed: 4626 ins; 13 del; 112 mod

8301007: [lworld] Handle mismatches of the preload attribute in the calling convention

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/834

From thartmann at openjdk.org  Wed Apr 19 12:28:18 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Apr 2023 12:28:18 GMT
Subject: [lworld] RFR: 8306443: [lworld] Incorrect loading of is-init-byte from
 stack
Message-ID: <_0GsWC_3vgrdb2UCjymePfVUAlRc2eKqPstbUQPTVg0=.654cce92-c197-41b2-89d1-7dcaa59fab09@github.com>

Incorrect loading of the is-init-byte (that determines if a scalarized argument is non-null) from the stack when buffering scalarized arguments leads to intermittent failures.

Best regards,
Tobias

-------------

Commit messages:
 - 8306443: [lworld] Incorrect loading of null byte from stack

Changes: https://git.openjdk.org/valhalla/pull/836/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=836&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306443
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/836.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/836/head:pull/836

PR: https://git.openjdk.org/valhalla/pull/836

From thartmann at openjdk.org  Wed Apr 19 13:07:24 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Apr 2023 13:07:24 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes [v2]
In-Reply-To: <IOXNIFFZnvKO-v11TVoDITUgIcm0Q0A9SkH03t0JqbI=.4d8f00a3-63ba-4ab8-8dd5-8532d2f0f12d@github.com>
References: <FN-qVFYWWJMRHTcBp5Nxz4uCN8E75xfpHxFSrA4VdIw=.57f613bd-62a0-4823-bcbc-8e67e13656e6@github.com>
 <IOXNIFFZnvKO-v11TVoDITUgIcm0Q0A9SkH03t0JqbI=.4d8f00a3-63ba-4ab8-8dd5-8532d2f0f12d@github.com>
Message-ID: <7tgQno56GRSbqINqbLDufoMc-yyiXoD0cAfeZfEYSbc=.cb8f6dfb-e22b-4ad2-8799-7191587524b2@github.com>

On Wed, 15 Mar 2023 19:29:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> When --enable-preview is true, the patching of some java.base classes as value classes disables CDS. 
>> Subsequently the CDS tests fail.
>> 
>> For a CDS, disable Valhalla when --enable-preview is set so java.base is not patched with value classes.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to jdi TestScaffold

Looks reasonable to me.

Problem listing sounds good as well. This just causes lots of noise in testing in the CI so it would be nice to get a fix in soon.

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/832#pullrequestreview-1392018146
PR Comment: https://git.openjdk.org/valhalla/pull/832#issuecomment-1514701377

From thartmann at openjdk.org  Wed Apr 19 13:26:26 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Apr 2023 13:26:26 GMT
Subject: [lworld] Integrated: 8306443: [lworld] Incorrect loading of
 is-init-byte from stack
In-Reply-To: <_0GsWC_3vgrdb2UCjymePfVUAlRc2eKqPstbUQPTVg0=.654cce92-c197-41b2-89d1-7dcaa59fab09@github.com>
References: <_0GsWC_3vgrdb2UCjymePfVUAlRc2eKqPstbUQPTVg0=.654cce92-c197-41b2-89d1-7dcaa59fab09@github.com>
Message-ID: <1OxKEer5lxYCYQ3FsaV1f5hOCIKuaR_8wU9HTz_-Pbc=.d2075f84-b178-4e4a-8fd5-51cffa78d6da@github.com>

On Wed, 19 Apr 2023 12:20:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Incorrect loading of the is-init-byte (that determines if a scalarized argument is non-null) from the stack when buffering scalarized arguments leads to intermittent failures.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: aba21790
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/aba2179008a7b09842d73450908dba30e04fd647
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8306443: [lworld] Incorrect loading of is-init-byte from stack

-------------

PR: https://git.openjdk.org/valhalla/pull/836

From rriggs at openjdk.org  Wed Apr 19 15:25:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Apr 2023 15:25:06 GMT
Subject: [lworld] RFR: 8306453: ProblemList CDS tests failing with dumping the
 shared archive: --patch-module
Message-ID: <YfXPVAUmIm38GFIl6qUJtaGxwn7hgRIZRXW2YmqBr9M=.ddae8118-db21-445e-b57d-4e6938120b07@github.com>

Problem list tests that file due to [JDK-8304168](https://bugs.openjdk.org/browse/JDK-8304168).

com/sun/jdi/cds/CDSBreakpointTest.java
com/sun/jdi/cds/CDSDeleteAllBkptsTest.java
com/sun/jdi/cds/CDSFieldWatchpoints.java
runtime/cds/appcds/redefineClass/RedefineRunningMethods_Shared.java

-------------

Commit messages:
 - 8306453: ProblemList CDS tests failing with dumping the shared archive: --patch-module

Changes: https://git.openjdk.org/valhalla/pull/837/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306453
  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/837.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/837/head:pull/837

PR: https://git.openjdk.org/valhalla/pull/837

From rriggs at openjdk.org  Wed Apr 19 18:34:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Apr 2023 18:34:18 GMT
Subject: [lworld] Integrated: 8306453: ProblemList CDS tests failing with
 dumping the shared archive: --patch-module
In-Reply-To: <YfXPVAUmIm38GFIl6qUJtaGxwn7hgRIZRXW2YmqBr9M=.ddae8118-db21-445e-b57d-4e6938120b07@github.com>
References: <YfXPVAUmIm38GFIl6qUJtaGxwn7hgRIZRXW2YmqBr9M=.ddae8118-db21-445e-b57d-4e6938120b07@github.com>
Message-ID: <aE0-P2yJ8IyCUy5vmqVhSvLBq7dJLPS0EJHrNeQ_9T4=.666b8a2f-69ee-446f-9121-949320d7bdf6@github.com>

On Wed, 19 Apr 2023 15:15:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Problem list tests that file due to [JDK-8304168](https://bugs.openjdk.org/browse/JDK-8304168).
> 
> com/sun/jdi/cds/CDSBreakpointTest.java
> com/sun/jdi/cds/CDSDeleteAllBkptsTest.java
> com/sun/jdi/cds/CDSFieldWatchpoints.java
> runtime/cds/appcds/redefineClass/RedefineRunningMethods_Shared.java

This pull request has now been integrated.

Changeset: 93355a32
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/93355a32e5f184fbce9f3e27f5f253278c80d8cc
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8306453: ProblemList CDS tests failing with dumping the shared archive: --patch-module

-------------

PR: https://git.openjdk.org/valhalla/pull/837

From jbhateja at openjdk.org  Thu Apr 20 11:31:19 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 20 Apr 2023 11:31:19 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v9]
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <bMeFuBqld3aA0nPaW6USi2bom9HWd8vpTuPQ-hkI9iw=.66bf2526-c405-4679-932c-b06cb2437d6a@github.com>

> Please find below the summary of changes included with the patch:
>   
> a) _ci Model:_
>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
> 
> b) _C1 compiler:_
>    Special handling to copy entire multifield bundle during withfield bytecode processing.
> 
> c) _C2 compiler:_
>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
> 
> d) _Runtime:_
>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
> 
> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
> 
> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
> 
> More information can be found at following link
> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
> 
> Please share your feedback and suggestions.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Some fixes in de-optimization handling of payloads, field-access APIs and Java side.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/6e735913..5902b90a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=08
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=07-08

  Stats: 150 lines in 14 files changed: 32 ins; 42 del; 76 mod
  Patch: https://git.openjdk.org/valhalla/pull/833.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833

PR: https://git.openjdk.org/valhalla/pull/833

From rriggs at openjdk.org  Thu Apr 20 13:32:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 13:32:15 GMT
Subject: [lworld] RFR: 8306567: ProblemList ProblemList CDS test
 RedefineRunningMethods_Shared.java
Message-ID: <j4uN81X3nCf1009Pzy3OFkfHDj9B6rXHAGTXoOUPzKE=.95764967-f3d0-44dc-99ea-7bf432fddef9@github.com>

Move RedefineRunningMethods_Shared.java to hotspot runtime ProblemList.

-------------

Commit messages:
 - 8306567: ProblemList ProblemList CDS test RedefineRunningMethods_Shared.java

Changes: https://git.openjdk.org/valhalla/pull/838/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=838&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306567
  Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/838.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/838/head:pull/838

PR: https://git.openjdk.org/valhalla/pull/838

From thartmann at openjdk.org  Thu Apr 20 13:56:10 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 20 Apr 2023 13:56:10 GMT
Subject: [lworld] RFR: 8306565: [lworld] Asserts with stress testing during
 PhaseCCP due to unexpected top types
Message-ID: <yyOKYZTaEcwPC8TZCWWOnCcp2u0HfC2JgUQnNiiWv0c=.659c4c75-9313-4cc5-854d-4c39ddae1821@github.com>

We intermittently assert during PhaseCCP with stress flags because some node types are still top. We should simply handle such cases.

Best regards,
Tobias

-------------

Commit messages:
 - 8306565: [lworld] Asserts with stress testing during PhaseCCP due to unexpected top types

Changes: https://git.openjdk.org/valhalla/pull/839/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306565
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/839.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/839/head:pull/839

PR: https://git.openjdk.org/valhalla/pull/839

From thartmann at openjdk.org  Thu Apr 20 14:15:47 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 20 Apr 2023 14:15:47 GMT
Subject: git: openjdk/valhalla: lworld: 8306565: [lworld] Asserts with stress
 testing during PhaseCCP due to unexpected top types
Message-ID: <0c297ed0-cf4f-4d63-93e8-6b478d1e505a@openjdk.org>

Changeset: 88632a32
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2023-04-20 14:13:40 +0000
URL:       https://git.openjdk.org/valhalla/commit/88632a32ad85dc5c6ed912e291be939741806bd1

8306565: [lworld] Asserts with stress testing during PhaseCCP due to unexpected top types

! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/type.cpp


From thartmann at openjdk.org  Thu Apr 20 14:17:15 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 20 Apr 2023 14:17:15 GMT
Subject: [lworld] Integrated: 8306565: [lworld] Asserts with stress testing
 during PhaseCCP due to unexpected top types
In-Reply-To: <yyOKYZTaEcwPC8TZCWWOnCcp2u0HfC2JgUQnNiiWv0c=.659c4c75-9313-4cc5-854d-4c39ddae1821@github.com>
References: <yyOKYZTaEcwPC8TZCWWOnCcp2u0HfC2JgUQnNiiWv0c=.659c4c75-9313-4cc5-854d-4c39ddae1821@github.com>
Message-ID: <LD3hdX1FSnzzDSJOo5Jh1hHyXLVA-jKTFLfSaPjNP88=.1c7c0a21-a69c-4c1a-a104-d2d6e5c31465@github.com>

On Thu, 20 Apr 2023 13:49:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We intermittently assert during PhaseCCP with stress flags because some node types are still top. We should simply handle such cases.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 88632a32
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/88632a32ad85dc5c6ed912e291be939741806bd1
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8306565: [lworld] Asserts with stress testing during PhaseCCP due to unexpected top types

-------------

PR: https://git.openjdk.org/valhalla/pull/839

From thartmann at openjdk.org  Thu Apr 20 14:21:14 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 20 Apr 2023 14:21:14 GMT
Subject: [lworld] RFR: 8306567: ProblemList ProblemList CDS test
 RedefineRunningMethods_Shared.java
In-Reply-To: <j4uN81X3nCf1009Pzy3OFkfHDj9B6rXHAGTXoOUPzKE=.95764967-f3d0-44dc-99ea-7bf432fddef9@github.com>
References: <j4uN81X3nCf1009Pzy3OFkfHDj9B6rXHAGTXoOUPzKE=.95764967-f3d0-44dc-99ea-7bf432fddef9@github.com>
Message-ID: <9GI1L7qWp0NpP7mjwdkKzLQgBbZw57MtWbiAMqk3cIc=.53b79283-d350-429c-9b6d-d394bd39534a@github.com>

On Thu, 20 Apr 2023 13:25:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Move RedefineRunningMethods_Shared.java to hotspot runtime ProblemList.

Looks good.

You might want to fix the bug title "ProblemList ProblemList"

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/838#pullrequestreview-1394113676
PR Comment: https://git.openjdk.org/valhalla/pull/838#issuecomment-1516414443

From rriggs at openjdk.org  Thu Apr 20 15:50:32 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 15:50:32 GMT
Subject: git: openjdk/valhalla: lworld: 8306567: ProblemList ProblemList CDS
 test RedefineRunningMethods_Shared.java
Message-ID: <3fad5426-6c04-4e24-a2a3-adf17351a03f@openjdk.org>

Changeset: edac97b7
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2023-04-20 15:47:46 +0000
URL:       https://git.openjdk.org/valhalla/commit/edac97b79163096594360f24c85415d7d46448d3

8306567: ProblemList ProblemList CDS test RedefineRunningMethods_Shared.java

Reviewed-by: thartmann

! test/hotspot/jtreg/ProblemList.txt
! test/jdk/ProblemList.txt


From rriggs at openjdk.org  Thu Apr 20 15:51:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 15:51:10 GMT
Subject: [lworld] Integrated: 8306567: ProblemList ProblemList CDS test
 RedefineRunningMethods_Shared.java
In-Reply-To: <j4uN81X3nCf1009Pzy3OFkfHDj9B6rXHAGTXoOUPzKE=.95764967-f3d0-44dc-99ea-7bf432fddef9@github.com>
References: <j4uN81X3nCf1009Pzy3OFkfHDj9B6rXHAGTXoOUPzKE=.95764967-f3d0-44dc-99ea-7bf432fddef9@github.com>
Message-ID: <pGj-TdVi07Jfi6dmL2INZv8eS5tArFSrDcEc24YBwms=.cb8563d8-d0ad-43bb-aa17-958f6d7ec0ca@github.com>

On Thu, 20 Apr 2023 13:25:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Move RedefineRunningMethods_Shared.java to hotspot runtime ProblemList.

This pull request has now been integrated.

Changeset: edac97b7
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/edac97b79163096594360f24c85415d7d46448d3
Stats:     3 lines in 2 files changed: 2 ins; 1 del; 0 mod

8306567: ProblemList ProblemList CDS test RedefineRunningMethods_Shared.java

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.org/valhalla/pull/838

From thartmann at openjdk.org  Fri Apr 21 07:25:14 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 21 Apr 2023 07:25:14 GMT
Subject: [lworld] RFR: 8306568: [lworld] Oop verification failure in
 InlineKlass::returned_inline_klass
Message-ID: <uhzW_skpbfWIIVwHa3Sf1yxJD1LueoMISuxhJaMoY3s=.f89c8cb7-0947-482a-8bf1-a1003cb96a61@github.com>

Oop verification intermittently fails with ZGC when checking the oop return value of a method from `ThreadSafepointState::handle_polling_page_exception` -> `InlineKlass::returned_inline_klass`  at returns. The problem is that header verification in `oopDesc::is_oop` fails because the mark word is set. Given that this code is executed outside of a safepoint, it's not safe to assume that the mark word is zero. I changed the verification code accordingly.

Thanks,
Tobias

-------------

Commit messages:
 - 8306568: [lworld] Oop verification failure in InlineKlass::returned_inline_klass

Changes: https://git.openjdk.org/valhalla/pull/840/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306568
  Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/840.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/840/head:pull/840

PR: https://git.openjdk.org/valhalla/pull/840

From thartmann at openjdk.org  Fri Apr 21 08:21:59 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 21 Apr 2023 08:21:59 GMT
Subject: [lworld] RFR: 8303000: [lworld] C2 compilation fails with
 assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr))
 failed: correct memory chain
Message-ID: <OOI_SX-ZrwOj98edQK-yXPHYSCf35IgTkWyqJlbQioM=.9a928bb8-39cd-4984-b739-912ef021b631@github.com>

Mainline fix for [JDK-8288204](https://bugs.openjdk.org/browse/JDK-8288204) needs to be extended to account for flat/null-free arrays.

Best regards,
Tobias

-------------

Commit messages:
 - 8303000: [lworld] C2 compilation fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain

Changes: https://git.openjdk.org/valhalla/pull/841/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=841&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303000
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/841.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/841/head:pull/841

PR: https://git.openjdk.org/valhalla/pull/841

From dsimms at openjdk.org  Fri Apr 21 08:30:17 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 21 Apr 2023 08:30:17 GMT
Subject: [lworld] RFR: 8306568: [lworld] Oop verification failure in
 InlineKlass::returned_inline_klass
In-Reply-To: <uhzW_skpbfWIIVwHa3Sf1yxJD1LueoMISuxhJaMoY3s=.f89c8cb7-0947-482a-8bf1-a1003cb96a61@github.com>
References: <uhzW_skpbfWIIVwHa3Sf1yxJD1LueoMISuxhJaMoY3s=.f89c8cb7-0947-482a-8bf1-a1003cb96a61@github.com>
Message-ID: <G9axvcflm76NUxb_2lD-u4Gq8z9seqroXxxoqNxGUhw=.14465aee-8194-4fa1-bf85-c58fc39e3b9f@github.com>

On Fri, 21 Apr 2023 07:18:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Oop verification intermittently fails with ZGC when checking the oop return value of a method from `ThreadSafepointState::handle_polling_page_exception` -> `InlineKlass::returned_inline_klass`  at returns. The problem is that header verification in `oopDesc::is_oop` fails because the mark word is set. Given that this code is executed outside of a safepoint, it's not safe to assume that the mark word is zero. I changed the verification code accordingly.
> 
> Thanks,
> Tobias

LGTM

-------------

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/840#pullrequestreview-1395327823

From jbhateja at openjdk.org  Fri Apr 21 10:41:05 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 21 Apr 2023 10:41:05 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v10]
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>

> Please find below the summary of changes included with the patch:
>   
> a) _ci Model:_
>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
> 
> b) _C1 compiler:_
>    Special handling to copy entire multifield bundle during withfield bytecode processing.
> 
> c) _C2 compiler:_
>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
> 
> d) _Runtime:_
>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
> 
> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
> 
> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
> 
> More information can be found at following link
> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
> 
> Please share your feedback and suggestions.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Preserve larval state of re-materialized vector payload boxes.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/5902b90a..23fa5745

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=09
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=08-09

  Stats: 36 lines in 6 files changed: 25 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/833.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833

PR: https://git.openjdk.org/valhalla/pull/833

From jbhateja at openjdk.org  Fri Apr 21 10:46:15 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 21 Apr 2023 10:46:15 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v10]
In-Reply-To: <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>
Message-ID: <6Jmr8MO2c1QO-unpQw7NZQfT_ERtV0vIPIfXaPOq64s=.c15540a8-379c-4dd1-8b72-3e8b2354b3fe@github.com>

On Fri, 21 Apr 2023 10:41:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Preserve larval state of re-materialized vector payload boxes.

Currently larval state is not preserved during de-optimization, my last check-in handles it for vector payload boxes. This looks like a bug in stock lworld branch also, but its critical for vector API since fallback implementation makes heavy use of Unsafe.put operations.

Filed separate bugs for larval state preservations in de-optimization and with in-lining disabled.
https://bugs.openjdk.org/browse/JDK-8306659
https://bugs.openjdk.org/browse/JDK-8306669

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/833#issuecomment-1517636083

From thartmann at openjdk.org  Fri Apr 21 10:56:04 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 21 Apr 2023 10:56:04 GMT
Subject: [lworld] RFR: 8306568: [lworld] Oop verification failure in
 InlineKlass::returned_inline_klass
In-Reply-To: <uhzW_skpbfWIIVwHa3Sf1yxJD1LueoMISuxhJaMoY3s=.f89c8cb7-0947-482a-8bf1-a1003cb96a61@github.com>
References: <uhzW_skpbfWIIVwHa3Sf1yxJD1LueoMISuxhJaMoY3s=.f89c8cb7-0947-482a-8bf1-a1003cb96a61@github.com>
Message-ID: <WNEtYANjtzxWxnXVk1UkPtQKiOn6YnGuvg23p0-LoPY=.c444387e-1653-4589-8508-e6e617c52123@github.com>

On Fri, 21 Apr 2023 07:18:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Oop verification intermittently fails with ZGC when checking the oop return value of a method from `ThreadSafepointState::handle_polling_page_exception` -> `InlineKlass::returned_inline_klass`  at returns. The problem is that header verification in `oopDesc::is_oop` fails because the mark word is set. Given that this code is executed outside of a safepoint, it's not safe to assume that the mark word is zero. I changed the verification code accordingly.
> 
> Thanks,
> Tobias

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/840#issuecomment-1517645973

From thartmann at openjdk.org  Fri Apr 21 10:59:04 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 21 Apr 2023 10:59:04 GMT
Subject: [lworld] Integrated: 8306568: [lworld] Oop verification failure in
 InlineKlass::returned_inline_klass
In-Reply-To: <uhzW_skpbfWIIVwHa3Sf1yxJD1LueoMISuxhJaMoY3s=.f89c8cb7-0947-482a-8bf1-a1003cb96a61@github.com>
References: <uhzW_skpbfWIIVwHa3Sf1yxJD1LueoMISuxhJaMoY3s=.f89c8cb7-0947-482a-8bf1-a1003cb96a61@github.com>
Message-ID: <3rymSrt2gAQkj3Rc0vCp1-7VqAdtTC5-KfBmysK8ooY=.c543a3e3-adfa-4b40-aebf-3a33087b738a@github.com>

On Fri, 21 Apr 2023 07:18:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Oop verification intermittently fails with ZGC when checking the oop return value of a method from `ThreadSafepointState::handle_polling_page_exception` -> `InlineKlass::returned_inline_klass`  at returns. The problem is that header verification in `oopDesc::is_oop` fails because the mark word is set. Given that this code is executed outside of a safepoint, it's not safe to assume that the mark word is zero. I changed the verification code accordingly.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: e7d52073
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e7d520735318131b107a8a62393b1768934a7def
Stats:     7 lines in 1 file changed: 0 ins; 3 del; 4 mod

8306568: [lworld] Oop verification failure in InlineKlass::returned_inline_klass

Reviewed-by: dsimms

-------------

PR: https://git.openjdk.org/valhalla/pull/840

From thartmann at openjdk.org  Fri Apr 21 11:41:13 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 21 Apr 2023 11:41:13 GMT
Subject: [lworld] Integrated: 8303000: [lworld] C2 compilation fails with
 assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr))
 failed: correct memory chain
In-Reply-To: <OOI_SX-ZrwOj98edQK-yXPHYSCf35IgTkWyqJlbQioM=.9a928bb8-39cd-4984-b739-912ef021b631@github.com>
References: <OOI_SX-ZrwOj98edQK-yXPHYSCf35IgTkWyqJlbQioM=.9a928bb8-39cd-4984-b739-912ef021b631@github.com>
Message-ID: <sVuN3llXcKFCJjUqJSwuJdN8t_pUVjXrG-gesPq8Awc=.5edbd234-bb61-475a-8ec9-1f7824d8477b@github.com>

On Fri, 21 Apr 2023 08:14:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Mainline fix for [JDK-8288204](https://bugs.openjdk.org/browse/JDK-8288204) needs to be extended to account for flat/null-free arrays.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 404d2ab1
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/404d2ab1fc480b69bd38877473f2621a61a2ad4e
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8303000: [lworld] C2 compilation fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain

-------------

PR: https://git.openjdk.org/valhalla/pull/841

From thartmann at openjdk.org  Fri Apr 21 14:48:05 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 21 Apr 2023 14:48:05 GMT
Subject: [lworld] Integrated: 8306677: [lworld] TestCallingConventionC1 fails
 on AArch64 with -XX:+PatchALot
Message-ID: <iQRL-KRe_4benmkdUprEhAOAzdQbkPLiVQaCOGyfaqg=.98452971-cb6a-42cb-b4ef-fa1615b5b305@github.com>

On AArch64, patching in C1 is handled by deoptimization (`DEOPTIMIZE_WHEN_PATCHING`) and therefore TestCallingConventionC1 fails with `-XX:+PatchALot` because some test methods are unexpectedly deoptimized. The fix is to disable that flag if C1 is the only available compiler.

Best regards,
Tobias

-------------

Commit messages:
 - 8306677: [lworld] TestCallingConventionC1 fails on AArch64 with -XX:+PatchALot

Changes: https://git.openjdk.org/valhalla/pull/842/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=842&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306677
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/842.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/842/head:pull/842

PR: https://git.openjdk.org/valhalla/pull/842

From thartmann at openjdk.org  Fri Apr 21 14:48:07 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 21 Apr 2023 14:48:07 GMT
Subject: [lworld] Integrated: 8306677: [lworld] TestCallingConventionC1 fails
 on AArch64 with -XX:+PatchALot
In-Reply-To: <iQRL-KRe_4benmkdUprEhAOAzdQbkPLiVQaCOGyfaqg=.98452971-cb6a-42cb-b4ef-fa1615b5b305@github.com>
References: <iQRL-KRe_4benmkdUprEhAOAzdQbkPLiVQaCOGyfaqg=.98452971-cb6a-42cb-b4ef-fa1615b5b305@github.com>
Message-ID: <vZBh25XYQ1nvQMsFxCKOnEyAzQyAJ9bdmaJW8mU20R4=.e4edc0cf-060f-48c5-af35-4483779a0d5b@github.com>

On Fri, 21 Apr 2023 14:36:07 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> On AArch64, patching in C1 is handled by deoptimization (`DEOPTIMIZE_WHEN_PATCHING`) and therefore TestCallingConventionC1 fails with `-XX:+PatchALot` because some test methods are unexpectedly deoptimized. The fix is to disable that flag if C1 is the only available compiler.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 6673e60b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6673e60b5f65664ff2858880dcd64e4be7b03448
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8306677: [lworld] TestCallingConventionC1 fails on AArch64 with -XX:+PatchALot

-------------

PR: https://git.openjdk.org/valhalla/pull/842

From xgong at openjdk.org  Sun Apr 23 08:16:13 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 23 Apr 2023 08:16:13 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v10]
In-Reply-To: <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>
Message-ID: <TUvnjh4kmNo_PWsTmTvzocSQ1ZSEbHaT4F0S1pvGbvE=.5cab1e4b-92a9-4efb-b37b-fc26d6b35025@github.com>

On Fri, 21 Apr 2023 10:41:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Preserve larval state of re-materialized vector payload boxes.

src/hotspot/share/opto/vector.cpp line 391:

> 389:     ciField* mutifield = payload_klass->declared_nonstatic_field_at(0);
> 390:     offset += mutifield->offset();
> 391:   }

If the `payload_field` is not flattened, I'm afraid the payload value should be buffered like the original array instance?

src/hotspot/share/opto/vector.cpp line 537:

> 535:         ciField* mutifield = payload_klass->declared_nonstatic_field_at(0);
> 536:         offset += mutifield->offset();
> 537:       }

Same with expanding vbox, if the `payload_field` is not flattened, we have to load the payload instance first, decode and then load the vector mf?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1174531563
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1174533048

From xgong at openjdk.org  Sun Apr 23 08:23:09 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 23 Apr 2023 08:23:09 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v7]
In-Reply-To: <2gO4ioPnyK0ya6aCMBnRL8nWXhmkKJyirJdo1inii4s=.41ad7b82-dbba-40e6-b182-14b500627d3c@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <2gO4ioPnyK0ya6aCMBnRL8nWXhmkKJyirJdo1inii4s=.41ad7b82-dbba-40e6-b182-14b500627d3c@github.com>
Message-ID: <dxDHVWHnvlFISssCHLCkqLb1pO67EwflpWJAsGIOggQ=.3bc7dbf6-272c-4ac5-934e-af0bfd7e2f75@github.com>

On Fri, 14 Apr 2023 07:03:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
> 
>  - Extend box forwarding transformation across Phi nodes.
>  - Code refactoring around vector boxing/unboxing.
>  - Review comments resolutions.

src/hotspot/share/opto/vectornode.hpp line 1695:

> 1693:     Node* payload_value = InlineTypeNode::make_uninitialized(gvn, payload, true);
> 1694:     payload_value->as_InlineType()->set_field_value(0, val);
> 1695:     payload_value = gvn.transform(payload_value);

Can we move  this to `expand_vbox_node` pass? We can keep the simple two inputs `Box` and `Value` for VectorBox like before. This can simply the change in `merge_through_phi`. 

Besides, `payload_oop` is not used, so can it be removed?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1174534046

From xgong at openjdk.org  Sun Apr 23 08:33:12 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 23 Apr 2023 08:33:12 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v10]
In-Reply-To: <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>
Message-ID: <VfipMCkKeoFL-iT6tK0mqeGc3mU5sncWlx_JvBq1o3A=.747b860b-c0d4-4831-b618-cb67fb937749@github.com>

On Fri, 21 Apr 2023 10:41:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Please find below the summary of changes included with the patch:
>>   
>> a) _ci Model:_
>>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
>> 
>> b) _C1 compiler:_
>>    Special handling to copy entire multifield bundle during withfield bytecode processing.
>> 
>> c) _C2 compiler:_
>>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
>> 
>> d) _Runtime:_
>>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
>> 
>> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
>> 
>> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
>> 
>> More information can be found at following link
>> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
>> 
>> Please share your feedback and suggestions.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Preserve larval state of re-materialized vector payload boxes.

src/hotspot/share/code/debugInfo.cpp line 154:

> 152:   _klass = read_from(stream);
> 153:   _is_init = read_from(stream);
> 154:   _in_larval = read_from(stream);

Rename `_in_larval` to `_is_larval` ?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1174535574

From thartmann at openjdk.org  Mon Apr 24 13:47:06 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Apr 2023 13:47:06 GMT
Subject: [lworld] RFR: 8232892: [AARCH64] [lworld] Inline type use of Access
 API (compiler barrier support)
Message-ID: <7IyR6JVhS1fQz6Mx2aw2wiQF45Gl6ro24ozL8zAYuyY=.98d1a510-5f04-469e-bdeb-4ddf17d6843b@github.com>

Missing AArch64 specific parts of [JDK-8231498](https://bugs.openjdk.org/browse/JDK-8231498). Most of the code has been fixed in the meantime by other changes.

Thanks,
Tobias

-------------

Commit messages:
 - 8232892: [AARCH64] [lworld] Inline type use of Access API (compiler barrier support)

Changes: https://git.openjdk.org/valhalla/pull/843/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=843&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8232892
  Stats: 13 lines in 1 file changed: 0 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/843.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/843/head:pull/843

PR: https://git.openjdk.org/valhalla/pull/843

From thartmann at openjdk.org  Mon Apr 24 15:40:17 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Apr 2023 15:40:17 GMT
Subject: [lworld] Integrated: 8232892: [AARCH64] [lworld] Inline type use of
 Access API (compiler barrier support)
In-Reply-To: <7IyR6JVhS1fQz6Mx2aw2wiQF45Gl6ro24ozL8zAYuyY=.98d1a510-5f04-469e-bdeb-4ddf17d6843b@github.com>
References: <7IyR6JVhS1fQz6Mx2aw2wiQF45Gl6ro24ozL8zAYuyY=.98d1a510-5f04-469e-bdeb-4ddf17d6843b@github.com>
Message-ID: <5Z_pDMCIrf-fatWMVmVOpRCb9c_acFBzT0_Ul0iLNqY=.3ad0fc1b-ae9e-43ac-83f0-186cef1d9202@github.com>

On Mon, 24 Apr 2023 13:40:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Missing AArch64 specific parts of [JDK-8231498](https://bugs.openjdk.org/browse/JDK-8231498). Most of the code has been fixed in the meantime by other changes.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: c5c56757
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c5c56757cb03e88cd952d50445646b9fcf1ad92f
Stats:     13 lines in 1 file changed: 0 ins; 8 del; 5 mod

8232892: [AARCH64] [lworld] Inline type use of Access API (compiler barrier support)

-------------

PR: https://git.openjdk.org/valhalla/pull/843

From davidalayachew at gmail.com  Mon Apr 24 21:07:19 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 24 Apr 2023 17:07:19 -0400
Subject: Trying to build valhalla from source code, but failing
Message-ID: <CAA9v-_PEy72AZ1BdYi+6HbecngL+n7RH_O31UPebqgQ5c5vZ2Q@mail.gmail.com>

Hello Valhalla Dev Team,

I am trying to build the Valhalla code base from source so that I can test
some of the new features. However, when I tried to do so this morning, my
build failed because a warning was thrown, and the build seems to fail on
warnings.

Here is the warning.

C:\cygwin64\home\david\valhalla\src\jdk.compiler\share\classes\com\sun\tools\javac\code\Lint.java:145:
warning: [this-escape] possible 'this' escape before subclass is fully
initialized
        context.put(lintKey, this);
                             ^
error: warnings found and -Werror specified
1 error
1 warning

Here is a link to the class on Valhalla's code base.

Current -
https://github.com/openjdk/valhalla/blob/lworld/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java#L145

Commit -
https://github.com/openjdk/valhalla/blob/947ad67fcdbef5e518f60a30b60309d9fc2cf337/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java#L145

Long story short, a new warning was added to JDK 21, and since I am
building Valhalla using this JDK 21, it is throwing a warning. They have
since put a @SuppressWarnings("this-escape") on the offending method in the
main line jdk code base, but that commit has not yet been put into the
Valhalla code base.

I don't really know how to hide my JDK 21 build, or to tell the Valhalla
build script to use my JDK 20 build. But, worst case scenario, I can just
delete my JDK 21 build, so I am not blocked. But I wanted to bring this up
in case this is something that needed action to be taken on.

Thank you for your time!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230424/07de7b8b/attachment-0001.htm>

From liangchenblue at gmail.com  Tue Apr 25 13:38:20 2023
From: liangchenblue at gmail.com (-)
Date: Tue, 25 Apr 2023 08:38:20 -0500
Subject: Reference pointers in compact value objects (primitive classes)
Message-ID: <CABe8uE0D-B8LbN_SxELnRehNyPKhG08Rvgp+RXPUbUQAomaa0w@mail.gmail.com>

Hello,
I just wonder if nullable reference pointers can be part of compact
value objects.

For instance, in the Classfile API, there is StackMapGenerator.Type, a
record with (int type, ClassDesc reference, int bci). The default
state (0, null, 0) is valid and a desirable default (0 type means
top-type). If the ClassDesc field can be part of the compact
representation, then the whole structure can be optimized, which looks
promising to me.

Meanwhile, I have another question about nullable object
representation in value classes: Suppose we have
Optional<Optional<Optional<String>>>, what will the representation be?
How will we distinguish Optional.empty() with
Optional.of(Optional.empty())?

Thanks,
Chen Liang

From zjx001202 at gmail.com  Tue Apr 25 14:05:57 2023
From: zjx001202 at gmail.com (Glavo)
Date: Tue, 25 Apr 2023 22:05:57 +0800
Subject: Reference pointers in compact value objects (primitive classes)
In-Reply-To: <CABe8uE0D-B8LbN_SxELnRehNyPKhG08Rvgp+RXPUbUQAomaa0w@mail.gmail.com>
References: <CABe8uE0D-B8LbN_SxELnRehNyPKhG08Rvgp+RXPUbUQAomaa0w@mail.gmail.com>
Message-ID: <CAJL5A3m1X6WhOwkdNAgTA259APiJTX5+TEjK_S7MJppFAG2yjg@mail.gmail.com>

>
> Meanwhile, I have another question about nullable object
> representation in value classes: Suppose we have
> Optional<Optional<Optional<String>>>, what will the representation be?
> How will we distinguish Optional.empty() with
> Optional.of(Optional.empty())?
>

To my knowledge, value objects as fields are usually not inlined, so
the representation of Optional.of(Optional.empty()) in heap remains the
same as it is now.

If you want a field to be inlined, its class should be a primitive class.
Value objects are usually only inlined when used as local variables.

Glavo

On Tue, Apr 25, 2023 at 9:39?PM - <liangchenblue at gmail.com> wrote:

> Hello,
> I just wonder if nullable reference pointers can be part of compact
> value objects.
>
> For instance, in the Classfile API, there is StackMapGenerator.Type, a
> record with (int type, ClassDesc reference, int bci). The default
> state (0, null, 0) is valid and a desirable default (0 type means
> top-type). If the ClassDesc field can be part of the compact
> representation, then the whole structure can be optimized, which looks
> promising to me.
>
> Meanwhile, I have another question about nullable object
> representation in value classes: Suppose we have
> Optional<Optional<Optional<String>>>, what will the representation be?
> How will we distinguish Optional.empty() with
> Optional.of(Optional.empty())?
>
> Thanks,
> Chen Liang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230425/9e0b6b9b/attachment.htm>

From forax at univ-mlv.fr  Tue Apr 25 14:46:24 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 25 Apr 2023 16:46:24 +0200 (CEST)
Subject: Reference pointers in compact value objects (primitive classes)
In-Reply-To: <CABe8uE0D-B8LbN_SxELnRehNyPKhG08Rvgp+RXPUbUQAomaa0w@mail.gmail.com>
References: <CABe8uE0D-B8LbN_SxELnRehNyPKhG08Rvgp+RXPUbUQAomaa0w@mail.gmail.com>
Message-ID: <1704292673.42211062.1682433984432.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "-" <liangchenblue at gmail.com>
> To: valhalla-dev at openjdk.org
> Sent: Tuesday, April 25, 2023 3:38:20 PM
> Subject: Reference pointers in compact value objects (primitive classes)

> Hello,
> I just wonder if nullable reference pointers can be part of compact
> value objects.

It depends if it's on the stack or on the heap.
On stack, a nullable reference to a value class if fully scalarized.
On heap, a nullable reference is not flattened, non null reference of value class with a default instance are flattened.

On stack, declaring a class as a value class is enough
  value record Point (int x, int y) {}

On heap, the value class also need a default constructor
   value record Point (int x, int y) {
     default Point();   // the default value is not null but Point(0,0)
   } 

  and when used, a field has to declare that the field is not nullable using '!'
   record Rectangle(Point! topLeft, Point! bottonRight) { }


> 
> For instance, in the Classfile API, there is StackMapGenerator.Type, a
> record with (int type, ClassDesc reference, int bci). The default
> state (0, null, 0) is valid and a desirable default (0 type means
> top-type). If the ClassDesc field can be part of the compact
> representation, then the whole structure can be optimized, which looks
> promising to me.

Most values of the ClassFile API are values on stack so they should be scalarized.
Note that, this is not yet true, currently a switch on a sealed interface forces the rematerialization.

> 
> Meanwhile, I have another question about nullable object
> representation in value classes: Suppose we have
> Optional<Optional<Optional<String>>>, what will the representation be?
> How will we distinguish Optional.empty() with
> Optional.of(Optional.empty())?

Let suppose that Optional is declared with a default instance like this
  value class Optional<T> {
    private final T value;

    default Optional();
    ...
  }

Then you need a '!' to ask for flattening, so Optional<Optional!<String>>

Now to answer to your question, the VM tracks the class (here Optional is specialized class), so even if the memory layout is the same between Optional<String> and Optional<Optional!<String>>, the specialized classes (sometimes also called the species) at runtime are not the same.

> 
> Thanks,
> Chen Liang

regards,
R?mi

From liangchenblue at gmail.com  Tue Apr 25 15:10:06 2023
From: liangchenblue at gmail.com (-)
Date: Tue, 25 Apr 2023 10:10:06 -0500
Subject: Reference pointers in compact value objects (primitive classes)
In-Reply-To: <1704292673.42211062.1682433984432.JavaMail.zimbra@univ-eiffel.fr>
References: <CABe8uE0D-B8LbN_SxELnRehNyPKhG08Rvgp+RXPUbUQAomaa0w@mail.gmail.com>
 <1704292673.42211062.1682433984432.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CABe8uE1f3_uio3oNucMez+4Z5vc8hcuh=oBUATgRQc=dKy-VWQ@mail.gmail.com>

Thanks Rem?!
One more question: can a value class with default constructor (inlined in
heap and arrays) declare a nullable reference field? I don't think we've
talked about this detail anywhere before.

Curious,
Chen

On Tue, Apr 25, 2023, 9:46 AM Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "-" <liangchenblue at gmail.com>
> > To: valhalla-dev at openjdk.org
> > Sent: Tuesday, April 25, 2023 3:38:20 PM
> > Subject: Reference pointers in compact value objects (primitive classes)
>
> > Hello,
> > I just wonder if nullable reference pointers can be part of compact
> > value objects.
>
> It depends if it's on the stack or on the heap.
> On stack, a nullable reference to a value class if fully scalarized.
> On heap, a nullable reference is not flattened, non null reference of
> value class with a default instance are flattened.
>
> On stack, declaring a class as a value class is enough
>   value record Point (int x, int y) {}
>
> On heap, the value class also need a default constructor
>    value record Point (int x, int y) {
>      default Point();   // the default value is not null but Point(0,0)
>    }
>
>   and when used, a field has to declare that the field is not nullable
> using '!'
>    record Rectangle(Point! topLeft, Point! bottonRight) { }
>
>
> >
> > For instance, in the Classfile API, there is StackMapGenerator.Type, a
> > record with (int type, ClassDesc reference, int bci). The default
> > state (0, null, 0) is valid and a desirable default (0 type means
> > top-type). If the ClassDesc field can be part of the compact
> > representation, then the whole structure can be optimized, which looks
> > promising to me.
>
> Most values of the ClassFile API are values on stack so they should be
> scalarized.
> Note that, this is not yet true, currently a switch on a sealed interface
> forces the rematerialization.
>
> >
> > Meanwhile, I have another question about nullable object
> > representation in value classes: Suppose we have
> > Optional<Optional<Optional<String>>>, what will the representation be?
> > How will we distinguish Optional.empty() with
> > Optional.of(Optional.empty())?
>
> Let suppose that Optional is declared with a default instance like this
>   value class Optional<T> {
>     private final T value;
>
>     default Optional();
>     ...
>   }
>
> Then you need a '!' to ask for flattening, so Optional<Optional!<String>>
>
> Now to answer to your question, the VM tracks the class (here Optional is
> specialized class), so even if the memory layout is the same between
> Optional<String> and Optional<Optional!<String>>, the specialized classes
> (sometimes also called the species) at runtime are not the same.
>
> >
> > Thanks,
> > Chen Liang
>
> regards,
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230425/e14a79a0/attachment-0001.htm>

From forax at univ-mlv.fr  Tue Apr 25 15:14:25 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 25 Apr 2023 17:14:25 +0200 (CEST)
Subject: Reference pointers in compact value objects (primitive classes)
In-Reply-To: <CABe8uE1f3_uio3oNucMez+4Z5vc8hcuh=oBUATgRQc=dKy-VWQ@mail.gmail.com>
References: <CABe8uE0D-B8LbN_SxELnRehNyPKhG08Rvgp+RXPUbUQAomaa0w@mail.gmail.com>
 <1704292673.42211062.1682433984432.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE1f3_uio3oNucMez+4Z5vc8hcuh=oBUATgRQc=dKy-VWQ@mail.gmail.com>
Message-ID: <1957019051.42259070.1682435665197.JavaMail.zimbra@univ-eiffel.fr>

> From: "-" <liangchenblue at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Tuesday, April 25, 2023 5:10:06 PM
> Subject: Re: Reference pointers in compact value objects (primitive classes)

> Thanks Rem?!
> One more question: can a value class with default constructor (inlined in heap
> and arrays) declare a nullable reference field? I don't think we've talked
> about this detail anywhere before.

yes, a value class (with a default constructor or without) c 

> Curious,
> Chen

> On Tue, Apr 25, 2023, 9:46 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> ----- Original Message -----
>> > From: "-" < [ mailto:liangchenblue at gmail.com | liangchenblue at gmail.com ] >
>> > To: [ mailto:valhalla-dev at openjdk.org | valhalla-dev at openjdk.org ]
>> > Sent: Tuesday, April 25, 2023 3:38:20 PM
>> > Subject: Reference pointers in compact value objects (primitive classes)

>> > Hello,
>> > I just wonder if nullable reference pointers can be part of compact
>> > value objects.

>> It depends if it's on the stack or on the heap.
>> On stack, a nullable reference to a value class if fully scalarized.
>> On heap, a nullable reference is not flattened, non null reference of value
>> class with a default instance are flattened.

>> On stack, declaring a class as a value class is enough
>> value record Point (int x, int y) {}

>> On heap, the value class also need a default constructor
>> value record Point (int x, int y) {
>> default Point(); // the default value is not null but Point(0,0)
>> }

>> and when used, a field has to declare that the field is not nullable using '!'
>> record Rectangle(Point! topLeft, Point! bottonRight) { }


>> > For instance, in the Classfile API, there is StackMapGenerator.Type, a
>> > record with (int type, ClassDesc reference, int bci). The default
>> > state (0, null, 0) is valid and a desirable default (0 type means
>> > top-type). If the ClassDesc field can be part of the compact
>> > representation, then the whole structure can be optimized, which looks
>> > promising to me.

>> Most values of the ClassFile API are values on stack so they should be
>> scalarized.
>> Note that, this is not yet true, currently a switch on a sealed interface forces
>> the rematerialization.


>> > Meanwhile, I have another question about nullable object
>> > representation in value classes: Suppose we have
>> > Optional<Optional<Optional<String>>>, what will the representation be?
>> > How will we distinguish Optional.empty() with
>> > Optional.of(Optional.empty())?

>> Let suppose that Optional is declared with a default instance like this
>> value class Optional<T> {
>> private final T value;

>> default Optional();
>> ...
>> }

>> Then you need a '!' to ask for flattening, so Optional<Optional!<String>>

>> Now to answer to your question, the VM tracks the class (here Optional is
>> specialized class), so even if the memory layout is the same between
>> Optional<String> and Optional<Optional!<String>>, the specialized classes
>> (sometimes also called the species) at runtime are not the same.


>> > Thanks,
>> > Chen Liang

>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230425/27d4cfd0/attachment.htm>

From forax at univ-mlv.fr  Tue Apr 25 15:16:19 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 25 Apr 2023 17:16:19 +0200 (CEST)
Subject: Reference pointers in compact value objects (primitive classes)
In-Reply-To: <CABe8uE1f3_uio3oNucMez+4Z5vc8hcuh=oBUATgRQc=dKy-VWQ@mail.gmail.com>
References: <CABe8uE0D-B8LbN_SxELnRehNyPKhG08Rvgp+RXPUbUQAomaa0w@mail.gmail.com>
 <1704292673.42211062.1682433984432.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE1f3_uio3oNucMez+4Z5vc8hcuh=oBUATgRQc=dKy-VWQ@mail.gmail.com>
Message-ID: <111640912.42260376.1682435779839.JavaMail.zimbra@univ-eiffel.fr>

> From: "-" <liangchenblue at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Tuesday, April 25, 2023 5:10:06 PM
> Subject: Re: Reference pointers in compact value objects (primitive classes)

> Thanks Rem?!
> One more question: can a value class with default constructor (inlined in heap
> and arrays) declare a nullable reference field? I don't think we've talked
> about this detail anywhere before.

yes, a value class (with a default constructor or without) can have fields that are a String or any other nullable type, not only primitives. 
The GC have been enhanced to correctly deal with them. 

> Curious,
> Chen

R?mi 

> On Tue, Apr 25, 2023, 9:46 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> ----- Original Message -----
>> > From: "-" < [ mailto:liangchenblue at gmail.com | liangchenblue at gmail.com ] >
>> > To: [ mailto:valhalla-dev at openjdk.org | valhalla-dev at openjdk.org ]
>> > Sent: Tuesday, April 25, 2023 3:38:20 PM
>> > Subject: Reference pointers in compact value objects (primitive classes)

>> > Hello,
>> > I just wonder if nullable reference pointers can be part of compact
>> > value objects.

>> It depends if it's on the stack or on the heap.
>> On stack, a nullable reference to a value class if fully scalarized.
>> On heap, a nullable reference is not flattened, non null reference of value
>> class with a default instance are flattened.

>> On stack, declaring a class as a value class is enough
>> value record Point (int x, int y) {}

>> On heap, the value class also need a default constructor
>> value record Point (int x, int y) {
>> default Point(); // the default value is not null but Point(0,0)
>> }

>> and when used, a field has to declare that the field is not nullable using '!'
>> record Rectangle(Point! topLeft, Point! bottonRight) { }


>> > For instance, in the Classfile API, there is StackMapGenerator.Type, a
>> > record with (int type, ClassDesc reference, int bci). The default
>> > state (0, null, 0) is valid and a desirable default (0 type means
>> > top-type). If the ClassDesc field can be part of the compact
>> > representation, then the whole structure can be optimized, which looks
>> > promising to me.

>> Most values of the ClassFile API are values on stack so they should be
>> scalarized.
>> Note that, this is not yet true, currently a switch on a sealed interface forces
>> the rematerialization.


>> > Meanwhile, I have another question about nullable object
>> > representation in value classes: Suppose we have
>> > Optional<Optional<Optional<String>>>, what will the representation be?
>> > How will we distinguish Optional.empty() with
>> > Optional.of(Optional.empty())?

>> Let suppose that Optional is declared with a default instance like this
>> value class Optional<T> {
>> private final T value;

>> default Optional();
>> ...
>> }

>> Then you need a '!' to ask for flattening, so Optional<Optional!<String>>

>> Now to answer to your question, the VM tracks the class (here Optional is
>> specialized class), so even if the memory layout is the same between
>> Optional<String> and Optional<Optional!<String>>, the specialized classes
>> (sometimes also called the species) at runtime are not the same.


>> > Thanks,
>> > Chen Liang

>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230425/ed541858/attachment-0001.htm>

From thartmann at openjdk.org  Thu Apr 27 15:53:23 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 27 Apr 2023 15:53:23 GMT
Subject: [lworld] RFR: 8306986: [lworld] C2 compilation fails with assert
 "Should have been buffered"
Message-ID: <mjYHjlgDyN2rnKpuuYAX2HyqbSTtw8dnYW9alFmbwRI=.103fe205-982f-4429-90c6-cf80389cc6fb@github.com>

An assert failed because C2 was not able to prove that an inline type was always buffered. I replaced the hacky `InlineTypeNode::_is_buffered` field by a proper node input to propagate the allocation state through C2 IR. We need it in addition to the oop input because for a `null` the oop input is `null` but the node should still be treated as buffered. Reviving my prototype test generator, I found some tests that trigger two too strong asserts. I added the tests and removed the asserts.

Best regards,
Tobias

-------------

Commit messages:
 - 8306986: [lworld] C2 compilation fails with assert "Should have been buffered"

Changes: https://git.openjdk.org/valhalla/pull/844/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=844&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306986
  Stats: 142 lines in 7 files changed: 72 ins; 28 del; 42 mod
  Patch: https://git.openjdk.org/valhalla/pull/844.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/844/head:pull/844

PR: https://git.openjdk.org/valhalla/pull/844

From thartmann at openjdk.org  Fri Apr 28 06:27:29 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 28 Apr 2023 06:27:29 GMT
Subject: [lworld] Integrated: 8306986: [lworld] C2 compilation fails with
 assert "Should have been buffered"
In-Reply-To: <mjYHjlgDyN2rnKpuuYAX2HyqbSTtw8dnYW9alFmbwRI=.103fe205-982f-4429-90c6-cf80389cc6fb@github.com>
References: <mjYHjlgDyN2rnKpuuYAX2HyqbSTtw8dnYW9alFmbwRI=.103fe205-982f-4429-90c6-cf80389cc6fb@github.com>
Message-ID: <-G76aDGI-yXZkcGT6CfUzUof0peFlN_C9FemPnpQyms=.cfc0bc4a-2c2c-4271-9357-5c51624c1d16@github.com>

On Thu, 27 Apr 2023 15:39:36 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> An assert failed because C2 was not able to prove that an inline type was always buffered. I replaced the hacky `InlineTypeNode::_is_buffered` field by a proper node input to propagate the allocation state through C2 IR. We need it in addition to the oop input because for a `null` the oop input is `null` but the node should still be treated as buffered. Reviving my prototype test generator, I found some tests that trigger two too strong asserts. I added the tests and removed the asserts.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 131a3cee
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/131a3cee543eadb6c992570dd6e3b5ee61f7860e
Stats:     142 lines in 7 files changed: 72 ins; 28 del; 42 mod

8306986: [lworld] C2 compilation fails with assert "Should have been buffered"

-------------

PR: https://git.openjdk.org/valhalla/pull/844

From jbhateja at openjdk.org  Fri Apr 28 17:22:23 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 28 Apr 2023 17:22:23 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v11]
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <f5Vnx8TPw4p8atdWXU2MH40RIjeOeI8NWQxDKub942s=.45b5b7db-2293-4807-b934-9526050f55d7@github.com>

> Please find below the summary of changes included with the patch:
>   
> a) _ci Model:_
>    oops model creates separate fieldDescriptor/FieldInfo for each scalar field of a multifield bundle, root field is marked as multifield_base and non -  root (synthetic) fileds carry a multifield flag. To ease vector IR construction ci only exposes base multifield and ciType holding bundle size to compilers.
> 
> b) _C1 compiler:_
>    Special handling to copy entire multifield bundle during withfield bytecode processing.
> 
> c) _C2 compiler:_
>    VectorBox becomes a derivative of InlineType IR node, changes in vector box/unbox expansions. Preventing scalarization of Vector arguments and return values.
> 
> d) _Runtime:_
>    Changes in object re-construction during deoptimization since now concrete vectors have multifield based payloads. Payload (VectorPayloadMF) is a primitive class object which gets fully flattened within its parent/holding instance i.e. a concrete vector, special handling has been added for non-flattened case where payload is allocated over heap and concrete vector payload field is assigned its reference.
> 
> e) Added type specific multifield payloads to ease vector IR creation by C2, this will ensure bundle type and C2 IR type are compatible.               
> 
> Scope of current changes is limited to Vector types only, shuffles and masks are still backed by array based payloads. This PoC patch has been validated over vector only tests. More robust validation will be done in due course.
> 
> More information can be found at following link
> [https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx](https://cr.openjdk.org/~jbhateja/vectorIntrinsics/Valhalla/lworld%2Bvector.pptx)
> 
> Please share your feedback and suggestions.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Few fixes for failing vector API regression.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/23fa5745..638959bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=10
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=833&range=09-10

  Stats: 16 lines in 2 files changed: 16 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/833.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/833/head:pull/833

PR: https://git.openjdk.org/valhalla/pull/833

From davidalayachew at gmail.com  Sat Apr 29 03:55:22 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 28 Apr 2023 23:55:22 -0400
Subject: Question about testing preview features
Message-ID: <CAA9v-_N6Tq4gmrcgss_7g84Ns1GZh9d+vzBuagExRVavwQFwfQ@mail.gmail.com>

Hello,

I saw that build 20 of JDK 21 was just released [1]. In it, there are the
Sequenced Collections changes, some Loom changes, and more.

I want to understand the following.

* Where do we go to see when a feature has been merged into their
respective repository (for example, Sequenced Collections into
openjdk/amber)? The JDK Bug System?

* Is there a gap between when a feature is merged into the respective
repository vs the openjdk/jdk?

* Where do we go to see when a feature has been merged into the openjdk/jdk?

The reason I ask all of these questions is because I recently started
building Amber, Loom, and Valhalla from source. It is not easy, and I see
failed tests when I finish, so I feel like I am doing it wrong. And more
importantly, it takes a very long time, even building all 3 concurrently,
to get the newest changes on my system.

In short, if the latest build of the openjdk/jdk is going to contain all
the newest features, then I am not sure that spending 4 hours of my day
waiting for 3 repos to build makes sense compared to just spending 10
minutes downloading just the 1, unpacking it, then pointing my variables to
it.

So, I guess a final question would be, what benefit is there in building
from source? I want to test these features and contribute, so is there some
form of contribution that I am able to provide building from source that I
would not be able to provide if I just downloaded the latest build and
started using it?

Thank you all for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230428/16a0f1db/attachment-0001.htm>

From davidalayachew at gmail.com  Sat Apr 29 03:56:25 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 28 Apr 2023 23:56:25 -0400
Subject: Question about testing preview features
In-Reply-To: <CAA9v-_N6Tq4gmrcgss_7g84Ns1GZh9d+vzBuagExRVavwQFwfQ@mail.gmail.com>
References: <CAA9v-_N6Tq4gmrcgss_7g84Ns1GZh9d+vzBuagExRVavwQFwfQ@mail.gmail.com>
Message-ID: <CAA9v-_Nh_zPo_ny4+QkdBB9=7gF4Un17JfotOFL+34D31s+=og@mail.gmail.com>

Whoops, forgot the link to build 20 of JDK 21. Here it is.

[1]=https://jdk.java.net/21/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230428/7ecf1804/attachment.htm>