From jbhateja at openjdk.org  Tue May  2 05:05:42 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 2 May 2023 05:05:42 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v11]
In-Reply-To: <TUvnjh4kmNo_PWsTmTvzocSQ1ZSEbHaT4F0S1pvGbvE=.5cab1e4b-92a9-4efb-b37b-fc26d6b35025@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>
 <TUvnjh4kmNo_PWsTmTvzocSQ1ZSEbHaT4F0S1pvGbvE=.5cab1e4b-92a9-4efb-b37b-fc26d6b35025@github.com>
Message-ID: <zNmh9o2QVw9QfwtEeoUHy47JjLbcgLtNmL_oFg2Qvrw=.ae72c0c0-f175-40fb-8070-487e24d483ad@github.com>

On Sun, 23 Apr 2023 08:03:00 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Few fixes for failing vector API regression.
>
> 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?

Payloads are primitive type objects of VectorPayloadMF* classes, by default should be flattened in the containing object i.e. container object size will take into account flattened fields sizes, but flattening happens under the influence of InlineFieldMaxFlatSize runtime flag, above code handles non-flattened case.

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

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


From jbhateja at openjdk.org  Tue May  2 05:17:42 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 2 May 2023 05:17:42 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v7]
In-Reply-To: <dxDHVWHnvlFISssCHLCkqLb1pO67EwflpWJAsGIOggQ=.3bc7dbf6-272c-4ac5-934e-af0bfd7e2f75@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <2gO4ioPnyK0ya6aCMBnRL8nWXhmkKJyirJdo1inii4s=.41ad7b82-dbba-40e6-b182-14b500627d3c@github.com>
 <dxDHVWHnvlFISssCHLCkqLb1pO67EwflpWJAsGIOggQ=.3bc7dbf6-272c-4ac5-934e-af0bfd7e2f75@github.com>
Message-ID: <mT3Q7wjQOcQSmau7y-IxMDxZ6MQPkRkiFWGgwH6170g=.e0b3fe45-9a0d-4545-9157-758d3bd82f0c@github.com>

On Sun, 23 Apr 2023 08:19:30 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> 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?

Current structure exactly comply with Java class definition, Box classes encapsulate primitive class fields. Existing valhalla routines for buffering and IR creation e.g. _make_from_oop_ etc are all recursive in nature and create an InlineTypeNode for every primitive class object field.

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

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


From jbhateja at openjdk.org  Tue May  2 05:44:34 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 2 May 2023 05:44:34 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v12]
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: <zUadIVuTa-nia8tq8kOpeswNMGbsAZBQLVO26QqKK4Q=.1f9acd56-14b6-4def-960e-063ec601c187@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/638959bb..e79c0a76

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

  Stats: 15 lines in 4 files changed: 0 ins; 0 del; 15 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  Wed May  3 21:40:19 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 3 May 2023 17:40:19 -0400
Subject: What is the difference between Inlining vs Heap Flattening?
In-Reply-To: <CAA9v-_POF_ss_NOq=shvpwhmz7ZUrLWJvYq9wSNCsnrE11tSng@mail.gmail.com>
References: <CAA9v-_POF_ss_NOq=shvpwhmz7ZUrLWJvYq9wSNCsnrE11tSng@mail.gmail.com>
Message-ID: <CAA9v-_N-_U8i2KFZmw3e2ONGvoOmR-f0RmV51aJ5OHOcbji5Ug@mail.gmail.com>

Hello Valhalla Dev Team,

(Resending since the first attempt didn't seem to go through)

I saw the most recent update to JEP 401, and I just wanted to understand
what the difference is between Inlining and Heap Flattening. I have a
nebulous understanding of both, and I think Heap Flattening is better than
inlining, but I don't know if they are concepts that overlap, or are
entirely orthogonal to each other. Google wasn't much help.

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

From jbhateja at openjdk.org  Thu May  4 06:52:35 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 4 May 2023 06:52:35 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
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: <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@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:

  Handling multifield access through Unsafe.get API, some more cleanups.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/e79c0a76..a5d0e150

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

  Stats: 40 lines in 7 files changed: 24 ins; 4 del; 12 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  Fri May  5 06:47:42 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 5 May 2023 06:47:42 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <zNmh9o2QVw9QfwtEeoUHy47JjLbcgLtNmL_oFg2Qvrw=.ae72c0c0-f175-40fb-8070-487e24d483ad@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <y4fFcBvlWKmQabSkgu6ycwDlqAmTAEsOms3CBgUuZx0=.763bd992-ec85-47c3-86a4-14c016d662e1@github.com>
 <TUvnjh4kmNo_PWsTmTvzocSQ1ZSEbHaT4F0S1pvGbvE=.5cab1e4b-92a9-4efb-b37b-fc26d6b35025@github.com>
 <zNmh9o2QVw9QfwtEeoUHy47JjLbcgLtNmL_oFg2Qvrw=.ae72c0c0-f175-40fb-8070-487e24d483ad@github.com>
Message-ID: <M4hJcsG6Fz8GByJmFcUKzioRyzSDLETxfHFOgC77obI=.36524efd-d370-41ff-ab79-746413ba8a17@github.com>

On Tue, 2 May 2023 05:01:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> 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?
>
> Payloads are primitive type objects of VectorPayloadMF* classes, by default should be flattened in the containing object i.e. container object size will take into account flattened fields sizes, but flattening happens under the influence of InlineFieldMaxFlatSize runtime flag, above code handles non-flattened case.

Yes, the non-flattened case may exist. What I mean is when handling the non-flattened payloads, should a buffer be allocated for it as a instance like before?

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

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


From vlivanov at openjdk.org  Sat May  6 01:07:42 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 6 May 2023 01:07:42 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
Message-ID: <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>

On Thu, 4 May 2023 06:52:35 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:
> 
>   Handling multifield access through Unsafe.get API, some more cleanups.

Impressive work, Jatin!

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1189:

> 1187:     movptr(rscratch1, rax);
> 1188:     // Skip scalarization for vector value objects (concrete vectors and payloads).
> 1189:     super_call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::is_vector_value_instance), rdi);

I'm curious what's the current way to disable scalarization for return values of primitive types other than vector. Or do all primitive classes unconditionally scalarized irrespective of how many elements they comprise?

It makes sense to introduce a flag on a Klass which signals when return value scalarization should be turned off (unless there's already such a flag present).

I see `InlineKlass::can_be_returned_as_fields()` but don't fully understand how it interacts with interpreter.

src/hotspot/share/c1/c1_GraphBuilder.cpp line 1866:

> 1864:   for (int i = 0; i < vk->nof_nonstatic_fields(); i++) {
> 1865:     ciField* inner_field = vk->nonstatic_field_at(i);
> 1866:     for (int j = 0, sec_offset = 0; j < inner_field->secondary_fields_count(); j++) {

Does it make sense to expose through CI a flat view over all fields which filters out multifields? (Also, relates to my comment later about aliasing in C2).

src/hotspot/share/ci/ciField.hpp line 112:

> 110:   ciType* type() { return (_type == NULL) ? compute_type() : _type; }
> 111: 
> 112:   bool is_multifield() { return _is_multifield; }

I'm concerned about how multi-field and the fields it consists of interact at runtime and affect C2 alias analysis which is offset-based. 

The scenario I'm specifically concerned about is when vector and scalar accesses are mixed. Is it possible when Unsafe API is used? 

I'd prefer to see CI to expose either a single multifield (for C2 w/ proper vector support) or a pack of scalar fields (for C1 or C2 w/o proper vector support), but not both at the same time. I believe C1 doesn't care about multifields while C2 should not care about scalar elements when vectors of proper size are supported.

src/hotspot/share/ci/ciInlineKlass.cpp line 100:

> 98: // Can this inline type be returned as multiple values?
> 99: bool ciInlineKlass::can_be_returned_as_fields() const {
> 100:   GUARDED_VM_ENTRY(return !VectorSupport::skip_value_scalarization(const_cast<ciInlineKlass*>(this)) && to_InlineKlass()->can_be_returned_as_fields();)

Why not make vector-specific check a part of `InlineKlass::can_be_returned_as_fields()`?

src/hotspot/share/opto/compile.cpp line 2770:

> 2768:     TracePhase tp("", &timers[_t_vector]);
> 2769:     PhaseVector pv(igvn);
> 2770:     pv.optimize_vector_boxes();

`PhaseVector` does perform `PhaseRemoveUseless` (as part of `PhaseVector::do_cleanup()`). 

How does it interact with `remove_root_to_sfpts_edges` happening earlier:

  // Now that all inlining is over and no PhaseRemoveUseless will run, cut edge from root to loop
  // safepoints
  remove_root_to_sfpts_edges(igvn);

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

> 215:         int off   = i % VMRegImpl::stack_slot_size;
> 216:         address elem_addr = reg_map->location(vreg, vslot) + off; // assumes little endian element order
> 217:         obj->byte_field_put(ffo + i, *(jbyte*)elem_addr);

It would be nicer to iterate over secondary fields of the multifield and copy one field at a time (as `init_payload_element` does for primitive arrays). But it's also fine to copy byte-by-byte for now.

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

> 284: }
> 285: 
> 286: InstanceKlass* VectorSupport::get_vector_payload_klass(BasicType elem_bt, int num_elem) {

Alternatively, it could be implemented as a class lookup by name. 

It is fine for now, but eventually I'd like to get rid of `vmSymbols::vector_VectorPayloadMF*_signature()` and `vector_VectorPayloadMF*_klass` and use only `VectorSupport.VectorPayloadMF` to mark classes which need special handling. 

Original implementation requires subclasses to declare 2 static fields which are used by `klass2length` and `klass2bt` queries. Since typed vector classes declare a field of primitive type, it can be used as the source of information now.

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

> 401:   fieldDescriptor fd;
> 402:   int elem_size = type2aelembytes(elem_bt);
> 403:   Symbol* payload_sig = VectorSupport::get_vector_payload_field_signature(elem_bt, num_elem);

Alternatively, you could derive that information from `payload` field. Would it also make `klass2length()` and `klass2bt()` queries (and relevant static final fields on Java side) obsolete?

src/hotspot/share/prims/vectorSupport.hpp line 34:

> 32: #include "runtime/registerMap.hpp"
> 33: #include "utilities/exceptions.hpp"
> 34: #include "ci/ciKlass.hpp"

`prims/vectorSupport.hpp` not the right place for CI-related queries.

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

> 1144:         if (EnableVectorSupport && VectorSupport::is_vector(ik)) {
> 1145:           obj = VectorSupport::allocate_vector(ik, fr, reg_map, sv, THREAD);
> 1146:         } else if (EnableVectorSupport && VectorSupport::is_vector_payload_mf(ik)) {

Why do you need to handle both cases now? Anything special needed for `VectorSupport::is_vector()` case?

src/hotspot/share/runtime/sharedRuntime.cpp line 642:

> 640: 
> 641: JRT_LEAF(jint, SharedRuntime::is_vector_value_instance(InlineKlass* klass))
> 642:   return (jint)VectorSupport::skip_value_scalarization(klass);

The naming is confusing here: `is_vector_value_instance` wraps `skip_value_scalarization`.  I suggest to use `is_vector_value_instance` uniformly.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 75:

> 73:     }
> 74: 
> 75:     static final Byte128Vector ZERO = new Byte128Vector(VectorPayloadMF.createVectPayloadInstance(byte.class, 16));

You could allocate `VectorSupport.VectorPayloadMF128B` directly or just use default value. 

Not sure `VectorPayloadMF.createVectPayloadInstance()` makes the intention clearer.

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

PR Review: https://git.openjdk.org/valhalla/pull/833#pullrequestreview-1415559103
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186570892
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186573143
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186572111
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186573359
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186573836
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186569846
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186568598
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186567323
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186566286
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186565115
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186555380
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186564209


From vlivanov at openjdk.org  Sat May  6 01:07:43 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 6 May 2023 01:07:43 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <OsWO9YdfRmIYCqUL2zMwhSYXtzONUzn0mJygzbJM1m0=.e6ca4329-a2c1-4ab3-ae8c-7764e341c5bb@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <fjW5fH7SwP7hFH0KtzyKiyBBRiuRP-m8Cybs9bDOS6w=.d98b7790-a8ff-4d70-bbab-37b601e67639@github.com>
 <jvGiavQyIoXXJFk5PhP9PWdxv0bcaCdiqfqp5cA8CLM=.d262ba20-8861-40e2-b950-41308b887e84@github.com>
 <OsWO9YdfRmIYCqUL2zMwhSYXtzONUzn0mJygzbJM1m0=.e6ca4329-a2c1-4ab3-ae8c-7764e341c5bb@github.com>
Message-ID: <EGgWTQmTu4JWJuMi9DxtSTJD2kzWoSPB77wrARhBDH8=.ec0bb8dd-89c9-4b50-b00f-c7fe57a08f33@github.com>

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

>> This is done to streamline vector IR type creation and prevent adding special handling in compiler to append a reinterpret IR post LoadVector. I wanted to prevent introducing any special handling in C2 which does not comply with Java code e.g. Float256Vector is backed by VectorPayload256MF @multifield(value = 64) byte mfield;.
>
> OK, make sense to me. Per my understanding, it currently only has `load/store/zero` vector operations for the multi-fields, right? Hence always using byte vector operations may also work well to me. But making the vector type accurate with the concrete vector class type is better for compiler.  So this change is fine to me. Thanks!

It looks fine for now. In the longer term, it's highly desirable to converge to a set of canonical classes which represent "super-long" primitives (>64 bit in size) which JVM knows about and natively support.

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

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


From vlivanov at openjdk.org  Sat May  6 01:07:43 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 6 May 2023 01:07:43 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
Message-ID: <2YMyxdM8DXhGaPEh6zwhpgJ6c_NEIHsb83DPb60OFfw=.46d8148b-2f5e-4918-b581-8b14bf0bd1a6@github.com>

On Sat, 6 May 2023 00:10:38 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handling multifield access through Unsafe.get API, some more cleanups.
>
> src/hotspot/share/runtime/deoptimization.cpp line 1146:
> 
>> 1144:         if (EnableVectorSupport && VectorSupport::is_vector(ik)) {
>> 1145:           obj = VectorSupport::allocate_vector(ik, fr, reg_map, sv, THREAD);
>> 1146:         } else if (EnableVectorSupport && VectorSupport::is_vector_payload_mf(ik)) {
> 
> Why do you need to handle both cases now? Anything special needed for `VectorSupport::is_vector()` case?

Another question: is there a lurking problem in the original implementation? Can a backing array leak into debug info, so reallocation has to handle it? I believe it's not the case since vector scalarization logic relies on typed vector box to pass type information, but want to double-check with you.

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

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


From xgong at openjdk.org  Sat May  6 09:33:39 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sat, 6 May 2023 09:33:39 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
Message-ID: <HcqmrjiSNwYYslvI8yO7Rvv-tx594wkTaXousNw-IrE=.4273bc5b-f97a-4325-af58-7292944e8234@github.com>

On Thu, 4 May 2023 06:52:35 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:
> 
>   Handling multifield access through Unsafe.get API, some more cleanups.

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

> 324: }
> 325: 
> 326: Node* PhaseVector::expand_vbox_node_helper(Node* vec_box,

The first VectorBox argument is not used and can be removed, right?

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

> 549:                                           num_elem,
> 550:                                           bt);
> 551:       vec_val_load = gvn.transform(vec_val_load);

Can simply use "vec_unbox->obj()->as_as_InlineType()->field_value(0)" ?

src/hotspot/share/opto/vectornode.cpp line 1642:

> 1640:   // a VectorBox but we still need to traverse back through chain of cast nodes
> 1641:   // to get to the VectorBox.
> 1642:   if (n->is_InlineType() &&

Since compiler will generate an InlineTypeNode for any value/primitive instance, is there any other cases that the input of `VectorUnbox` is not an `InlineTypeNode` ?  If not, maybe we could remove this condition and add an assertion instead?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186667820
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186670541
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1186670350


From xgong at openjdk.org  Sat May  6 10:00:40 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sat, 6 May 2023 10:00:40 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v11]
In-Reply-To: <f5Vnx8TPw4p8atdWXU2MH40RIjeOeI8NWQxDKub942s=.45b5b7db-2293-4807-b934-9526050f55d7@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <f5Vnx8TPw4p8atdWXU2MH40RIjeOeI8NWQxDKub942s=.45b5b7db-2293-4807-b934-9526050f55d7@github.com>
Message-ID: <CuHw_PUiGB5cq1MRglKADuWGQJ7Oc1SF3x6Wlxl9UPo=.1ca88741-58d4-4396-baa1-b5f3148f5171@github.com>

On Fri, 28 Apr 2023 17:22:23 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:
> 
>   Few fixes for failing vector API regression.

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

> 438:         if (field->is_multifield_base() &&
> 439:           Matcher::match_rule_supported_vector(VectorNode::replicate_opcode(bt), vec_len, bt)) {
> 440:           value = kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, Type::get_const_type(field->type()), false));

If the oop is not the default oop, the multifield values maybe different from the multifield base, right?

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

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


From jbhateja at openjdk.org  Tue May  9 19:08:05 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 May 2023 19:08:05 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
Message-ID: <EnesnfEekLj_szMfNrGwmBFPWssBR1j4mN9CGlzRhF4=.c49b33c2-7010-4a01-9fba-7a7e411595e7@github.com>

On Sat, 6 May 2023 00:43:29 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I'm curious what's the current way to disable scalarization for return values of primitive types other than vector. Or do all primitive classes unconditionally scalarized irrespective of how many elements they comprise?
> 
Currently entire handling operates under two global flags `InlineTypeReturnedAsFields` and `InlineTypePassFieldsAsArgs`
I introduced special handling to prevent scalarization for vectors in `InlineKlass::can_be_passed_as_fields` and `InlineKlass::can_be_returned_as_fields`.

> It makes sense to introduce a flag on a Klass which signals when return value scalarization should be turned off (unless there's already such a flag present).

Agree, I can handle this on lworld branch since it will be good to enhance core infrastructure to disable scalarization per class basis even though value type semantics always enforces scalarization, vector values are special since multifield needs to be passed using vector and we do not support a mixed GPR+VECTOR calling convention currently.
 
> 
> I see `InlineKlass::can_be_returned_as_fields()` but don't fully understand how it interacts with interpreter.

InlineKlass contains unpack / pack handlers , interpreter and c1 side handling directly operate under influence of above mentioned global flags. There is no mechanism to prevent scalarization for value objects currently, apart from c2 all the other execution engines uses pack/unpack handlers to pass / receive a value object.

> Does it make sense to expose through CI a flat view over all fields which filters out multifields? (Also, relates to my comment later about aliasing in C2).

Currently, I create a hierarchical field structure with all synthetic multifield hidden beneath base multi-field and are exposed to C2 only if target does not support vector size to load multi-field.

> I'm concerned about how multi-field and the fields it consists of interact at runtime and affect C2 alias analysis which is offset-based.
> 

We always access multi-field through unsafe APIs, thus the alias are computed based on address calculation over payload class objects. Both payload (VectorPayloadMF*) and computed address are of TypeInstPtr type. This is different from regular array element update which gets captured in MemoryMergeNode at same alias index as of entire array.

> The scenario I'm specifically concerned about is when vector and scalar accesses are mixed. Is it possible when Unsafe API is used?
> 

Unsafe.put operate over buffered InlineTypeNodes followed by re-materialization of InlineTypeNode, and a Unsafe.get operation loads particular field from buffer, their effective addresses are computed with payload as the base field.  

> I'd prefer to see CI to expose either a single multifield (for C2 w/ proper vector support) or a pack of scalar fields (for C1 or C2 w/o proper vector support), but not both at the same time. I believe C1 doesn't care about multifields while C2 should not care about scalar elements when vectors of proper size are supported.

Yes, CI captures both base and synthetic multi-fields and expose the synthetic multi-field for scalar IR creation only if target does not support the vector size.

![image](https://github.com/openjdk/valhalla/assets/59989778/f5ac7bc0-8f03-4a19-8d57-5cb5329b62f5)

> src/hotspot/share/ci/ciInlineKlass.cpp line 100:
> 
>> 98: // Can this inline type be returned as multiple values?
>> 99: bool ciInlineKlass::can_be_returned_as_fields() const {
>> 100:   GUARDED_VM_ENTRY(return !VectorSupport::skip_value_scalarization(const_cast<ciInlineKlass*>(this)) && to_InlineKlass()->can_be_returned_as_fields();)
> 
> Why not make vector-specific check a part of `InlineKlass::can_be_returned_as_fields()`?

DONE

> src/hotspot/share/opto/compile.cpp line 2770:
> 
>> 2768:     TracePhase tp("", &timers[_t_vector]);
>> 2769:     PhaseVector pv(igvn);
>> 2770:     pv.optimize_vector_boxes();
> 
> `PhaseVector` does perform `PhaseRemoveUseless` (as part of `PhaseVector::do_cleanup()`). 
> 
> How does it interact with `remove_root_to_sfpts_edges` happening earlier:
> 
>   // Now that all inlining is over and no PhaseRemoveUseless will run, cut edge from root to loop
>   // safepoints
>   remove_root_to_sfpts_edges(igvn);

Fixed, it was an left behind artifact of a previous check-in, its not moved after PhaseVector completion like in current implementation.

> src/hotspot/share/prims/vectorSupport.cpp line 286:
> 
>> 284: }
>> 285: 
>> 286: InstanceKlass* VectorSupport::get_vector_payload_klass(BasicType elem_bt, int num_elem) {
> 
> Alternatively, it could be implemented as a class lookup by name. 
> 
> It is fine for now, but eventually I'd like to get rid of `vmSymbols::vector_VectorPayloadMF*_signature()` and `vector_VectorPayloadMF*_klass` and use only `VectorSupport.VectorPayloadMF` to mark classes which need special handling. 
> 
> Original implementation requires subclasses to declare 2 static fields which are used by `klass2length` and `klass2bt` queries. Since typed vector classes declare a field of primitive type, it can be used as the source of information now.

I thought about it but any lookup by name may be costly. But we can refine as suggested.

> Alternatively, you could derive that information from `payload` field. Would it also make `klass2length()` and `klass2bt()` queries (and relevant static final fields on Java side) obsolete?

find_field need field signature to query the fieldDescriptor.   payload is no longer a primitive array but a primitive class instance, we still need pass klass2length() and klass2bt() information to payload signature factory method.

> src/hotspot/share/runtime/sharedRuntime.cpp line 642:
> 
>> 640: 
>> 641: JRT_LEAF(jint, SharedRuntime::is_vector_value_instance(InlineKlass* klass))
>> 642:   return (jint)VectorSupport::skip_value_scalarization(klass);
> 
> The naming is confusing here: `is_vector_value_instance` wraps `skip_value_scalarization`.  I suggest to use `is_vector_value_instance` uniformly.

DONE

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025540
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025720
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025613
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025791
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025872
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025435
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025348
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189025000


From jbhateja at openjdk.org  Tue May  9 19:08:09 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 May 2023 19:08:09 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v11]
In-Reply-To: <CuHw_PUiGB5cq1MRglKADuWGQJ7Oc1SF3x6Wlxl9UPo=.1ca88741-58d4-4396-baa1-b5f3148f5171@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <f5Vnx8TPw4p8atdWXU2MH40RIjeOeI8NWQxDKub942s=.45b5b7db-2293-4807-b934-9526050f55d7@github.com>
 <CuHw_PUiGB5cq1MRglKADuWGQJ7Oc1SF3x6Wlxl9UPo=.1ca88741-58d4-4396-baa1-b5f3148f5171@github.com>
Message-ID: <LDBJPKqJkELSxhp5f9mrcy8zgFxt7Ie5S6lIODyCWkw=.2e837f7a-4bd4-4568-aec8-6cdedf62d2bb@github.com>

On Sat, 6 May 2023 09:57:09 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Few fixes for failing vector API regression.
>
> src/hotspot/share/opto/inlinetypenode.cpp line 440:
> 
>> 438:         if (field->is_multifield_base() &&
>> 439:           Matcher::match_rule_supported_vector(VectorNode::replicate_opcode(bt), vec_len, bt)) {
>> 440:           value = kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, Type::get_const_type(field->type()), false));
> 
> If the oop is not the default oop, the multifield values maybe different from the multifield base, right?

Correct, its handles loading a multi-field value from a constant oop associated with payload which is created only when payload class is uninitialized. 

https://github.com/openjdk/valhalla/pull/833/files#diff-ba9e2d10a50a01316946660ec9f68321eb864fd9c815616c10abbec39360efe5R1692

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

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


From jbhateja at openjdk.org  Tue May  9 19:08:13 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 May 2023 19:08:13 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <HcqmrjiSNwYYslvI8yO7Rvv-tx594wkTaXousNw-IrE=.4273bc5b-f97a-4325-af58-7292944e8234@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <HcqmrjiSNwYYslvI8yO7Rvv-tx594wkTaXousNw-IrE=.4273bc5b-f97a-4325-af58-7292944e8234@github.com>
Message-ID: <VH6KsxgmRiczmp_1z6dAQ4PqnapGeSHxzR8mEk7s5aA=.1cb0cac6-292d-451a-b819-2a1c4d72acca@github.com>

On Sat, 6 May 2023 09:30:08 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handling multifield access through Unsafe.get API, some more cleanups.
>
> src/hotspot/share/opto/vector.cpp line 551:
> 
>> 549:                                           num_elem,
>> 550:                                           bt);
>> 551:       vec_val_load = gvn.transform(vec_val_load);
> 
> Can simply use "vec_unbox->obj()->as_InlineType()->field_value(0)" ?

This is a fallback code, which ideally should never get executed, i introduced it in first version of patch, but its not needed anymore.

> src/hotspot/share/opto/vectornode.cpp line 1642:
> 
>> 1640:   // a VectorBox but we still need to traverse back through chain of cast nodes
>> 1641:   // to get to the VectorBox.
>> 1642:   if (n->is_InlineType() &&
> 
> Since compiler will generate an InlineTypeNode for any value/primitive instance, is there any other cases that the input of `VectorUnbox` is not an `InlineTypeNode` ?  If not, maybe we could remove this condition and add an assertion instead?

Correct, added assertion.

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

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


From jbhateja at openjdk.org  Tue May  9 19:08:16 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 May 2023 19:08:16 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <2YMyxdM8DXhGaPEh6zwhpgJ6c_NEIHsb83DPb60OFfw=.46d8148b-2f5e-4918-b581-8b14bf0bd1a6@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
 <2YMyxdM8DXhGaPEh6zwhpgJ6c_NEIHsb83DPb60OFfw=.46d8148b-2f5e-4918-b581-8b14bf0bd1a6@github.com>
Message-ID: <mrbHynNfKMbjgo_paJqODuA9CYUY9C8-OsAvbU4Fso4=.19fb36fd-2ba8-4cd9-a09e-c4f36bb85ae3@github.com>

On Sat, 6 May 2023 00:15:33 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/runtime/deoptimization.cpp line 1146:
>> 
>>> 1144:         if (EnableVectorSupport && VectorSupport::is_vector(ik)) {
>>> 1145:           obj = VectorSupport::allocate_vector(ik, fr, reg_map, sv, THREAD);
>>> 1146:         } else if (EnableVectorSupport && VectorSupport::is_vector_payload_mf(ik)) {
>> 
>> Why do you need to handle both cases now? Anything special needed for `VectorSupport::is_vector()` case?
>
> Another question: is there a lurking problem in the original implementation? Can a backing array leak into debug info, so reallocation has to handle it? I believe it's not the case since vector scalarization logic relies on typed vector box to pass type information, but want to double-check with you.

> Why do you need to handle both cases now? Anything special needed for `VectorSupport::is_vector()` case?

Both VectorSupportMF* and its containing VectorBoxes are inline types (primitive / value classes) and there is lot of surface area involving Unsafe APIs in fallback implementation where we create a payload and update its fields before wrapping it into a box, this handling makes sure to re-materialize payloads in case de-optimization triggers before vector box creation. 

> Another question: is there a lurking problem in the original implementation? Can a backing array leak into debug info, so reallocation has to handle it? I believe it's not the case since vector scalarization logic relies on typed vector box to pass type information, but want to double-check with you.

Arrays [re-allocation](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1157)` / `[reassignment](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1572) is already handled during de-optimization, on a side note even escape analysis records the scalarized locations of small eliminated arrays whose size is less than EliminateAllocationArraySizeLimit since larger arrays are already allocated over heap. So existing stock implementation is already handling backing storage appropriately.

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

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


From jbhateja at openjdk.org  Tue May  9 19:13:25 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 May 2023 19:13:25 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
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: <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@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/a5d0e150..21bea77c

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

  Stats: 199 lines in 39 files changed: 23 ins; 74 del; 102 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  Tue May  9 19:13:52 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 9 May 2023 19:13:52 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
Message-ID: <nY43pBJMXGTuI7-om7NDnARvhq_StgGsWUbO4xJdQ0Q=.288f9937-c041-438b-993e-c16b8461e95c@github.com>

On Sat, 6 May 2023 01:04:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handling multifield access through Unsafe.get API, some more cleanups.
>
> Impressive work, Jatin!

Hi @iwanowww , @XiaohongGong , your comments have been addressed. Let me know if this is good to check-in as first version.

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

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


From xgong at openjdk.org  Wed May 10 02:00:44 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 02:00:44 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
Message-ID: <P001YkQgA6K2NikOnaG8lFML5Z7tnUF3EwpdgOpQZC8=.90c139b1-2705-4eaa-ae29-06fd3e634b66@github.com>

On Thu, 4 May 2023 06:52:35 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:
> 
>   Handling multifield access through Unsafe.get API, some more cleanups.

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

> 516: 
> 517:     Node* vec_val_load = get_loaded_payload(vec_unbox);
> 518: 

Maybe directly merge `get_loaded_payload` method with this method? Any other place that `get_loaded_payload` is used besides here?

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

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


From xgong at openjdk.org  Wed May 10 02:00:43 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 02:00:43 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
Message-ID: <utK9ZMX6Gg05tG1BItaIx86GZWKzKvnluC94KhHpGc8=.d70732c4-932e-47f3-bf35-b5c621b78879@github.com>

On Tue, 9 May 2023 19:13:25 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/opto/parse1.cpp line 924:

> 922:     kit.sync_jvms();
> 923:     Node* res = kit.argument(0);
> 924:     if (res->isa_InlineType() && VectorSupport::skip_value_scalarization(res->as_InlineType()->inline_klass()->get_InlineKlass())) {

I'm wondering if `tf()->returns_inline_type_as_fields()` in followed `else-if` branch has any connection with `ciInlineKlass::can_be_returned_as_fields()`.  If `ciInlineKlass::can_be_returned_as_fields()` can decide the result of `tf()->returns_inline_type_as_fields()`, then this special handling for bufferred `InlineTypeNode` can be removed like before?

src/hotspot/share/opto/vector.hpp line 32:

> 30: #include "opto/type.hpp"
> 31: #include "opto/vectornode.hpp"
> 32: #include "ci/ciKlass.hpp"

Style: please reorder this include file. Thanks!

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

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


From xgong at openjdk.org  Wed May 10 02:28:48 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 02:28:48 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
Message-ID: <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>

On Tue, 9 May 2023 19:13:25 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/ci/ciField.hpp line 192:

> 190:   bool is_null_free            () const { return _is_null_free; }
> 191: 
> 192: 

style: please remove this new blank line.

src/hotspot/share/classfile/vmClassMacros.hpp line 197:

> 195:   do_klass(vector_VectorPayloadMF_klass,                jdk_internal_vm_vector_VectorPayloadMF                ) \
> 196:   do_klass(vector_VectorPayloadMF64B_klass,              jdk_internal_vm_vector_VectorPayloadMF64B              ) \
> 197:   do_klass(vector_VectorPayloadMF128B_klass,             jdk_internal_vm_vector_VectorPayloadMF128B             ) \

Suggestion:

  do_klass(vector_VectorPayloadMF64B_klass,             jdk_internal_vm_vector_VectorPayloadMF64B             ) \
  do_klass(vector_VectorPayloadMF128B_klass,            jdk_internal_vm_vector_VectorPayloadMF128B            ) \

src/hotspot/share/classfile/vmSymbols.hpp line 124:

> 122:   template(mfield_name,                               "mfield")                                   \
> 123:   template(ETYPE_name,                                "ETYPE")                                    \
> 124:   template(VLENGTH_name,                              "VLENGTH")                                  \

style: suggest to align with line-120.

Suggestion:

  template(jdk_internal_vm_vector_VectorPayloadMF512D, "jdk/internal/vm/vector/VectorSupport$VectorPayloadMF512D") \
  template(payload_name,                               "payload")                                  \
  template(mfield_name,                                "mfield")                                   \
  template(ETYPE_name,                                 "ETYPE")                                    \
  template(VLENGTH_name,                               "VLENGTH")                                  \

src/hotspot/share/classfile/vmSymbols.hpp line 298:

> 296:   template(vector_VectorPayloadMF64B_signature,        "Qjdk/internal/vm/vector/VectorSupport$VectorPayloadMF64B;")  \
> 297:   template(vector_VectorPayloadMF128B_signature,       "Qjdk/internal/vm/vector/VectorSupport$VectorPayloadMF128B;") \
> 298:   template(vector_VectorPayloadMF256B_signature,       "Qjdk/internal/vm/vector/VectorSupport$VectorPayloadMF256B;") \

style: ditto, alignment please.

src/hotspot/share/opto/cfgnode.cpp line 2704:

> 2702:   ciInlineKlass* payload = vk->declared_nonstatic_field_at(0)->type()->as_inline_klass();
> 2703: 
> 2704:   Node* payload_oop = payload->is_initialized() ? InlineTypeNode::default_oop(*igvn, payload) : igvn->zerocon(T_PRIMITIVE_OBJECT);

`payload_oop` is not used and can be removed?

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

> 34: #include "opto/phaseX.hpp"
> 35: #include "opto/vectornode.hpp"
> 36: 

style: one more blank line.

src/hotspot/share/opto/inlinetypenode.hpp line 31:

> 29: #include "opto/loopnode.hpp"
> 30: #include "opto/node.hpp"
> 31: #include "opto/matcher.hpp"

style: include reorder

src/hotspot/share/opto/inlinetypenode.hpp line 61:

> 59:   void expand_input_edges(ciInlineKlass * vk);
> 60: 
> 61: 

style: two more blank lines

src/hotspot/share/opto/inlinetypenode.hpp line 127:

> 125:   bool          is_multifield_base(uint index) const;
> 126:   int           secondary_fields_count(uint index) const;
> 127:   bool          is_multifield() const;

`is_multifield()` is not implemented and used?

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

> 32: #include "opto/vector.hpp"
> 33: #include "utilities/macros.hpp"
> 34: #include "prims/vectorSupport.hpp"

style: include reorder

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

> 29: #include "opto/memnode.hpp"
> 30: #include "opto/node.hpp"
> 31: #include "opto/inlinetypenode.hpp"

ditto

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

> 27: #include "classfile/vmClasses.hpp"
> 28: #include "classfile/vmSymbols.hpp"
> 29: #include "classfile/vmClassMacros.hpp"

style: ditto

src/hotspot/share/runtime/fieldDescriptor.hpp line 98:

> 96:   inline jbyte multifield_index()        const;
> 97:   inline int secondary_fields_count(int base_idx) const;
> 98: 

style: one more blank line

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189281241
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189283354
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189283691
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189284324
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189285035
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189285461
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189286201
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189286327
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189287204
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189290492
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189291378
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189291604
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189291994


From xgong at openjdk.org  Wed May 10 02:28:48 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 02:28:48 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <fjW5fH7SwP7hFH0KtzyKiyBBRiuRP-m8Cybs9bDOS6w=.d98b7790-a8ff-4d70-bbab-37b601e67639@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <fjW5fH7SwP7hFH0KtzyKiyBBRiuRP-m8Cybs9bDOS6w=.d98b7790-a8ff-4d70-bbab-37b601e67639@github.com>
Message-ID: <mKE9KodPiqI-N063vLHo0MY1W3EMmCRpW4i0zXMArdo=.4f1bb2b9-ade4-46c2-bbba-615eda3ea014@github.com>

On Mon, 20 Mar 2023 07:21:00 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/vectornode.cpp line 861:
> 
>> 859:     return n->in(1)->bottom_type() == TypeF::ONE;
>> 860:   case Op_ReplicateD:
>> 861:     return n->in(1)->bottom_type() == TypeD::ONE;
> 
> `is_all_ones_vector` here means all bits are `1` (i.e. `-1` for integer types). So `TypeF::ONE` is not the right value here?

Missed this comment?

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

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


From xgong at openjdk.org  Wed May 10 02:31:47 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 02:31:47 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
Message-ID: <ljlMAELopaAao27beM95tdXhFJBuK3iH2yXCBV33iVI=.7eb67764-b763-4b0d-9973-ce496c5460ce@github.com>

On Sat, 6 May 2023 01:04:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Handling multifield access through Unsafe.get API, some more cleanups.
>
> Impressive work, Jatin!

> Hi @iwanowww , @XiaohongGong , your comments have been addressed. Let me know if this is good to check-in as first version.

Hi Jatin,

Thanks for your updating! The current version generally looks fine to me, just with some style issues and minor issues. Hope this patch could be in next. Thanks a lot!

Best Regards,
Xiaohong

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

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


From xgong at openjdk.org  Wed May 10 06:08:44 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 06:08:44 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
Message-ID: <TA2pJ8FKizhscfxWKuBTUOIiIoRCRNoW7YyV54S0vNk=.b8ea772f-47ee-49a9-a708-1f7d49c4ca36@github.com>

On Tue, 9 May 2023 19:13:25 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/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 198:

> 196:                     case 32: obj = new VectorPayloadMF256B(); break;
> 197:                     case 64: obj = new VectorPayloadMF512B(); break;
> 198:                     default: assert false : "Unhandled vector size";

We could return the new object directly.
Suggestion:

                    case  8: return new VectorPayloadMF64B();
                    case 16: return new VectorPayloadMF128B();
                    case 32: return new VectorPayloadMF256B();
                    case 64: return new VectorPayloadMF512B();
                    default: assert false : "Unhandled vector size";

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

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


From xgong at openjdk.org  Wed May 10 06:12:44 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 06:12:44 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
Message-ID: <hEJyUkLH6HMJxVGjzZaQiZNawIFk16GUFJPqwdGrIWc=.f3286207-13ca-41ed-b3bc-14f6ad1011d0@github.com>

On Tue, 9 May 2023 19:13:25 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/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 246:

> 244:         @ForceInline
> 245:         public static VectorPayloadMF createVectPayloadInstance(Class<?> elemType, int length) {
> 246:             return newInstanceFactory(elemType, length);

Any reason that we define two methods to new the payload instance? Can remove this and call `newInstanceFactory()` directly?

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

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


From xgong at openjdk.org  Wed May 10 06:20:43 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 06:20:43 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
Message-ID: <ZqQd564118O4_7iA5JNEfp_XBKqbDUa0Q3cwkwU0Avo=.cfd12e84-12d0-4c19-8a70-e56bd78a2d3e@github.com>

On Tue, 9 May 2023 19:13:25 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/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 457:

> 455:     public primitive static class VectorPayloadMF64L extends VectorPayloadMF {
> 456:         @MultiField(value = 1)
> 457:         long mfield = 0;

Can remove the MultiField annotation?

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

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


From xgong at openjdk.org  Wed May 10 07:58:52 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 07:58:52 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <EnesnfEekLj_szMfNrGwmBFPWssBR1j4mN9CGlzRhF4=.c49b33c2-7010-4a01-9fba-7a7e411595e7@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
 <EnesnfEekLj_szMfNrGwmBFPWssBR1j4mN9CGlzRhF4=.c49b33c2-7010-4a01-9fba-7a7e411595e7@github.com>
Message-ID: <Qzp0h8lHccMaAK3UdPqccS3uSs61BVcdZFetePb3-R8=.67185f3e-7c60-4fe1-8fd1-66bf35ca3c8c@github.com>

On Tue, 9 May 2023 19:03:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/compile.cpp line 2770:
>> 
>>> 2768:     TracePhase tp("", &timers[_t_vector]);
>>> 2769:     PhaseVector pv(igvn);
>>> 2770:     pv.optimize_vector_boxes();
>> 
>> `PhaseVector` does perform `PhaseRemoveUseless` (as part of `PhaseVector::do_cleanup()`). 
>> 
>> How does it interact with `remove_root_to_sfpts_edges` happening earlier:
>> 
>>   // Now that all inlining is over and no PhaseRemoveUseless will run, cut edge from root to loop
>>   // safepoints
>>   remove_root_to_sfpts_edges(igvn);
>
> Fixed, it was an left behind artifact of a previous check-in, its not moved after PhaseVector completion like in current implementation.

Why not handling the vector box optimizations before the `process_inline_types` like before? We can do the safepoint scalarize in `PhaseVector` for vector boxes, including the special handles for vector mask utility. Otherwise, we have to move the vector mask utility handling to `InlineTypeNode`, which looks weird. We can skip the vector boxes in `process_inline_types()`. Another benefit is most of the `VectorBoxNode` are eliminated before processing `InlineTypeNode`.

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

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


From jbhateja at openjdk.org  Wed May 10 09:20:47 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 May 2023 09:20:47 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>
Message-ID: <Bv8KI4b8T9seVVef3QX5rMG3XZFKMH2V1x-x3fSYWiE=.c015bae5-f90b-4fe9-b050-6e12be1fbb99@github.com>

On Wed, 10 May 2023 02:08:46 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/cfgnode.cpp line 2704:
> 
>> 2702:   ciInlineKlass* payload = vk->declared_nonstatic_field_at(0)->type()->as_inline_klass();
>> 2703: 
>> 2704:   Node* payload_oop = payload->is_initialized() ? InlineTypeNode::default_oop(*igvn, payload) : igvn->zerocon(T_PRIMITIVE_OBJECT);
> 
> `payload_oop` is not used and can be removed?

This is already handled within  _`make_uninitialized`_

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

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


From xgong at openjdk.org  Wed May 10 09:34:55 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 09:34:55 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <Bv8KI4b8T9seVVef3QX5rMG3XZFKMH2V1x-x3fSYWiE=.c015bae5-f90b-4fe9-b050-6e12be1fbb99@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>
 <Bv8KI4b8T9seVVef3QX5rMG3XZFKMH2V1x-x3fSYWiE=.c015bae5-f90b-4fe9-b050-6e12be1fbb99@github.com>
Message-ID: <uUcsI4B6lL-LICNiEQDnFU8OWfUFyMiCxtPQ-BWc_44=.d139221a-8276-432b-b48c-4938bb620036@github.com>

On Wed, 10 May 2023 09:17:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/cfgnode.cpp line 2704:
>> 
>>> 2702:   ciInlineKlass* payload = vk->declared_nonstatic_field_at(0)->type()->as_inline_klass();
>>> 2703: 
>>> 2704:   Node* payload_oop = payload->is_initialized() ? InlineTypeNode::default_oop(*igvn, payload) : igvn->zerocon(T_PRIMITIVE_OBJECT);
>> 
>> `payload_oop` is not used and can be removed?
>
> This is already handled within  _`make_uninitialized`_

Exactly right.

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

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


From jbhateja at openjdk.org  Wed May 10 10:00:50 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 May 2023 10:00:50 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>
Message-ID: <Uk9Ve0pZ2-xtohikEhSCNFJg5BwUqEs9Z5JF3ECMQ3k=.5a0742e0-7a0c-4437-96c7-0f9840e9a185@github.com>

On Wed, 10 May 2023 02:11:30 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/inlinetypenode.hpp line 31:
> 
>> 29: #include "opto/loopnode.hpp"
>> 30: #include "opto/node.hpp"
>> 31: #include "opto/matcher.hpp"
> 
> style: include reorder

I think we should run [IWYU](https://github.com/include-what-you-use/include-what-you-use ) on JVM code once , WDYT?

> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 246:
> 
>> 244:         @ForceInline
>> 245:         public static VectorPayloadMF createVectPayloadInstance(Class<?> elemType, int length) {
>> 246:             return newInstanceFactory(elemType, length);
> 
> Any reason that we define two methods to new the payload instance? Can remove this and call `newInstanceFactory()` directly?

Just to give meaningful name to wrapper, both are anyways annotated by @ForceInline hence will always get inlined in caller context.

> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 457:
> 
>> 455:     public primitive static class VectorPayloadMF64L extends VectorPayloadMF {
>> 456:         @MultiField(value = 1)
>> 457:         long mfield = 0;
> 
> Can remove the MultiField annotation?

Annotations are propagated to both oops and ci model, and we do special handlings for multifields.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189663894
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189667543
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1189667472


From xgong at openjdk.org  Wed May 10 10:04:54 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 10:04:54 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <Uk9Ve0pZ2-xtohikEhSCNFJg5BwUqEs9Z5JF3ECMQ3k=.5a0742e0-7a0c-4437-96c7-0f9840e9a185@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>
 <Uk9Ve0pZ2-xtohikEhSCNFJg5BwUqEs9Z5JF3ECMQ3k=.5a0742e0-7a0c-4437-96c7-0f9840e9a185@github.com>
Message-ID: <QEJ6vx3qTOQ5y1q1C9QPNAxd5K-l4nwWlvYszRqz-YQ=.573ebd75-c068-4a31-9c9e-9a35a14b9165@github.com>

On Wed, 10 May 2023 09:57:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 457:
>> 
>>> 455:     public primitive static class VectorPayloadMF64L extends VectorPayloadMF {
>>> 456:         @MultiField(value = 1)
>>> 457:         long mfield = 0;
>> 
>> Can remove the MultiField annotation?
>
> Annotations are propagated to both oops and ci model, and we do special handlings for multifields.

Yes, so besides the vectorization, any other special handling of the multifield? I think vectorization is not affected if it is moved for one element count. Anyway, adding this annotation is also fine to me. Thanks!

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

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


From xgong at openjdk.org  Wed May 10 10:08:51 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 10 May 2023 10:08:51 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <Uk9Ve0pZ2-xtohikEhSCNFJg5BwUqEs9Z5JF3ECMQ3k=.5a0742e0-7a0c-4437-96c7-0f9840e9a185@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>
 <Uk9Ve0pZ2-xtohikEhSCNFJg5BwUqEs9Z5JF3ECMQ3k=.5a0742e0-7a0c-4437-96c7-0f9840e9a185@github.com>
Message-ID: <KuSePM-S0R6c_Gf6z79tg2KbRSKG-U_Pn9eTRJTLuxk=.b35e7bbb-827f-4a06-bd8d-8a2658d1b8bb@github.com>

On Wed, 10 May 2023 09:57:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 246:
>> 
>>> 244:         @ForceInline
>>> 245:         public static VectorPayloadMF createVectPayloadInstance(Class<?> elemType, int length) {
>>> 246:             return newInstanceFactory(elemType, length);
>> 
>> Any reason that we define two methods to new the payload instance? Can remove this and call `newInstanceFactory()` directly?
>
> Just to give meaningful name to wrapper, both are anyways annotated by @ForceInline hence will always get inlined in caller context.

The reason that I asked this question is: when I was modifying the VectorMask related code, I will use `VectorPayloadMF.createVectPayloadInstance(...)` when I need to create a payload for mask. Then I was thinking maybe `VectorPayloadMF.newInstanceFactory()` is better with two reasons:

1. We have already contained "VectorPayloadMF" in the class name.
2. The later is shorter.

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

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


From jbhateja at openjdk.org  Wed May 10 10:32:58 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 May 2023 10:32:58 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <utK9ZMX6Gg05tG1BItaIx86GZWKzKvnluC94KhHpGc8=.d70732c4-932e-47f3-bf35-b5c621b78879@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <utK9ZMX6Gg05tG1BItaIx86GZWKzKvnluC94KhHpGc8=.d70732c4-932e-47f3-bf35-b5c621b78879@github.com>
Message-ID: <6nAwuzVUacs6095692gd15ynurD1nz1MFlUXf3Xlz7o=.7a99beb9-461e-414f-ba82-46f471905fe5@github.com>

On Wed, 10 May 2023 01:52:50 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/parse1.cpp line 924:
> 
>> 922:     kit.sync_jvms();
>> 923:     Node* res = kit.argument(0);
>> 924:     if (res->isa_InlineType() && VectorSupport::skip_value_scalarization(res->as_InlineType()->inline_klass()->get_InlineKlass())) {
> 
> I'm wondering if `tf()->returns_inline_type_as_fields()` in followed `else-if` branch has any connection with `ciInlineKlass::can_be_returned_as_fields()`.  If `ciInlineKlass::can_be_returned_as_fields()` can decide the result of `tf()->returns_inline_type_as_fields()`, then this special handling for bufferred `InlineTypeNode` can be removed like before?

C2 always scalarizes value objects before returning it, for vector we current do not support scalarization hence I am returning the oop buffer of InlineTypeNode.

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

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


From jbhateja at openjdk.org  Wed May 10 10:32:59 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 May 2023 10:32:59 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <KuSePM-S0R6c_Gf6z79tg2KbRSKG-U_Pn9eTRJTLuxk=.b35e7bbb-827f-4a06-bd8d-8a2658d1b8bb@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <SWELlDBuqDWQlbSsZp7LVq6Kg0lVNO_KUg8G-5HbJcA=.71c26ada-9a7a-443a-a699-c009559a25cb@github.com>
 <Uk9Ve0pZ2-xtohikEhSCNFJg5BwUqEs9Z5JF3ECMQ3k=.5a0742e0-7a0c-4437-96c7-0f9840e9a185@github.com>
 <KuSePM-S0R6c_Gf6z79tg2KbRSKG-U_Pn9eTRJTLuxk=.b35e7bbb-827f-4a06-bd8d-8a2658d1b8bb@github.com>
Message-ID: <GQipwPgBwW6O1j4A5-Yb22bApCi2NGO6Lm525-fhkJg=.f8d2a2d2-0c7b-407a-84f5-e6606816f47e@github.com>

On Wed, 10 May 2023 10:05:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Just to give meaningful name to wrapper, both are anyways annotated by @ForceInline hence will always get inlined in caller context.
>
> The reason that I asked this question is: when I was modifying the VectorMask related code, I will use `VectorPayloadMF.createVectPayloadInstance(...)` when I need to create a payload for mask. Then I was thinking maybe `VectorPayloadMF.newInstanceFactory()` is better with two reasons:
> 
> 1. We have already contained "VectorPayloadMF" in the class name.
> 2. The later is shorter.

No problem, please modify as you feel appropriate during your implementation.

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

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


From jbhateja at openjdk.org  Wed May 10 10:54:47 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 May 2023 10:54:47 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <6nAwuzVUacs6095692gd15ynurD1nz1MFlUXf3Xlz7o=.7a99beb9-461e-414f-ba82-46f471905fe5@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <utK9ZMX6Gg05tG1BItaIx86GZWKzKvnluC94KhHpGc8=.d70732c4-932e-47f3-bf35-b5c621b78879@github.com>
 <6nAwuzVUacs6095692gd15ynurD1nz1MFlUXf3Xlz7o=.7a99beb9-461e-414f-ba82-46f471905fe5@github.com>
Message-ID: <VtJVeck3U_I0TzUDaCd3JGd8OzANlM1U5xiISyF6pZk=.b0b7b674-d87a-49ea-8b81-d50e7bae880c@github.com>

On Wed, 10 May 2023 10:28:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/parse1.cpp line 924:
>> 
>>> 922:     kit.sync_jvms();
>>> 923:     Node* res = kit.argument(0);
>>> 924:     if (res->isa_InlineType() && VectorSupport::skip_value_scalarization(res->as_InlineType()->inline_klass()->get_InlineKlass())) {
>> 
>> I'm wondering if `tf()->returns_inline_type_as_fields()` in followed `else-if` branch has any connection with `ciInlineKlass::can_be_returned_as_fields()`.  If `ciInlineKlass::can_be_returned_as_fields()` can decide the result of `tf()->returns_inline_type_as_fields()`, then this special handling for bufferred `InlineTypeNode` can be removed like before?
>
> C2 always scalarizes value objects before returning it, for vector we current do not support scalarization hence I am returning the oop buffer of InlineTypeNode. Without this return value register mask may not comply with value being returned, this will specially be problematic when we return VectorPayloadMF* instances, it only has one field of type vector and return value mask expects a GPR.

BTW,  Valhalla  added a new return calling convention for inline types but it needs to be extended to cover vectors.
[https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L567](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L567)

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

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


From qamai at openjdk.org  Wed May 10 11:09:50 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 10 May 2023 11:09:50 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
Message-ID: <lvE6dWhWnAE-OiV56T2lNwU4I3xRRtN3gYUvKweREBY=.cfedfdf6-6310-4bc8-b085-bc49963c3aef@github.com>

On Tue, 9 May 2023 19:13:25 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/opto/parse1.cpp line 924:

> 922:     kit.sync_jvms();
> 923:     Node* res = kit.argument(0);
> 924:     if (res->isa_InlineType() && VectorSupport::skip_value_scalarization(res->as_InlineType()->inline_klass()->get_InlineKlass())) {

I think in general multi-field fields should be scalarised differently from normal fields, since they represent an array and ideally should be packed together on the stack instead of passing separately. As a result, for now it may be better to reject scalarisation of types with multi-fields altogether.

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

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


From jbhateja at openjdk.org  Wed May 10 11:15:55 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 May 2023 11:15:55 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v15]
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: <7ep3uAYU1ou4TMo5ZNTov4F0y7dL_jlWyWCVe2CbX3k=.4b8b56b9-71dd-4f25-9cdc-540d6efabf7e@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/21bea77c..4bf661ed

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

  Stats: 97 lines in 12 files changed: 6 ins; 13 del; 78 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  Wed May 10 11:15:55 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 May 2023 11:15:55 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <ljlMAELopaAao27beM95tdXhFJBuK3iH2yXCBV33iVI=.7eb67764-b763-4b0d-9973-ce496c5460ce@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
 <ljlMAELopaAao27beM95tdXhFJBuK3iH2yXCBV33iVI=.7eb67764-b763-4b0d-9973-ce496c5460ce@github.com>
Message-ID: <V2KGqspg_IXpstH0rj1sgXEMmld9AbPjRST-3XtQ9Hw=.d5ad1397-478f-453a-9835-57cdb3910cd6@github.com>

On Wed, 10 May 2023 02:28:45 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Impressive work, Jatin!
>
>> Hi @iwanowww , @XiaohongGong , your comments have been addressed. Let me know if this is good to check-in as first version.
> 
> Hi Jatin,
> 
> Thanks for your updating! The current version generally looks fine to me, just with some style issues and minor issues. Hope this patch could be in next. Thanks a lot!
> 
> Best Regards,
> Xiaohong

Hi @XiaohongGong , your comments have been addressed.

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

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


From jbhateja at openjdk.org  Wed May 10 11:15:57 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 10 May 2023 11:15:57 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <lvE6dWhWnAE-OiV56T2lNwU4I3xRRtN3gYUvKweREBY=.cfedfdf6-6310-4bc8-b085-bc49963c3aef@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <lvE6dWhWnAE-OiV56T2lNwU4I3xRRtN3gYUvKweREBY=.cfedfdf6-6310-4bc8-b085-bc49963c3aef@github.com>
Message-ID: <nd8CbL-bxo9M2R-6xn5rmBuIEkLJDB8yr4BEWnsQilM=.5d988f40-572c-458b-bdc6-255b1c4e1d2f@github.com>

On Wed, 10 May 2023 11:07:06 GMT, Quan Anh Mai <qamai 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/parse1.cpp line 924:
> 
>> 922:     kit.sync_jvms();
>> 923:     Node* res = kit.argument(0);
>> 924:     if (res->isa_InlineType() && VectorSupport::skip_value_scalarization(res->as_InlineType()->inline_klass()->get_InlineKlass())) {
> 
> I think in general multi-field fields should be scalarised differently from normal fields, since they represent an array and ideally should be packed together on the stack instead of passing separately. As a result, for now it may be better to reject scalarisation of types with multi-fields altogether.

Agree. We will eventually need to extend new return calling convention to support vectors.
https://github.com/openjdk/valhalla/pull/833#discussion_r1189730320

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

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


From xgong at openjdk.org  Thu May 11 01:46:12 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 11 May 2023 01:46:12 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v15]
In-Reply-To: <7ep3uAYU1ou4TMo5ZNTov4F0y7dL_jlWyWCVe2CbX3k=.4b8b56b9-71dd-4f25-9cdc-540d6efabf7e@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <7ep3uAYU1ou4TMo5ZNTov4F0y7dL_jlWyWCVe2CbX3k=.4b8b56b9-71dd-4f25-9cdc-540d6efabf7e@github.com>
Message-ID: <9g6-INo6jlrhqRV5WhZ4cYJm_X4_zHaIU4PTEmZgEdw=.e7c25950-ae34-4028-9f99-82452224173f@github.com>

On Wed, 10 May 2023 11:15:55 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.

Generally looks good to me. Thanks!

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

Marked as reviewed by xgong (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/833#pullrequestreview-1421611929


From xgong at openjdk.org  Thu May 11 01:46:12 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 11 May 2023 01:46:12 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v14]
In-Reply-To: <VtJVeck3U_I0TzUDaCd3JGd8OzANlM1U5xiISyF6pZk=.b0b7b674-d87a-49ea-8b81-d50e7bae880c@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <w8EyPv61c4lv-FXDcxqXgUPGuwfRpFh8iscka0-l7v0=.bac2e42f-f74e-43b8-97f0-594d1fdebf56@github.com>
 <utK9ZMX6Gg05tG1BItaIx86GZWKzKvnluC94KhHpGc8=.d70732c4-932e-47f3-bf35-b5c621b78879@github.com>
 <6nAwuzVUacs6095692gd15ynurD1nz1MFlUXf3Xlz7o=.7a99beb9-461e-414f-ba82-46f471905fe5@github.com>
 <VtJVeck3U_I0TzUDaCd3JGd8OzANlM1U5xiISyF6pZk=.b0b7b674-d87a-49ea-8b81-d50e7bae880c@github.com>
Message-ID: <wbFRTIX-EYPx8HISe3wnMPJKdCFgTBcbZtFIWjai_Vk=.82cb5420-0877-4a23-a01d-1606d11d64db@github.com>

On Wed, 10 May 2023 10:51:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> C2 always scalarizes value objects before returning it, for vector we current do not support scalarization hence I am returning the oop buffer of InlineTypeNode. Without this return value register mask may not comply with value being returned, this will specially be problematic when we return VectorPayloadMF* instances, it only has one field of type vector and return value mask expects a GPR.
>
> BTW,  Valhalla  added a new return calling convention for inline types but it needs to be extended to cover vectors.
> [https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L567](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L567)

Yeah, make sense to me. What I mean here is whether we can save this new added branch if  the `else-if` in line-928 can avoid such multifields scalarization. Not a block, we can refine such code in future if possible.

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

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


From john.r.rose at oracle.com  Thu May 11 18:23:09 2023
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 11 May 2023 11:23:09 -0700
Subject: Adding Valhalla bits to Lilliput headers
Message-ID: <71073C5F-E6FE-4A4F-BC5D-08EFA8AEA6F1@oracle.com>

Since Lilliput is becoming very real (yay!) the question arises, how will Valhalla be impacted, if at all?

Since we use object header bits for special new state (4 at current count), we will need to rethink how those work with Lilliput?s reorganization of that same header.

Here are a few thoughts on this set of problems:

https://cr.openjdk.org/~jrose/values/valhalla-and-lilliput.html
https://cr.openjdk.org/~jrose/values/valhalla-and-lilliput.md

Comments?  Anything I should add or remove?

? John

And here?s an inline copy, with some formatting stripped:

Adding Valhalla bits to Lilliput headers

John Rose, 5/2023

Problem

Valhalla makes new fundamental distinctions between types, one between identity objects and value objects, and another between variables which are not (easily) flattenable and others which are null-free values that are flattenable.

Some of these distinctions are relevant on the hottest paths in the JVM, including the acmp instruction (which has a new meaning for value objects) and the aaload instruction (which has a special behavior for flattened arrays).

Valhalla prototyping work indicates that gating the new behaviors, with best performance along hot paths, requires allocation of new flag bits in the object header.

In fact, there are currently four header bits to gate:

One bit VAL declares that ?this object has no identity because it is a value?. (This is the key bit; it gates the acmp fast path.)

Two bits ARFL declare that ?this array object has special handling for flat data?. (One says ?it?s all flat in here?, while one says ?not flat, but convert nulls to flat zeroes?.)

One bit LARV declares that ?this object is a larval buffer for Unsafe?. (That?s internal magic.)

That last magic bit encodes a subtle internal distinction used only within code that synthesizes value objects reflectively (e.g., during deserialization). LARV is temporary marker on a value object, to the effect that the object is operating as a non-shareable and mutable private buffer, instead of according to its standard semantics. This is internal ?larval? state is hidden from all users, except clients of the Unsafe API.

Meanwhile, Lilliput is busy shrinking object footprint, under the heading ?Compact Object Headers? (see JEP 450 for current work). A compact object header uses 64 bits (and eventually maybe even 32 bits) to hold per-object metadata that currently occupies 96 bits. The 64 bits are carefully laid out according to this division, from LSB to MSB:

2 bits for object locking state.
5 more bits (used with the first 2) for internal GC states.
25 bits to store the identity hash code (after it is computed).
32 bits for the class pointer, in a compressed state.

A future version of Lilliput may restore the hash code to its previous glory of 31 bits, at the direct cost of reducing the class pointer to 26 bits. This will probably require adjusting the class pointer compression scheme to use fewer bits for similar numbers of classes, so as to support those few Java applications which use dynamic class creation to make huge numbers of classes. It is a tricky tradeoff.

This leads to a conflict: In Lilliput?s current (and likely future) accounting, there are no more bits to hand out to Valhalla for it to use on its hot paths.

Mad props to David Simms, Fredric Parain, and Tobias Hartmann for inventing this stuff, and giving helpful discussions on the shape of this problem. And respect to Roman Kennke and his merry band of Lilliputians for reimagining object layouts. All errors in this document are sole property of the author, but he will part with them upon notification of their presence.

Valhalla dilemmas

To maintain its performance model as prototyped, Valhalla must remove up to four bits from the other compressed header components, or else compromise performance.

The likely form of compromised performance is pushing the bits down into into the Klass structure, at the cost of a Klass decode and indirection on hot paths.

For the record, an unlikely form of compromised performance is adding a new field to Valhalla values, just to carry the extra bits. This move would directly conflict with a key Valhalla goal, shared with Lilliput, which is to reduce footprint. Lilliput shrinks object headers, and Valhalla removes them (for flattened or scalarized variables).

Let?s not compromise, but rather let us use the header bits, and reinterpret them creatively.

The fundamental distinction of value vs. identity must be either a stand-alone bit VAL or somehow derived from the class pointer, by decoding. (?Or by indirectly storing VAL in the Klass, as discussed just above.)

Is it a zero-sum game? Must we steal bandwidth from the compressed class ID field to encode VAL instead?

Yes, it?s true, we must steal bandwidth. And the simplest answer is to reduce the theoretical maximum number of identity classes by 50%.

If we believe that in the far future the mix of value vs. identity classes is 50/50, this is even an optimal step, since we could contrive to keep two spaces of classes, of equal size.

But there are gentler ways to siphon off bandwidth. If we believe that, in the foreseeable future, at most %12.5 of classes will be value classes (a reasonable limit) then we can take three bits to jointly encode the VAL condition. All class IDs with three low bits zero would be reserved to represent value classes. That?s 12.5% of them, and the other 87.5% would be reserved to represent identity classes (the legacy case).

if ((object->_header._klass & VAL_BITS3_MASK) != 0)
  goto not_a_value_object;

Such a decision can be internally adjusted as Valhalla is adopted, but there is likely a setting (3 bits? 2 bits? 1 bit?) which suffices for all workloads. It is unlikely that more than 3 bits is needed, simply because if an application has so many classes that it breaks the encoding limit, raising that limit by a few percent (by going to 4 or 5 bits) is unlikely to stave off OOM for long.

Once the VAL condition is encoded, the larval state bit (LARV) can be allocated easily, by observing that (a) value objects are never locked, and (b) larval objects are never shared. The simplest way to implement the LARV state is to identify it with a locking state. This state needs no associated monitor block; in some designs it corresponds to an ?anonymously locked? state.

if ((object->_header._klass & VAL_BITS3_MASK) != 0)
  goto error;
const LARV_BIT_MASK = LOCK_MASK_IN_PLACE;
if ((object->_header._klass & LARV_BIT_MASK) != 0)
  goto not_a_larval_object;

What about all those hash bits? A value object has no identity hash code (because it has no identity) but there is an overloading of the concept which assigns a structural hash code to a value object instead. This value is likely to be cached in the object header, just like a true identity hash code. If it is not cached in that way, then all those bits open up for use, just for value objects. The LARV bit could be placed there instead.

And the possibilities would be endless: The GC could cache layout summaries in those freed-up bits, for tracing value objects (when on heap) without loading class metadata. It?s tempting. But in the end, it?s likely that Valhalla will use a common ?container? for caching both identity and structural hash codes. And that ?container? will go somewhere else, anyway, if and when Lilliput reaches the 32 bit limit for headers.

This leaves the array bits to consider. Where to put them? There are two choices (besides the third choice of pushing them down into the Klass, at the cost of extra indirections in aaload).

First, try the ?gentle bandwidth siphon? again: Play the 3-bit trick (for some value of ?3?, as discussed above) to take another 12.5% of the class encodings and reserve them for specially-marked arrays. If there are two (or N) special states to worry about within specially-marked arrays, divide that space further into 2 (or N) parts.

In fact, it might be good to use the 3-bit encoding trick to regularly mark all arrays, with a distinctive encoding in their headers. That would make array checks even faster than the current fast path, which loads a descriptor word (the ?layout helper?) from the Klass. That in turn might possibly make some array-sensitive hot paths go faster; it?s hard to tell without doing the prototyping and testing.

If we change the focus to treating all arrays as special, we can discuss taking some the header?s hash code field to encode array characteristics. This would degrade the quality of array hashes, since all arrays with a common set of characteristics would be required to share a common subset of hash codes.

This might seem bad, but note that array hashes are relatively useless, since they do not take array content into account, unlike List hashes.

If there were four equivalence classes, and an identity hash map had up to 2^25 arrays all of type (say) int[], then it would see excess collisions after only 2^23 arrays were inserted.

This interesting discussion would also include the question: What workloads operate on large number of directly hashed arrays? And since those workloads will have the same failure mode after the full 2^25 arrays are entered, do we care that doom comes a little sooner if we steal bits for array characteristics?

If and when hash codes are put back to 31 bits, the same discussion moves out to that scale, which is even less likely.

If we ?steal? array bits from the identity hash code, then array parts of the ?layout helper? descriptor, which describes the scale factor of the array and its basic element type in about 4-5 bits, could be hoisted into the repurposed identity hash bits. Those bits could continue to be part of the hash as well. An extra SHIFT/XOR, perhaps from the class ID field, could help obscure their presence.

In any case, it seems likely that some special encoding of compressed class IDs for arrays will save the day, for array fast paths, and specifically for the special processing paths for arrays that are new in Valhalla. And stealing bits from the hash field, for arrays, seems worth further discussion as well.


From xgong at openjdk.org  Fri May 12 06:49:20 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 12 May 2023 06:49:20 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v15]
In-Reply-To: <7ep3uAYU1ou4TMo5ZNTov4F0y7dL_jlWyWCVe2CbX3k=.4b8b56b9-71dd-4f25-9cdc-540d6efabf7e@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <7ep3uAYU1ou4TMo5ZNTov4F0y7dL_jlWyWCVe2CbX3k=.4b8b56b9-71dd-4f25-9cdc-540d6efabf7e@github.com>
Message-ID: <GueLlm6nyE8dKBakIE9p8VLFnfpl4aSwxBRgkR-xth4=.02154a2f-0d4b-499f-ae0d-2f606e4130d8@github.com>

On Wed, 10 May 2023 11:15:55 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/opto/cfgnode.cpp line 2718:

> 2716:   new_box_node->as_InlineType()->set_field_value(0, payload_value);
> 2717:   new_box_node = igvn->transform(new_box_node);
> 2718:   return new_box_node;

Suggestion:


  const Type* ptype = cached_vbox->field_value(0)->bottom_type();

  Node* new_payload_phi = igvn->transform(clone_through_phi(root_phi, ptype, 3, igvn));
  Node* new_vector_phi = igvn->transform(clone_through_phi(new_payload_phi, vtype, 3, igvn));
  Node* new_vbox_phi = clone_through_phi(root_phi, btype, 1, igvn);

  return igvn->transform(VectorBoxNode::make_box_node(*igvn, phase->C, new_vbox_phi, new_vector_phi, btype, vtype));


Another question: why `igvn->transform()` is used for the first two `clone_through_phi`, while not used for the last one?

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

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


From jbhateja at openjdk.org  Fri May 12 09:34:17 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 12 May 2023 09:34:17 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v16]
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: <aucwtbhIGxH2ZatqBO8za2dKtbrJwi3bvS5KdyJFF10=.36689a5f-30e5-4c6e-b8ef-da1007898af1@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 cleanups.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/833/files
  - new: https://git.openjdk.org/valhalla/pull/833/files/4bf661ed..c68a7676

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

  Stats: 17 lines in 1 file changed: 0 ins; 13 del; 4 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 May 12 09:34:18 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 12 May 2023 09:34:18 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v15]
In-Reply-To: <GueLlm6nyE8dKBakIE9p8VLFnfpl4aSwxBRgkR-xth4=.02154a2f-0d4b-499f-ae0d-2f606e4130d8@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <7ep3uAYU1ou4TMo5ZNTov4F0y7dL_jlWyWCVe2CbX3k=.4b8b56b9-71dd-4f25-9cdc-540d6efabf7e@github.com>
 <GueLlm6nyE8dKBakIE9p8VLFnfpl4aSwxBRgkR-xth4=.02154a2f-0d4b-499f-ae0d-2f606e4130d8@github.com>
Message-ID: <SkUBtA36FKj8lCKyhbGA85eJ5ikZwfwoPYBfxQB9NaY=.2bb88354-61b8-4037-9f61-8d797bc41a3a@github.com>

On Fri, 12 May 2023 06:46:27 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/cfgnode.cpp line 2718:
> 
>> 2716:   new_box_node->as_InlineType()->set_field_value(0, payload_value);
>> 2717:   new_box_node = igvn->transform(new_box_node);
>> 2718:   return new_box_node;
> 
> Suggestion:
> 
> 
>   const Type* ptype = cached_vbox->field_value(0)->bottom_type();
> 
>   Node* new_payload_phi = igvn->transform(clone_through_phi(root_phi, ptype, 3, igvn));
>   Node* new_vector_phi = igvn->transform(clone_through_phi(new_payload_phi, vtype, 3, igvn));
>   Node* new_vbox_phi = clone_through_phi(root_phi, btype, 1, igvn);
> 
>   return igvn->transform(VectorBoxNode::make_box_node(*igvn, phase->C, new_vbox_phi, new_vector_phi, btype, vtype));
> 
> 
> Another question: why `igvn->transform()` is used for the first two `clone_through_phi`, while not used for the last one?

We do not need upfront transformation, new node is registered with GVN within _clone_through_phi_.

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

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


From jbhateja at openjdk.org  Fri May 12 09:34:18 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 12 May 2023 09:34:18 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v15]
In-Reply-To: <SkUBtA36FKj8lCKyhbGA85eJ5ikZwfwoPYBfxQB9NaY=.2bb88354-61b8-4037-9f61-8d797bc41a3a@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <7ep3uAYU1ou4TMo5ZNTov4F0y7dL_jlWyWCVe2CbX3k=.4b8b56b9-71dd-4f25-9cdc-540d6efabf7e@github.com>
 <GueLlm6nyE8dKBakIE9p8VLFnfpl4aSwxBRgkR-xth4=.02154a2f-0d4b-499f-ae0d-2f606e4130d8@github.com>
 <SkUBtA36FKj8lCKyhbGA85eJ5ikZwfwoPYBfxQB9NaY=.2bb88354-61b8-4037-9f61-8d797bc41a3a@github.com>
Message-ID: <R_R3AFiyDJ0FGCKSIJGoU5yCtXKcI_7alvAWZTMJWdg=.adcd42d2-cbf2-446e-8f24-8797ed7b580d@github.com>

On Fri, 12 May 2023 09:27:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/cfgnode.cpp line 2718:
>> 
>>> 2716:   new_box_node->as_InlineType()->set_field_value(0, payload_value);
>>> 2717:   new_box_node = igvn->transform(new_box_node);
>>> 2718:   return new_box_node;
>> 
>> Suggestion:
>> 
>> 
>>   const Type* ptype = cached_vbox->field_value(0)->bottom_type();
>> 
>>   Node* new_payload_phi = igvn->transform(clone_through_phi(root_phi, ptype, 3, igvn));
>>   Node* new_vector_phi = igvn->transform(clone_through_phi(new_payload_phi, vtype, 3, igvn));
>>   Node* new_vbox_phi = clone_through_phi(root_phi, btype, 1, igvn);
>> 
>>   return igvn->transform(VectorBoxNode::make_box_node(*igvn, phase->C, new_vbox_phi, new_vector_phi, btype, vtype));
>> 
>> 
>> Another question: why `igvn->transform()` is used for the first two `clone_through_phi`, while not used for the last one?
>
> We do not need upfront transformation, new node is registered with GVN within _clone_through_phi_.

Modified as suggested.

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

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


From xgong at openjdk.org  Fri May 12 09:34:18 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 12 May 2023 09:34:18 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v15]
In-Reply-To: <R_R3AFiyDJ0FGCKSIJGoU5yCtXKcI_7alvAWZTMJWdg=.adcd42d2-cbf2-446e-8f24-8797ed7b580d@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <7ep3uAYU1ou4TMo5ZNTov4F0y7dL_jlWyWCVe2CbX3k=.4b8b56b9-71dd-4f25-9cdc-540d6efabf7e@github.com>
 <GueLlm6nyE8dKBakIE9p8VLFnfpl4aSwxBRgkR-xth4=.02154a2f-0d4b-499f-ae0d-2f606e4130d8@github.com>
 <SkUBtA36FKj8lCKyhbGA85eJ5ikZwfwoPYBfxQB9NaY=.2bb88354-61b8-4037-9f61-8d797bc41a3a@github.com>
 <R_R3AFiyDJ0FGCKSIJGoU5yCtXKcI_7alvAWZTMJWdg=.adcd42d2-cbf2-446e-8f24-8797ed7b580d@github.com>
Message-ID: <NtVW4vQPq-M_K6O88L15UqkEofy_O9VEJXo3n7cfJa0=.f979d9cd-c485-4c01-b2df-7fa2ee6c342a@github.com>

On Fri, 12 May 2023 09:27:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> We do not need upfront transformation, new node is registered with GVN within _clone_through_phi_.
>
> Modified as suggested.

Thanks for the updating! Change looks good to me.

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

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


From vlivanov at openjdk.org  Fri May 12 18:40:17 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 12 May 2023 18:40:17 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v16]
In-Reply-To: <aucwtbhIGxH2ZatqBO8za2dKtbrJwi3bvS5KdyJFF10=.36689a5f-30e5-4c6e-b8ef-da1007898af1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <aucwtbhIGxH2ZatqBO8za2dKtbrJwi3bvS5KdyJFF10=.36689a5f-30e5-4c6e-b8ef-da1007898af1@github.com>
Message-ID: <Zirp9oRMnlhozcuIOeHLElk87m055XpHr2T9x837suI=.9d796e10-ae9c-4cbe-95c0-4da5f1e78127@github.com>

On Fri, 12 May 2023 09:34:17 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 cleanups.

Thanks for clarifications, Jatin. 

Overall, looks fine. Feel free to push it.

src/hotspot/share/opto/graphKit.cpp line 1070:

> 1068:       bool ignored_will_link;
> 1069:       ciField* field = method()->get_field_at_bci(bci(), ignored_will_link);
> 1070:       int size = field->is_multifield_base() ?

Encapsulate size computation for mulitfields in `ciField`?

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

Marked as reviewed by vlivanov (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/833#pullrequestreview-1424969452
PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1192684262


From vlivanov at openjdk.org  Fri May 12 18:40:17 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 12 May 2023 18:40:17 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v13]
In-Reply-To: <EnesnfEekLj_szMfNrGwmBFPWssBR1j4mN9CGlzRhF4=.c49b33c2-7010-4a01-9fba-7a7e411595e7@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <C9Y07ec8LobNQIYGUfEt4wr2iwHzaQwvo54aPW6s_DQ=.58b61f2b-66f5-4990-875d-344b89734693@github.com>
 <C55BsHb2t8gu8Nj1DoutUYizm12P89xjbaq3RhHNJyk=.bb026c6c-0172-46fe-9f55-1d5af9568c28@github.com>
 <EnesnfEekLj_szMfNrGwmBFPWssBR1j4mN9CGlzRhF4=.c49b33c2-7010-4a01-9fba-7a7e411595e7@github.com>
Message-ID: <N-yKgr9q2xlYwV6AyiUrC7QP1zIqduQosYKGPw7a-HY=.213b529d-a923-4637-a55d-7e35b81f01b6@github.com>

On Tue, 9 May 2023 19:03:26 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/prims/vectorSupport.cpp line 286:
>> 
>>> 284: }
>>> 285: 
>>> 286: InstanceKlass* VectorSupport::get_vector_payload_klass(BasicType elem_bt, int num_elem) {
>> 
>> Alternatively, it could be implemented as a class lookup by name. 
>> 
>> It is fine for now, but eventually I'd like to get rid of `vmSymbols::vector_VectorPayloadMF*_signature()` and `vector_VectorPayloadMF*_klass` and use only `VectorSupport.VectorPayloadMF` to mark classes which need special handling. 
>> 
>> Original implementation requires subclasses to declare 2 static fields which are used by `klass2length` and `klass2bt` queries. Since typed vector classes declare a field of primitive type, it can be used as the source of information now.
>
> I thought about it but any lookup by name may be costly. But we can refine as suggested.

If it turns out to be costly, JVM can keep a table on its side to cache lookup results.

>> src/hotspot/share/prims/vectorSupport.cpp line 403:
>> 
>>> 401:   fieldDescriptor fd;
>>> 402:   int elem_size = type2aelembytes(elem_bt);
>>> 403:   Symbol* payload_sig = VectorSupport::get_vector_payload_field_signature(elem_bt, num_elem);
>> 
>> Alternatively, you could derive that information from `payload` field. Would it also make `klass2length()` and `klass2bt()` queries (and relevant static final fields on Java side) obsolete?
>
>> Alternatively, you could derive that information from `payload` field. Would it also make `klass2length()` and `klass2bt()` queries (and relevant static final fields on Java side) obsolete?
> 
> find_field need field signature to query the fieldDescriptor.   payload is no longer a primitive array but a primitive class instance, we still need pass klass2length() and klass2bt() information to payload signature factory method.

Looking up the field by name in the trusted class is also an option.

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

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


From jbhateja at openjdk.org  Mon May 15 02:12:16 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 15 May 2023 02:12:16 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v16]
In-Reply-To: <Zirp9oRMnlhozcuIOeHLElk87m055XpHr2T9x837suI=.9d796e10-ae9c-4cbe-95c0-4da5f1e78127@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <aucwtbhIGxH2ZatqBO8za2dKtbrJwi3bvS5KdyJFF10=.36689a5f-30e5-4c6e-b8ef-da1007898af1@github.com>
 <Zirp9oRMnlhozcuIOeHLElk87m055XpHr2T9x837suI=.9d796e10-ae9c-4cbe-95c0-4da5f1e78127@github.com>
Message-ID: <KsWXCaWvh475avvhNjmAMIr6GAMxPS3pQNmB74Jz4a4=.b3be6ef1-9ea5-4254-a6d9-84c839ad3ec1@github.com>

On Fri, 12 May 2023 18:33:23 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review cleanups.
>
> src/hotspot/share/opto/graphKit.cpp line 1070:
> 
>> 1068:       bool ignored_will_link;
>> 1069:       ciField* field = method()->get_field_at_bci(bci(), ignored_will_link);
>> 1070:       int size = field->is_multifield_base() ?
> 
> Encapsulate size computation for mulitfields in `ciField`?

Decision to scalarize a multi-field is delegated to compiler, ci* model is sacrosanct.  So a size query over ciMultiField (base) will always return the entire bundle size, we have to to a special handling on compiler side. I have factored this into a static routine.

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

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


From jbhateja at openjdk.org  Mon May 15 02:16:16 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 15 May 2023 02:16:16 GMT
Subject: [lworld+vector] RFR: 8304310: Initial compilers and runtime
 handling for multifield backed vectors. [v16]
In-Reply-To: <Zirp9oRMnlhozcuIOeHLElk87m055XpHr2T9x837suI=.9d796e10-ae9c-4cbe-95c0-4da5f1e78127@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
 <aucwtbhIGxH2ZatqBO8za2dKtbrJwi3bvS5KdyJFF10=.36689a5f-30e5-4c6e-b8ef-da1007898af1@github.com>
 <Zirp9oRMnlhozcuIOeHLElk87m055XpHr2T9x837suI=.9d796e10-ae9c-4cbe-95c0-4da5f1e78127@github.com>
Message-ID: <cW8tSdbhwgtpBmh7GHzl2Aek9GXuIlWydBNrRvQLOXw=.94e9eac8-7865-433a-b144-09bf1f005e2d@github.com>

On Fri, 12 May 2023 18:36:55 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review cleanups.
>
> Thanks for clarifications, Jatin. 
> 
> Overall, looks fine. Feel free to push it.

Thanks @iwanowww , @XiaohongGong  for your reviews. I plan to incrementally fine tune and stabilize the support subsequent patches.

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

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


From jbhateja at openjdk.org  Mon May 15 11:35:22 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 15 May 2023 11:35:22 GMT
Subject: [lworld+vector] Integrated: 8304310: Initial compilers and runtime
 handling for multifield backed vectors.
In-Reply-To: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
References: <1hTHWZ5pw1KUEYSzkQ-T0D-RogjaFEiP6V3FTdDrDvY=.c3de3b3f-3050-4969-bc2e-ce985578b1f1@github.com>
Message-ID: <HCK3d_Nb3H_o1SyXMOcq-db8rqs9ts7q5Kx4mFeihOo=.83744231-f340-463c-9c71-d197f181a6dd@github.com>

On Fri, 17 Mar 2023 14:49:24 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

This pull request has now been integrated.

Changeset: d9f744fe
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d9f744fe6e816a91aa7c8d5e84ce464e8a9d3921
Stats:     1566 lines in 79 files changed: 1077 ins; 79 del; 410 mod

8304310: Initial compilers and runtime handling for multifield backed vectors.

Reviewed-by: xgong, vlivanov

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

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


From xgong at openjdk.org  Tue May 16 04:15:01 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 16 May 2023 04:15:01 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes
Message-ID: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>

This patch changes the Vector API java side and hotspot
compiler code to make the `VectorMask` operations work well
after integrating with valhalla value/primitive classes.

Java side changes include:
 - Define the concrete VectorMask classes as value class.
 - Define the payload field type as primitive classes, which
   defines `MultiField` annotated field to save the element
   values.
 - Change all the relative API implementations, which use
   Unsafe APIs to access the new payload.
 - Move several VectorMask default operations to the abstract
   super class.

Compiler changes include:
 - Enable intrinsification for VectorMask related operations.
   Mask input/output of `VectorBox/VectorUnbox` is changed to
   the boolean vector format, to adapt C2's `InlineTypeNode`
   and new `VectorBox` features. Note that the mask input/output
   is a normal vector or predicate before.
 - Refine `VectorBox` expanding logic to make it right when the
   primitive payload instance is not flattened.
 - Minor code cleanup.

Basic VectorMask jtreg tests pass with
"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
and the basic unit tests work well after enabling vector support.

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

Commit messages:
 - 8307715: Integrate VectorMask with value/primitive classes

Changes: https://git.openjdk.org/valhalla/pull/845/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=845&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307715
  Stats: 3310 lines in 47 files changed: 364 ins; 1436 del; 1510 mod
  Patch: https://git.openjdk.org/valhalla/pull/845.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/845/head:pull/845

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


From xgong at openjdk.org  Wed May 17 09:07:18 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 17 May 2023 09:07:18 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
Message-ID: <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>

> This patch changes the Vector API java side and hotspot
> compiler code to make the `VectorMask` operations work well
> after integrating with valhalla value/primitive classes.
> 
> Java side changes include:
>  - Define the concrete VectorMask classes as value class.
>  - Define the payload field type as primitive classes, which
>    defines `MultiField` annotated field to save the element
>    values.
>  - Change all the relative API implementations, which use
>    Unsafe APIs to access the new payload.
>  - Move several VectorMask default operations to the abstract
>    super class.
> 
> Compiler changes include:
>  - Enable intrinsification for VectorMask related operations.
>    Mask input/output of `VectorBox/VectorUnbox` is changed to
>    the boolean vector format, to adapt C2's `InlineTypeNode`
>    and new `VectorBox` features. Note that the mask input/output
>    is a normal vector or predicate before.
>  - Refine `VectorBox` expanding logic to make it right when the
>    primitive payload instance is not flattened.
>  - Minor code cleanup.
> 
> Basic VectorMask jtreg tests pass with
> "`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
> and the basic unit tests work well after enabling vector support.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Fix issue when the boxed type is not equal to the intrinsic return type

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/845/files
  - new: https://git.openjdk.org/valhalla/pull/845/files/9f90cb77..dadedbe2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=845&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=845&range=00-01

  Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/845.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/845/head:pull/845

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


From jbhateja at openjdk.org  Wed May 17 14:00:33 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 17 May 2023 14:00:33 GMT
Subject: [lworld+vector] RFR: Merge lworld
Message-ID: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>

Merge from lworld into lworld+vector.

Please review and approve.

Best Regards,
Jatin

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

Commit messages:
 - Remove white spaces.
 - Merge lworld
 - 8306986: [lworld] C2 compilation fails with assert "Should have been buffered"
 - 8232892: [AARCH64] [lworld] Inline type use of Access API (compiler barrier support)
 - 8306677: [lworld] TestCallingConventionC1 fails on AArch64 with -XX:+PatchALot
 - 8303000: [lworld] C2 compilation fails with assert(phase->C->get_alias_index(t) == phase->C->get_alias_index(t_adr)) failed: correct memory chain
 - 8306568: [lworld] Oop verification failure in InlineKlass::returned_inline_klass
 - 8306567: ProblemList ProblemList CDS test RedefineRunningMethods_Shared.java
 - 8306565: [lworld] Asserts with stress testing during PhaseCCP due to unexpected top types
 - 8306453: ProblemList CDS tests failing with dumping the shared archive: --patch-module
 - ... and 380 more: https://git.openjdk.org/valhalla/compare/d9f744fe...04b8ab3f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld+vector: https://webrevs.openjdk.org/?repo=valhalla&pr=847&range=00.0
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=847&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/847/files
  Stats: 32782 lines in 1453 files changed: 19329 ins; 7805 del; 5648 mod
  Patch: https://git.openjdk.org/valhalla/pull/847.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/847/head:pull/847

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


From jbhateja at openjdk.org  Wed May 17 14:00:34 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 17 May 2023 14:00:34 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
Message-ID: <E3ZA_RTeA1AYuWrM_nDW5t0hw8hblWBQ-IbAPmOgBnk=.189800f9-d4af-48c8-8a2b-9de755211784@github.com>

On Wed, 17 May 2023 13:47:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld into lworld+vector.
> 
> Please review and approve.
> 
> Best Regards,
> Jatin

Post merge validation status is at par with pre-merge.

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

PR Comment: https://git.openjdk.org/valhalla/pull/847#issuecomment-1551444942


From jbhateja at openjdk.org  Thu May 18 01:08:14 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 18 May 2023 01:08:14 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
Message-ID: <IoBaXno_ojU_8netCa5sMa7mIiX5LOJbS7-csjyVmu8=.6ff19e64-5911-407f-9a34-1fd560c5430e@github.com>

On Wed, 17 May 2023 13:47:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld into lworld+vector.
> 
> Please review and approve.
> 
> Best Regards,
> Jatin

Hi @TobiHartmann ,
Can you kindly sponsor the patch.

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/847#issuecomment-1552268435


From xgong at openjdk.org  Thu May 18 02:48:10 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 18 May 2023 02:48:10 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
Message-ID: <czavoYDKiJREgoyUibVOqbqz3IcwMAaRWkvcCN5OLy0=.ca9ded7d-984a-4c24-8d1b-048d20b4d72c@github.com>

On Wed, 17 May 2023 09:07:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot
>> compiler code to make the `VectorMask` operations work well
>> after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete VectorMask classes as value class.
>>  - Define the payload field type as primitive classes, which
>>    defines `MultiField` annotated field to save the element
>>    values.
>>  - Change all the relative API implementations, which use
>>    Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract
>>    super class.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for VectorMask related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to
>>    the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output
>>    is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the
>>    primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask jtreg tests pass with
>> "`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue when the boxed type is not equal to the intrinsic return type

Hi @iwanowww @PaulSandoz @jatin-bhateja , 

Could you please take a look at this patch related to VectorMask integration with value/primitive classes? Thanks a lot!

VectorShuffle related changes are in work progress, and will be pushed soon after further testing!

Best Regards,
Xiaohong

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1552328837


From jbhateja at openjdk.org  Thu May 18 08:30:13 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 18 May 2023 08:30:13 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
Message-ID: <0lbNNTj7U4d9yuOB6hhVIjkLdVB1cZ5n2SkQZF4rgGE=.5c1cc9ad-9701-46aa-84d6-a06a9e9a3c81@github.com>

On Wed, 17 May 2023 09:07:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot
>> compiler code to make the `VectorMask` operations work well
>> after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete VectorMask classes as value class.
>>  - Define the payload field type as primitive classes, which
>>    defines `MultiField` annotated field to save the element
>>    values.
>>  - Change all the relative API implementations, which use
>>    Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract
>>    super class.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for VectorMask related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to
>>    the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output
>>    is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the
>>    primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask jtreg tests pass with
>> "`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue when the boxed type is not equal to the intrinsic return type

Your patch looks good to me apart from some minor comments.

src/hotspot/share/opto/castnode.cpp line 99:

> 97:       return vt;
> 98:     }
> 99:   }

As per[ JEP ](https://openjdk.org/jeps/8277163) Value classes (primitve and value) are implicitly final. Also both oop and InlineTypeNode should always be of same type. Do you see a case where a cast should be applied to oop but InlineTypeNode remain sacrosanct ?
Only  one I can think off is when InlineTypeNode was created using _make_default_ / _make_uninitialized_ and _ciInstanceKlass_ was uninitialized

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

> 246:   // Multi-field based vectors are InlineTypeNodes and are already
> 247:   // scalarized by process_inline_types.
> 248:   if (is_vector(iklass) || is_vector_mask(iklass)) {

We can directly use _!is_vector_shuffle(iklass)_

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

> 493: // Since intrinsification is skipped upfront for mask/shuffle related operations
> 494: // this is anyways a dead code currently.
> 495: void PhaseVector::expand_vunbox_node_shuffle(VectorUnboxNode* vec_unbox) {

You can also remove mask related functionality from this routines, since you have already moved it to box creation method.

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

> 573:     ciInstanceKlass* from_kls = tinst->instance_klass();
> 574: 
> 575:     if (is_vector(from_kls) || is_vector_mask(from_kls)) {

Same as above, we can directly use _!is_vector_shuffle(from_kls)_

src/hotspot/share/opto/vectorIntrinsics.cpp line 51:

> 49: 
> 50:   ciInstanceKlass* ik = vbox_type->instance_klass();
> 51:   assert(is_vector(ik) || is_vector_mask(ik), "not a vector or a vector mask");

Same as above.

src/hotspot/share/opto/vectorIntrinsics.cpp line 183:

> 181:   }
> 182:   // TODO[valhalla] Limiting support to only vector and vector mask cases untill shuffle becomes inline types.
> 183:   if (!is_vector(vbox_type->instance_klass()) && !is_vector_mask(vbox_type->instance_klass())) {

Same as above.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java line 642:

> 640:             return VectorSupport.binaryOp(VECTOR_OP_AND, Double64Mask.class, null,
> 641:                                           long.class, VLENGTH, this, m, null,
> 642:                                           (m1, m2, vm) -> (Double64Mask) m1.bOp(m2, (i, a, b) -> a & b));

There is difference in naming convention of fallback routine b/w masks (bOp) and vectors (bOpMF),  we should have a one consistent convention.

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

PR Review: https://git.openjdk.org/valhalla/pull/845#pullrequestreview-1432103584
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197438355
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197442724
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197455539
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197451664
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197452188
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197462200
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197483541


From jbhateja at openjdk.org  Thu May 18 08:30:13 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 18 May 2023 08:30:13 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <czavoYDKiJREgoyUibVOqbqz3IcwMAaRWkvcCN5OLy0=.ca9ded7d-984a-4c24-8d1b-048d20b4d72c@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <czavoYDKiJREgoyUibVOqbqz3IcwMAaRWkvcCN5OLy0=.ca9ded7d-984a-4c24-8d1b-048d20b4d72c@github.com>
Message-ID: <SZwUZ5eHC4BL1iSsysTQtu7Ds1410QL9ew3ZQgIPxjs=.4249effd-0ca2-4fca-bd5c-c5d1ed13481f@github.com>

On Thu, 18 May 2023 02:43:19 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Hi @iwanowww @PaulSandoz @jatin-bhateja ,
> 
> Could you please take a look at this patch related to VectorMask integration with value/primitive classes? Thanks a lot!
> 
> VectorShuffle related changes are in work progress, and will be pushed soon after further testing!
> 
> Best Regards, Xiaohong

I have rebased lworld+vector to lworld tip, there were changes in structure of InlineTypeNode.
https://github.com/openjdk/valhalla/pull/847
Kindly check and approve.

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1552718335


From xgong at openjdk.org  Thu May 18 08:35:14 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 18 May 2023 08:35:14 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <0lbNNTj7U4d9yuOB6hhVIjkLdVB1cZ5n2SkQZF4rgGE=.5c1cc9ad-9701-46aa-84d6-a06a9e9a3c81@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <0lbNNTj7U4d9yuOB6hhVIjkLdVB1cZ5n2SkQZF4rgGE=.5c1cc9ad-9701-46aa-84d6-a06a9e9a3c81@github.com>
Message-ID: <gTaU5GtST_vGsQiSEsZTyrz5VRc4WPUcYogCpKyVYtk=.9b2c899c-3b52-43c5-9b47-d6ef8a020104@github.com>

On Thu, 18 May 2023 06:32:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issue when the boxed type is not equal to the intrinsic return type
>
> src/hotspot/share/opto/vector.cpp line 248:
> 
>> 246:   // Multi-field based vectors are InlineTypeNodes and are already
>> 247:   // scalarized by process_inline_types.
>> 248:   if (is_vector(iklass) || is_vector_mask(iklass)) {
> 
> We can directly use _!is_vector_shuffle(iklass)_

These code will be removed after shuffle is supported. I will push the patch soon with more clean-ups. Thanks for your review!

> src/hotspot/share/opto/vector.cpp line 495:
> 
>> 493: // Since intrinsification is skipped upfront for mask/shuffle related operations
>> 494: // this is anyways a dead code currently.
>> 495: void PhaseVector::expand_vunbox_node_shuffle(VectorUnboxNode* vec_unbox) {
> 
> You can also remove mask related functionality from this routines, since you have already moved it to box creation method.

Same as before. These will be cleaned-up soon.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java line 642:
> 
>> 640:             return VectorSupport.binaryOp(VECTOR_OP_AND, Double64Mask.class, null,
>> 641:                                           long.class, VLENGTH, this, m, null,
>> 642:                                           (m1, m2, vm) -> (Double64Mask) m1.bOp(m2, (i, a, b) -> a & b));
> 
> There is difference in naming convention of fallback routine b/w masks (bOp) and vectors (bOpMF),  we should have a one consistent convention.

Good catch! I will fix this later. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197551948
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197552997
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197553791


From xgong at openjdk.org  Thu May 18 08:39:17 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 18 May 2023 08:39:17 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <0lbNNTj7U4d9yuOB6hhVIjkLdVB1cZ5n2SkQZF4rgGE=.5c1cc9ad-9701-46aa-84d6-a06a9e9a3c81@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <0lbNNTj7U4d9yuOB6hhVIjkLdVB1cZ5n2SkQZF4rgGE=.5c1cc9ad-9701-46aa-84d6-a06a9e9a3c81@github.com>
Message-ID: <jZgpQOtAmAC4xvuCR7SoyViCyL6LfvPoebLZUg1DiOA=.198ef64d-2449-4096-9c9a-1614682809ed@github.com>

On Thu, 18 May 2023 06:30:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issue when the boxed type is not equal to the intrinsic return type
>
> src/hotspot/share/opto/castnode.cpp line 99:
> 
>> 97:       return vt;
>> 98:     }
>> 99:   }
> 
> As per[ JEP ](https://openjdk.org/jeps/8277163) Value classes (primitve and value) are implicitly final. Also both oop and InlineTypeNode should always be of same type. Do you see a case where a cast should be applied to oop but InlineTypeNode remain sacrosanct ?
> Only  one I can think off is when InlineTypeNode was created using _make_default_ / _make_uninitialized_ and _ciInstanceKlass_ was uninitialized

Yes, the relative API is `VectorMask.fromArray()`, which the InlineTypeNode type is the concrete value class (e.g. `Byte128Mask.class`), while the receiver type is its super class (e.g. `VectorMask.class`). I think it is generated between `VectorBox` and its relative inline method call.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1197557505


From xgong at openjdk.org  Thu May 18 09:39:19 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 18 May 2023 09:39:19 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <YHDdDTyJbmxRitpxgSnnkrztsvNwTc0DrV3Kl8Ebcqg=.e101e0e2-ac95-4a88-b8fe-9aed0f9e5cfd@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <YHDdDTyJbmxRitpxgSnnkrztsvNwTc0DrV3Kl8Ebcqg=.e101e0e2-ac95-4a88-b8fe-9aed0f9e5cfd@github.com>
Message-ID: <xML6zUHTLx3Llo7x21XiY8ufdFyRFl2_BsqJlrX-q9g=.a9790084-463c-4d79-aeaa-790a605c18b4@github.com>

On Thu, 18 May 2023 09:34:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.

Sure, I will run this test. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1552795087


From jbhateja at openjdk.org  Thu May 18 09:39:19 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 18 May 2023 09:39:19 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
Message-ID: <YHDdDTyJbmxRitpxgSnnkrztsvNwTc0DrV3Kl8Ebcqg=.e101e0e2-ac95-4a88-b8fe-9aed0f9e5cfd@github.com>

On Wed, 17 May 2023 09:07:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot
>> compiler code to make the `VectorMask` operations work well
>> after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete VectorMask classes as value class.
>>  - Define the payload field type as primitive classes, which
>>    defines `MultiField` annotated field to save the element
>>    values.
>>  - Change all the relative API implementations, which use
>>    Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract
>>    super class.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for VectorMask related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to
>>    the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output
>>    is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the
>>    primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask jtreg tests pass with
>> "`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue when the boxed type is not equal to the intrinsic return type

I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check.
Relevant test : Float256VectorTest.java.

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1552793665


From xgong at openjdk.org  Thu May 18 09:45:11 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 18 May 2023 09:45:11 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <xML6zUHTLx3Llo7x21XiY8ufdFyRFl2_BsqJlrX-q9g=.a9790084-463c-4d79-aeaa-790a605c18b4@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <YHDdDTyJbmxRitpxgSnnkrztsvNwTc0DrV3Kl8Ebcqg=.e101e0e2-ac95-4a88-b8fe-9aed0f9e5cfd@github.com>
 <xML6zUHTLx3Llo7x21XiY8ufdFyRFl2_BsqJlrX-q9g=.a9790084-463c-4d79-aeaa-790a605c18b4@github.com>
Message-ID: <X4SfOmysOoSJmnhF4jg7XKe5Mt9L4lIVPNGJ2grDluk=.59647729-b09a-42f8-a459-7b654e0a258c@github.com>

On Thu, 18 May 2023 09:36:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
> 
> Sure, I will run this test. Thanks!

There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future.  Besides, did you see any other known failures before? Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1552803068


From jbhateja at openjdk.org  Thu May 18 10:23:09 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 18 May 2023 10:23:09 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
Message-ID: <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>

On Wed, 17 May 2023 09:07:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot
>> compiler code to make the `VectorMask` operations work well
>> after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete VectorMask classes as value class.
>>  - Define the payload field type as primitive classes, which
>>    defines `MultiField` annotated field to save the element
>>    values.
>>  - Change all the relative API implementations, which use
>>    Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract
>>    super class.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for VectorMask related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to
>>    the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output
>>    is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the
>>    primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask jtreg tests pass with
>> "`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue when the boxed type is not equal to the intrinsic return type

> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
> > 
> > 
> > Sure, I will run this test. Thanks!
> 
> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!



> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
> > 
> > 
> > Sure, I will run this test. Thanks!
> 
> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!

I saw some failures with -XX:TieredStopAtLevel=3 which is C1 compilation, I am not sure if they are related to de-optimization. 
Attaching relevant hs_err log.
[hs_err_pid717512.log](https://github.com/openjdk/valhalla/files/11506800/hs_err_pid717512.log)

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1552842919


From jbhateja at openjdk.org  Thu May 18 10:34:07 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 18 May 2023 10:34:07 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
Message-ID: <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>

On Thu, 18 May 2023 10:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
> > 
> > 
> > Sure, I will run this test. Thanks!
> 
> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!

With -XX:-TieredCompilation I see following crash right at the start for the regression run, looks like we need to handle [mask type value during rematerialization.](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144)

[hs_err_pid718455.log](https://github.com/openjdk/valhalla/files/11506850/hs_err_pid718455.log)

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1552856392


From vladimir.x.ivanov at oracle.com  Thu May 18 18:07:01 2023
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 18 May 2023 11:07:01 -0700
Subject: CFV: New Valhalla Committer: Jatin Bhateja
Message-ID: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>

I hereby nominate Jatin Bhateja (OpenJDK name: jbhateja) to Valhalla 
Committer.

Jatin is a Reviewer in JDK Project and a Committer in Panama Project. He 
authored numerous bug fixes and enhancements in C2 and Vector API.

In the context of Valhalla Project, Jatin leads the effort to migrate 
Vector API implementation to value objects and primitive values (most 
notably, [3] [4] [5] in lworld+vector branch [6]).

Votes are due by 2021-05-31 17:00 PST.

Only current Valhalla Committers [1] are eligible to vote
on this nomination.  Votes must be cast in the open by replying
to this mailing list.

For Lazy Consensus voting instructions, see [2].

Best regards,
Vladimir Ivanov

[1] https://openjdk.java.net/census

[2] https://openjdk.java.net/projects/#committer-vote

[3] 
https://github.com/openjdk/valhalla/commit/8159184e95f67bb5ea4d3754bfcf7ab7a25a9803
     8296767: Support multi-field based vector classes.

[4] 
https://github.com/openjdk/valhalla/commit/d9f744fe6e816a91aa7c8d5e84ce464e8a9d3921
     8304310: Initial compilers and runtime handling for multifield 
backed vectors.

[5] 
https://github.com/jatin-bhateja/valhalla/commit/b7b7231ae76f4f2a2510dd904aa407771a70c970
     8308363: Initial compiler support for FP16 scalar operations (under 
review)

[6] https://github.com/openjdk/valhalla/tree/lworld+vector


From paul.sandoz at oracle.com  Thu May 18 18:10:19 2023
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 18 May 2023 18:10:19 +0000
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <CA7EABE5-FCAA-4CA6-B119-FB9C547B8444@oracle.com>

Vote: yes

Paul.


From vladimir.x.ivanov at oracle.com  Thu May 18 18:10:56 2023
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 18 May 2023 11:10:56 -0700
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <bb86d916-7e3f-ef78-1ed0-d6ba7eda8a8a@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 5/18/23 11:07, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (OpenJDK name: jbhateja) to Valhalla 
> Committer.
> 


From roger.riggs at oracle.com  Thu May 18 18:35:02 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 18 May 2023 14:35:02 -0400
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <71f77f18-f366-4f61-78bc-439c4d8e2355@oracle.com>

Vote: Yes

On 5/18/23 2:07 PM, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (OpenJDK name: jbhateja) to Valhalla 
> Committer. 



From frederic.parain at oracle.com  Thu May 18 20:39:37 2023
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 18 May 2023 16:39:37 -0400
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <8e69fe92-323b-0c2c-0596-5977cb61d9ad@oracle.com>

Vote: Yes


On 5/18/23 2:07 PM, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (OpenJDK name: jbhateja) to Valhalla 
> Committer.
>
> Jatin is a Reviewer in JDK Project and a Committer in Panama Project. 
> He authored numerous bug fixes and enhancements in C2 and Vector API.
>
> In the context of Valhalla Project, Jatin leads the effort to migrate 
> Vector API implementation to value objects and primitive values (most 
> notably, [3] [4] [5] in lworld+vector branch [6]).
>
> Votes are due by 2021-05-31 17:00 PST.
>
> Only current Valhalla Committers [1] are eligible to vote
> on this nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://openjdk.java.net/census
>
> [2] https://openjdk.java.net/projects/#committer-vote
>
> [3] 
> https://github.com/openjdk/valhalla/commit/8159184e95f67bb5ea4d3754bfcf7ab7a25a9803
> ??? 8296767: Support multi-field based vector classes.
>
> [4] 
> https://github.com/openjdk/valhalla/commit/d9f744fe6e816a91aa7c8d5e84ce464e8a9d3921
> ??? 8304310: Initial compilers and runtime handling for multifield 
> backed vectors.
>
> [5] 
> https://github.com/jatin-bhateja/valhalla/commit/b7b7231ae76f4f2a2510dd904aa407771a70c970
> ??? 8308363: Initial compiler support for FP16 scalar operations 
> (under review)
>
> [6] https://github.com/openjdk/valhalla/tree/lworld+vector


From xgong at openjdk.org  Fri May 19 01:16:11 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 19 May 2023 01:16:11 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask with
 value/primitive classes [v2]
In-Reply-To: <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
 <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
Message-ID: <osbr5zsMSSGfdFdr5oYhMht4Y4ZPE9UvrdwoWBJKwro=.b66b07e0-026f-401e-876a-4b2531cd5c4b@github.com>

On Thu, 18 May 2023 10:31:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
> > > 
> > > 
> > > Sure, I will run this test. Thanks!
> > 
> > 
> > There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
> 
> With -XX:-TieredCompilation I see following crash right at the start for the regression run, looks like we need to handle [mask type value during rematerialization.](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144)
> 
> [hs_err_pid718455.log](https://github.com/openjdk/valhalla/files/11506850/hs_err_pid718455.log)

Right! I missed the deoptimization part when I was doing the VectorMask integration. In my VectorShuffle changes, I'v changed all these relative code. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1553875322


From xgong at openjdk.org  Fri May 19 04:04:14 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 19 May 2023 04:04:14 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v3]
In-Reply-To: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
Message-ID: <-Z0VZ_2twFaRohpWbm0l8bDL0Ou8oY8vzvH_x5a0zH0=.56293574-56a9-4bde-ba41-5ce81ad7f2c0@github.com>

> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
> 
> Java side changes include:
>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>  - Move several VectorMask default operations to the abstract super class.
>  - Minor code cleanup.
> 
> Compiler changes include:
>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>  - Minor code cleanup.
> 
> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
> and the basic unit tests work well after enabling vector support.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Use value/primitive classes for VectorShuffle, cleanup and issue fixes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/845/files
  - new: https://git.openjdk.org/valhalla/pull/845/files/dadedbe2..2cb15e66

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

  Stats: 2335 lines in 48 files changed: 476 ins; 1126 del; 733 mod
  Patch: https://git.openjdk.org/valhalla/pull/845.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/845/head:pull/845

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


From xgong at openjdk.org  Fri May 19 04:04:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 19 May 2023 04:04:15 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v2]
In-Reply-To: <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
Message-ID: <jtU1M1y3bEFpkU2QM6dD8BB7Nm2kAFCEhhGD-rVnx9s=.7c4cf845-5367-4cb5-9c05-d2d7b50d591f@github.com>

On Wed, 17 May 2023 09:07:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract super class.
>>  - Minor code cleanup.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue when the boxed type is not equal to the intrinsic return type

The latest commit adds the VectorShuffle support after integrating with value/primitive classes. Besides the basic java code and hotspot compiler changes, it also fixes several jtreg failures and do more code clean up to unused legacy code in hotspot.

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1553961873


From xgong at openjdk.org  Fri May 19 06:09:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 19 May 2023 06:09:15 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v2]
In-Reply-To: <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
 <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
Message-ID: <xDLcp8rSvOnfqeCpjU3iuzMHg7s6oVQD-XrdjLM_YdI=.ccf338fc-830d-475c-a227-8df44d709217@github.com>

On Thu, 18 May 2023 10:31:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>>> > 
>>> > 
>>> > Sure, I will run this test. Thanks!
>>> 
>>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
>> 
>> 
>> 
>>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>>> > 
>>> > 
>>> > Sure, I will run this test. Thanks!
>>> 
>>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
>> 
>> I saw some failures with -XX:TieredStopAtLevel=3 which is C1 compilation, I am not sure if they are related to de-optimization. 
>> Attaching relevant hs_err log.
>> [hs_err_pid717512.log](https://github.com/openjdk/valhalla/files/11506800/hs_err_pid717512.log)
>
>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>> > 
>> > 
>> > Sure, I will run this test. Thanks!
>> 
>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
> 
> With -XX:-TieredCompilation I see following crash right at the start for the regression run, looks like we need to handle [mask type value during rematerialization.](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144)
> 
> [hs_err_pid718455.log](https://github.com/openjdk/valhalla/files/11506850/hs_err_pid718455.log)

Hi @jatin-bhateja , could you please help to run and test whether the issue you met is fixed with the latest commit? I met other regressions and am working in progress to see what is going on. Thanks a lot!

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1554056248


From xgong at openjdk.org  Fri May 19 07:12:26 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 19 May 2023 07:12:26 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v4]
In-Reply-To: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
Message-ID: <NpEKlDRiho4O_-Tl3jfTIQz6LR1SSI5vxsNsJgLEpBE=.d8c748cb-2344-4400-b474-1f0ef7e8fa44@github.com>

> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
> 
> Java side changes include:
>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>  - Move several VectorMask default operations to the abstract super class.
>  - Minor code cleanup.
> 
> Compiler changes include:
>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>  - Minor code cleanup.
> 
> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
> and the basic unit tests work well after enabling vector support.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/845/files
  - new: https://git.openjdk.org/valhalla/pull/845/files/2cb15e66..ca70c356

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

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

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


From tobias.hartmann at oracle.com  Fri May 19 08:08:17 2023
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 19 May 2023 10:08:17 +0200
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <c6c4dbc0-8f5b-753b-13e6-154fc4328314@oracle.com>

Vote: yes

Best regards,
Tobias

On 18.05.23 20:07, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (OpenJDK name: jbhateja) to Valhalla Committer.
> 
> Jatin is a Reviewer in JDK Project and a Committer in Panama Project. He authored numerous bug fixes
> and enhancements in C2 and Vector API.
> 
> In the context of Valhalla Project, Jatin leads the effort to migrate Vector API implementation to
> value objects and primitive values (most notably, [3] [4] [5] in lworld+vector branch [6]).
> 
> Votes are due by 2021-05-31 17:00 PST.
> 
> Only current Valhalla Committers [1] are eligible to vote
> on this nomination.? Votes must be cast in the open by replying
> to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] https://openjdk.java.net/census
> 
> [2] https://openjdk.java.net/projects/#committer-vote
> 
> [3] https://github.com/openjdk/valhalla/commit/8159184e95f67bb5ea4d3754bfcf7ab7a25a9803
> ??? 8296767: Support multi-field based vector classes.
> 
> [4] https://github.com/openjdk/valhalla/commit/d9f744fe6e816a91aa7c8d5e84ce464e8a9d3921
> ??? 8304310: Initial compilers and runtime handling for multifield backed vectors.
> 
> [5] https://github.com/jatin-bhateja/valhalla/commit/b7b7231ae76f4f2a2510dd904aa407771a70c970
> ??? 8308363: Initial compiler support for FP16 scalar operations (under review)
> 
> [6] https://github.com/openjdk/valhalla/tree/lworld+vector


From xgong at openjdk.org  Fri May 19 10:46:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 19 May 2023 10:46:27 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v5]
In-Reply-To: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
Message-ID: <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>

> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
> 
> Java side changes include:
>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>  - Move several VectorMask default operations to the abstract super class.
>  - Minor code cleanup.
> 
> Compiler changes include:
>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>  - Minor code cleanup.
> 
> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
> and the basic unit tests work well after enabling vector support.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Fix jtreg failures

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/845/files
  - new: https://git.openjdk.org/valhalla/pull/845/files/ca70c356..d34f4020

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

  Stats: 34 lines in 3 files changed: 15 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/valhalla/pull/845.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/845/head:pull/845

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


From liangchenblue at gmail.com  Sun May 21 04:21:15 2023
From: liangchenblue at gmail.com (-)
Date: Sat, 20 May 2023 23:21:15 -0500
Subject: Rebasing the JVMS/JLS revisions onto that of current release (20)
Message-ID: <CABe8uE0MOcxH3s2odhAtvfydfrC-pK3Y5sg4NR8_Hu_P0Qt-Dg@mail.gmail.com>

Hi,
Just a heads up, I am glad to see active developments in the
specification for various Valhalla JEPs on Dan's code review site
https://cr.openjdk.org/~dlsmith/jep401/jep401-20230519/

I recommend upgrading them to Java 20, as they appear to be based of
Java 16's specifications, as shown by the absence of
PermittedSubclasses attribute.

In addition, these JVMS changes for https://openjdk.org/jeps/8267650
Better-defined JVM class file validation appear quite mature already.
Is there any outstanding problem that obstructs their progress? This
would prove helpful for future Language and VM changes, just like how
Nestmates, initially aimed for generic specialization, immediately
eliminated synthetic bridge methods across inner classes for all Java
programs.

Best,
Chen Liang


From jbhateja at openjdk.org  Mon May 22 05:07:18 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 22 May 2023 05:07:18 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v2]
In-Reply-To: <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
 <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
Message-ID: <9yfISOCGIuMsolGOMbZEebxvyjtMhAQIwVg2MkdNquU=.d64b688a-17f4-4e89-9bff-c1620a7d8465@github.com>

On Thu, 18 May 2023 10:31:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>>> > 
>>> > 
>>> > Sure, I will run this test. Thanks!
>>> 
>>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
>> 
>> 
>> 
>>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>>> > 
>>> > 
>>> > Sure, I will run this test. Thanks!
>>> 
>>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
>> 
>> I saw some failures with -XX:TieredStopAtLevel=3 which is C1 compilation, I am not sure if they are related to de-optimization. 
>> Attaching relevant hs_err log.
>> [hs_err_pid717512.log](https://github.com/openjdk/valhalla/files/11506800/hs_err_pid717512.log)
>
>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>> > 
>> > 
>> > Sure, I will run this test. Thanks!
>> 
>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
> 
> With -XX:-TieredCompilation I see following crash right at the start for the regression run, looks like we need to handle [mask type value during rematerialization.](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144)
> 
> [hs_err_pid718455.log](https://github.com/openjdk/valhalla/files/11506850/hs_err_pid718455.log)

> Hi @jatin-bhateja , could you please help to run and test whether the issue you met is fixed with the latest commit? I met other regressions and am working in progress to see what is going on. Thanks a lot!

Hi @XiaohongGong,

I floated a patch to merge latest changes from lword into lworld+vector since there have been changes in InlineTypeNode IR.
https://github.com/openjdk/valhalla/pull/847

With following patch most of the JTreg tests are passing. Load/Store tests are failing because EnablePrimitiveClass not getting set with --add-modules=jdk.incubator.vector.

[regression_fixes_post_merge.txt](https://github.com/openjdk/valhalla/files/11527140/regression_fixes_post_merge.txt)

You may integrate it along with your patch to validate and avoid duplications,  alternatively, I can post this as a stand alone patch once merge patch is integrated, I see couple of more issues and in process of fixing them. 

Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1556538217


From xgong at openjdk.org  Mon May 22 06:25:18 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 22 May 2023 06:25:18 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
Message-ID: <NpThOVzNIuMpXo1B5ZKmX9H9n1GuBOWBHlCPoP6hO3Y=.816a38e9-29be-4dde-bb18-1ac512ec2344@github.com>

On Wed, 17 May 2023 13:47:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld into lworld+vector.
> 
> Please review and approve.
> 
> Best Regards,
> Jatin

LGTM!

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

Marked as reviewed by xgong (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/847#pullrequestreview-1435843327


From xgong at openjdk.org  Mon May 22 06:33:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 22 May 2023 06:33:15 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v2]
In-Reply-To: <9yfISOCGIuMsolGOMbZEebxvyjtMhAQIwVg2MkdNquU=.d64b688a-17f4-4e89-9bff-c1620a7d8465@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
 <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
 <9yfISOCGIuMsolGOMbZEebxvyjtMhAQIwVg2MkdNquU=.d64b688a-17f4-4e89-9bff-c1620a7d8465@github.com>
Message-ID: <ddWrkPCyVhnUp6d6kIfPkuCedkhtbhaWcnWJ9mnT8Q0=.717f7720-8f17-430a-99c1-f8fe5e82b6a3@github.com>

On Mon, 22 May 2023 05:04:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>>> > 
>>> > 
>>> > Sure, I will run this test. Thanks!
>>> 
>>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
>> 
>> With -XX:-TieredCompilation I see following crash right at the start for the regression run, looks like we need to handle [mask type value during rematerialization.](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144)
>> 
>> [hs_err_pid718455.log](https://github.com/openjdk/valhalla/files/11506850/hs_err_pid718455.log)
>
>> Hi @jatin-bhateja , could you please help to run and test whether the issue you met is fixed with the latest commit? I met other regressions and am working in progress to see what is going on. Thanks a lot!
> 
> Hi @XiaohongGong,
> 
> I floated a patch to merge latest changes from lword into lworld+vector since there have been changes in InlineTypeNode IR.
> https://github.com/openjdk/valhalla/pull/847
> 
> With following patch most of the JTreg tests are passing. Load/Store tests are failing because EnablePrimitiveClass not getting set with --add-modules=jdk.incubator.vector.
> 
> [regression_fixes_post_merge.txt](https://github.com/openjdk/valhalla/files/11527140/regression_fixes_post_merge.txt)
> 
> You may integrate it along with your patch to validate and avoid duplications,  alternatively, I can post this as a stand alone patch once merge patch is integrated, I see couple of more issues and in process of fixing them.  Will re-review and validate your shuffle/mask changes and share my comments.
> 
> Thanks!

> > Hi @jatin-bhateja , could you please help to run and test whether the issue you met is fixed with the latest commit? I met other regressions and am working in progress to see what is going on. Thanks a lot!
> 
> Hi @XiaohongGong,
> 
> I floated a patch to merge latest changes from lword into lworld+vector since there have been changes in InlineTypeNode IR. #847
> 
> With following patch most of the JTreg tests are passing. Load/Store tests are failing because EnablePrimitiveClass not getting set with --add-modules=jdk.incubator.vector.
> 
> [regression_fixes_post_merge.txt](https://github.com/openjdk/valhalla/files/11527140/regression_fixes_post_merge.txt)
> 
> You may integrate it along with your patch to validate and avoid duplications, alternatively, I can post this as a stand alone patch once merge patch is integrated, I see couple of more issues and in process of fixing them. Will re-review and validate your shuffle/mask changes and share my comments.
> 
> Thanks!

Hi Jatin,

Thanks for the fixing patch! I also fixed several issues in my patch, including the `InlineTypeNode` handles in `PhiNode::Ideal()`. I'm fine that you post a stand alone fixing patch. I can rebase my patch after then. 

Thanks,
Xiaohong

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1556614941


From david.simms at oracle.com  Mon May 22 09:03:34 2023
From: david.simms at oracle.com (David Simms)
Date: Mon, 22 May 2023 11:03:34 +0200
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <6007896b-949e-a3ef-f617-5de907316d2e@oracle.com>

Vote: yes

On 2023-05-18 20:07, Vladimir Ivanov wrote:
> I hereby nominate Jatin Bhateja (OpenJDK name: jbhateja) to Valhalla 
> Committer.
>
>


From tanksherman27 at gmail.com  Mon May 22 14:41:59 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Mon, 22 May 2023 22:41:59 +0800
Subject: What happened to primitive classes?
Message-ID: <CAP2b4GOaqda-hCO+U=goBOKNoLpNMM6NEsWu-D6TruJ8j2X5dw@mail.gmail.com>

Sorry if this is a silly question, but I recently browsed through
JEP-401 to find that all references to primitive classes have been
completely scrubbed, as if they were never there at all. I haven't been
keeping up to date with Valhalla lately, so I can't tell what the changes
(if any) have been. Did they move elsewhere or were they changed to
something else?

best regards,
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230522/5b47628e/attachment.htm>

From forax at univ-mlv.fr  Mon May 22 15:08:31 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 22 May 2023 17:08:31 +0200 (CEST)
Subject: What happened to primitive classes?
In-Reply-To: <CAP2b4GOaqda-hCO+U=goBOKNoLpNMM6NEsWu-D6TruJ8j2X5dw@mail.gmail.com>
References: <CAP2b4GOaqda-hCO+U=goBOKNoLpNMM6NEsWu-D6TruJ8j2X5dw@mail.gmail.com>
Message-ID: <63319410.61631771.1684768111794.JavaMail.zimbra@univ-eiffel.fr>

> From: "Julian Waters" <tanksherman27 at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Monday, May 22, 2023 4:41:59 PM
> Subject: What happened to primitive classes?

> Sorry if this is a silly question, but I recently browsed through JEP-401 to
> find that all references to primitive classes have been completely scrubbed, as
> if they were never there at all. I haven't been keeping up to date with
> Valhalla lately, so I can't tell what the changes (if any) have been. Did they
> move elsewhere or were they changed to something else?

Yes, all values classes are now nullable by default. 
The equivalent of the old primitive class is a non-nullable value class with a default instance. 

If you declare the value class Range like the first example of the JEP-401, Range! (not the '!') is what is the closest to the old primitive class. 

> best regards,
> Julian

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

From liangchenblue at gmail.com  Mon May 22 15:43:15 2023
From: liangchenblue at gmail.com (-)
Date: Mon, 22 May 2023 10:43:15 -0500
Subject: Future of primitive specialization (generics) and null-restriction
Message-ID: <CABe8uE287xX=6XvMUTDOQjF8xs5_56ybggAkQ-fRZyzVYRgv6w@mail.gmail.com>

Hello,
Since we have null-restricted types now, I have a few questions about
its implications on existing primitives and expanded generics:

1. Are Integer.TYPE (int.class) primitives etc. now the same as the
null-restricted type of Integer etc. value-type wrappers?
2. Will type parameterization like List<int> be written like
List<Integer!> (null-restricted specialization), effectively
invalidating JEP 218, as the same performance can now be achieved with
value-type parameterization in VM without invasively changing the type
hierarchy assumptions of generics? (JEP 8261529 doesn't appear updated
to the current null-restriction model)

Curious,
Chen Liang


From brian.goetz at oracle.com  Mon May 22 16:37:29 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 22 May 2023 12:37:29 -0400
Subject: What happened to primitive classes?
In-Reply-To: <63319410.61631771.1684768111794.JavaMail.zimbra@univ-eiffel.fr>
References: <CAP2b4GOaqda-hCO+U=goBOKNoLpNMM6NEsWu-D6TruJ8j2X5dw@mail.gmail.com>
 <63319410.61631771.1684768111794.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <66a7e9c1-2ee9-0c74-fe7a-e8eb6946e5fc@oracle.com>

There's a document on these shifts coming soon.

On 5/22/2023 11:08 AM, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Julian Waters" <tanksherman27 at gmail.com>
>     *To: *"valhalla-dev" <valhalla-dev at openjdk.org>
>     *Sent: *Monday, May 22, 2023 4:41:59 PM
>     *Subject: *What happened to primitive classes?
>
>     Sorry if?this is a silly question, but I recently browsed?through
>     JEP-401?to find?that all references?to primitive classes have been
>     completely scrubbed, as if?they were never?there at all. I haven't
>     been keeping up?to date with Valhalla lately, so I can't?tell
>     what?the changes (if any) have been. Did?they move elsewhere or
>     were?they changed?to something else?
>
>
> Yes, all values classes are now nullable by default.
> The equivalent of the old primitive class is a non-nullable value 
> class with a default instance.
>
> If you declare the value class Range like the first example of the 
> JEP-401, Range! (not the '!') is what is the closest to the old 
> primitive class.
>
>
>     best regards,
>     Julian
>
>
> regards,
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230522/01691095/attachment.htm>

From brian.goetz at oracle.com  Mon May 22 16:41:49 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 22 May 2023 12:41:49 -0400
Subject: Future of primitive specialization (generics) and null-restriction
In-Reply-To: <CABe8uE287xX=6XvMUTDOQjF8xs5_56ybggAkQ-fRZyzVYRgv6w@mail.gmail.com>
References: <CABe8uE287xX=6XvMUTDOQjF8xs5_56ybggAkQ-fRZyzVYRgv6w@mail.gmail.com>
Message-ID: <08912432-d9d7-b064-6171-8c48d8cb0923@oracle.com>

These are very fair questions, but its still early to answer these.? 
I'll try to sketch where we are on these questions.

1.? The previous model ("primitive classes") tried to directly model the 
int/Integer divide.? One of the supposed benefits is that the 
int/Integer distinction could go away, but as it turns out, this wasn't 
necessarily even 100% true.

The current model breaks the divide down into more fundamental 
distinctions (declaration-site initialization safety + use-site 
nullity), which is a big improvement, but makes it even less likely that 
we will truly achieve `int` being an alias for `Integer!`.? The main 
question is where to put the (now much smaller) seam; there are tradeoffs.

2.? The exact status of the legacy primitives in generics depends on 
some decisions coming out of (1), TBD.? Again, tradeoffs.

On 5/22/2023 11:43 AM, - wrote:
> Hello,
> Since we have null-restricted types now, I have a few questions about
> its implications on existing primitives and expanded generics:
>
> 1. Are Integer.TYPE (int.class) primitives etc. now the same as the
> null-restricted type of Integer etc. value-type wrappers?
> 2. Will type parameterization like List<int> be written like
> List<Integer!> (null-restricted specialization), effectively
> invalidating JEP 218, as the same performance can now be achieved with
> value-type parameterization in VM without invasively changing the type
> hierarchy assumptions of generics? (JEP 8261529 doesn't appear updated
> to the current null-restriction model)
>
> Curious,
> Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230522/385c3d49/attachment.htm>

From anhmdq at gmail.com  Mon May 22 16:47:40 2023
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Tue, 23 May 2023 00:47:40 +0800
Subject: Progress of value classes
Message-ID: <CAPvyiyJwfw8GBmh84e-wft7qQojwB5ajMu2-fC6NwtDOD+H3tg@mail.gmail.com>

Hi,

It seems to me that all of the recent discussions are about B3 classes and
the discussions regarding B2 classes have generally settled down. May I ask
if there is any blocker for Value classes to integrate into mainline and
can the JEP make it into JDK 22, or maybe JDK 21?

Thanks a lot for your answers,
Quan Anh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230523/5d5be6a0/attachment.htm>

From brian.goetz at oracle.com  Mon May 22 16:55:12 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 22 May 2023 12:55:12 -0400
Subject: Progress of value classes
In-Reply-To: <CAPvyiyJwfw8GBmh84e-wft7qQojwB5ajMu2-fC6NwtDOD+H3tg@mail.gmail.com>
References: <CAPvyiyJwfw8GBmh84e-wft7qQojwB5ajMu2-fC6NwtDOD+H3tg@mail.gmail.com>
Message-ID: <a5eb36cf-3d67-ac13-8667-565a35d2f69a@oracle.com>

 From a *design* perspective, you are correct that most of the 
discussion has been on "B3" classes, which raises the reasonable 
question of "can we ship B2 while this discussion plays out."? For a 
long time, we've felt uncomfortable doing so, because until we had a 
reasonable story for B3 in which we had high confidence, the risk of a 
premature B2 release constraining the bigger story was still high.

We feel now that we're approaching the point where the B3 story is 
converging to the desired confidence level that B2 will not be 
destabilized.? So we're able to proceed more directly on that.

As to scheduling, the answer is as always: it's ready when it's ready.? 
Even though the design has settled, there is still specification, 
implementation, and testing work to do, so it will take some more time.? 
But I think this train can start moving faster soon.? It's not that 
there are "blockers", but there is plenty of work.

On 5/22/2023 12:47 PM, Qu?n Anh Mai wrote:
> Hi,
>
> It seems to me that all of the recent discussions are about B3 classes 
> and the discussions regarding B2 classes have generally settled down. 
> May I ask if?there is any blocker for Value classes to integrate into 
> mainline and can the JEP make it into JDK 22,?or maybe JDK 21?
>
> Thanks a lot for your answers,
> Quan Anh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230522/16a363d6/attachment.htm>

From forax at univ-mlv.fr  Mon May 22 17:02:05 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 22 May 2023 19:02:05 +0200 (CEST)
Subject: Future of primitive specialization (generics) and null-restriction
In-Reply-To: <CABe8uE287xX=6XvMUTDOQjF8xs5_56ybggAkQ-fRZyzVYRgv6w@mail.gmail.com>
References: <CABe8uE287xX=6XvMUTDOQjF8xs5_56ybggAkQ-fRZyzVYRgv6w@mail.gmail.com>
Message-ID: <1582821438.61821974.1684774925688.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "-" <liangchenblue at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Monday, May 22, 2023 5:43:15 PM
> Subject: Future of primitive specialization (generics) and null-restriction

> Hello,
> Since we have null-restricted types now, I have a few questions about
> its implications on existing primitives and expanded generics:
> 
> 1. Are Integer.TYPE (int.class) primitives etc. now the same as the
> null-restricted type of Integer etc. value-type wrappers?

Conceptually, they are not the same, Integer! is a subtype of Object while int is not.
We want to try to unified them but it won't be easy :)

> 2. Will type parameterization like List<int> be written like
> List<Integer!> (null-restricted specialization), effectively
> invalidating JEP 218, as the same performance can now be achieved with
> value-type parameterization in VM without invasively changing the type
> hierarchy assumptions of generics? (JEP 8261529 doesn't appear updated
> to the current null-restriction model)

It's still in flux.

List<int> is a kind of reification of List<Integer!> where the parametrized class also have bridges to convert from Integer! to int.
So a simple first approach is to only allow List<int> when you inherit/implement a class/interface.

i.e.
  class IntStream implements Stream<int> { ... }  // Ok
  List<int> list;  // Ok
  var list = new ArrayList<int>();  // Not ok
  var list2 = new ArrayList<int>() {};  // Ok
  var list3 = (List<int>) ...  // Not ok, no way to check if bridges are present at runtime
  var list4 = (List<Integer!>) ... // unchecked cast but Ok
  
 
It means that int is a subtype of Integer! when overriding.
We can not go in the other direction due to a limitation of how the bridges work in case of separate compilations.

And we also need some VM magic so Integer![] is seens as an int[] at runtime, when "new T[size]" is specialized with T=int, so at least, iaload/iastore + checkcast needs to work on an Integer![].
int[] and Integer![] are different classes, but it's the same layout in memory.

> 
> Curious,
> Chen Liang

regards,
R?mi


From jbhateja at openjdk.org  Mon May 22 17:15:57 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 22 May 2023 17:15:57 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16 scalar
 operations.
Message-ID: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>

Starting with 4th Generation Xeon, Intel has made extensive extensions to existing ISA to support 16 bit scalar and vector floating point operations based on IEEE 754 FP16 format.

We plan to support this in multiple stages spanning across Java side definition of Float16 type, scalar operation and finally SLP vectorization support.

This patch adds  minimal Java and Compiler side support for one API Float16.add.

Following is the gist of changes introduced with the patch :-

- Minimal implementation of Float16 primitive class supporting one operation (Float16.add)
- X86 AVX512-FP16 feature detection at VM startup.
- C2 IR and Inline expander changes for Float16.add API.
- FP16 constant folding handling.
- Backend support : Instruction selection patterns and assembler support.

Please review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - 8308363: Initial compiler support for FP16 scalar operations.

Changes: https://git.openjdk.org/valhalla/pull/848/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308363
  Stats: 1413 lines in 22 files changed: 1404 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/848.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/848/head:pull/848

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


From lois.foltan at oracle.com  Mon May 22 17:18:28 2023
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 22 May 2023 17:18:28 +0000
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <BLAPR10MB51560E4E646AB13C7FDC32F08A439@BLAPR10MB5156.namprd10.prod.outlook.com>

Vote: yes

Lois

From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date: Thursday, May 18, 2023 at 2:07 PM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Jatin Bhateja
I hereby nominate Jatin Bhateja (OpenJDK name: jbhateja) to Valhalla
Committer.

Jatin is a Reviewer in JDK Project and a Committer in Panama Project. He
authored numerous bug fixes and enhancements in C2 and Vector API.

In the context of Valhalla Project, Jatin leads the effort to migrate
Vector API implementation to value objects and primitive values (most
notably, [3] [4] [5] in lworld+vector branch [6]).

Votes are due by 2021-05-31 17:00 PST.

Only current Valhalla Committers [1] are eligible to vote
on this nomination.  Votes must be cast in the open by replying
to this mailing list.

For Lazy Consensus voting instructions, see [2].

Best regards,
Vladimir Ivanov

[1] https://openjdk.java.net/census

[2] https://openjdk.java.net/projects/#committer-vote

[3]
https://github.com/openjdk/valhalla/commit/8159184e95f67bb5ea4d3754bfcf7ab7a25a9803
     8296767: Support multi-field based vector classes.

[4]
https://github.com/openjdk/valhalla/commit/d9f744fe6e816a91aa7c8d5e84ce464e8a9d3921
     8304310: Initial compilers and runtime handling for multifield
backed vectors.

[5]
https://github.com/jatin-bhateja/valhalla/commit/b7b7231ae76f4f2a2510dd904aa407771a70c970
     8308363: Initial compiler support for FP16 scalar operations (under
review)

[6] https://github.com/openjdk/valhalla/tree/lworld+vector
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230522/adaa5952/attachment.htm>

From serguei.spitsyn at oracle.com  Mon May 22 21:00:14 2023
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Mon, 22 May 2023 21:00:14 +0000
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <BY5PR10MB4324B4EEE7086ABB5A42D3B78D439@BY5PR10MB4324.namprd10.prod.outlook.com>

Voye: yes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230522/fe78828c/attachment.htm>

From dsimms at openjdk.org  Tue May 23 06:19:40 2023
From: dsimms at openjdk.org (David Simms)
Date: Tue, 23 May 2023 06:19:40 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <AtH9u7BSxylVJYmhWlC9IZU4EuZzbtqXJNMYyaynm9g=.41255ec4-b618-4f30-ae52-6636b968396d@github.com>

Merge from jdk-21+5 to jdk-21+10

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

Commit messages:
 - Adjust for new code
 - Merge tag 'jdk-21+10' into lworld_merge_jdk_incr_from_21_5
 - 8302163: Speed up various String comparison methods with ArraysSupport.mismatch
 - 8301460: Clean up LambdaForm to reference BasicType enums directly
 - 8302127: Remove unused arg in write_ref_field_post
 - 8301225: Replace NULL with nullptr in share/gc/shenandoah/
 - 8301700: Increase the default TLS Diffie-Hellman group size from 1024-bit to 2048-bit
 - 8301463: Code in DatagramSocket still refers to resolved JDK-8237352
 - 8302325: Wrong comment in java.base/share/native/libjimage/imageFile.hpp
 - 8300808: Accelerate Base64 on x86 for AVX2
 - ... and 568 more: https://git.openjdk.org/valhalla/compare/131a3cee...10a88e5b

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=846&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=846&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/846/files
  Stats: 108987 lines in 3476 files changed: 45110 ins; 24744 del; 39133 mod
  Patch: https://git.openjdk.org/valhalla/pull/846.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/846/head:pull/846

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


From dsimms at openjdk.org  Tue May 23 06:19:42 2023
From: dsimms at openjdk.org (David Simms)
Date: Tue, 23 May 2023 06:19:42 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <AtH9u7BSxylVJYmhWlC9IZU4EuZzbtqXJNMYyaynm9g=.41255ec4-b618-4f30-ae52-6636b968396d@github.com>
References: <AtH9u7BSxylVJYmhWlC9IZU4EuZzbtqXJNMYyaynm9g=.41255ec4-b618-4f30-ae52-6636b968396d@github.com>
Message-ID: <sCrLhtfRluxwjR0TCVCE_5nvlaFIqo9VHMphaUPoWGo=.efbd040b-d74e-4356-a4a9-c90bcc3b96bc@github.com>

On Wed, 17 May 2023 12:48:14 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge from jdk-21+5 to jdk-21+10

This pull request has now been integrated.

Changeset: fc300fa9
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/fc300fa9c5795b9376e1df87f39f0de1a9020a0b
Stats:     108987 lines in 3476 files changed: 45110 ins; 24744 del; 39133 mod

Merge jdk

Merge from jdk-21+5 to jdk-21+10

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

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


From xgong at openjdk.org  Tue May 23 15:25:56 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 23 May 2023 15:25:56 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v2]
In-Reply-To: <9yfISOCGIuMsolGOMbZEebxvyjtMhAQIwVg2MkdNquU=.d64b688a-17f4-4e89-9bff-c1620a7d8465@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
 <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
 <9yfISOCGIuMsolGOMbZEebxvyjtMhAQIwVg2MkdNquU=.d64b688a-17f4-4e89-9bff-c1620a7d8465@github.com>
Message-ID: <xYgOZ6DdShFEhADb3pJnt0ok1m7BjA7B3cl4OhBsobw=.7014a7fc-a373-45a2-b057-c4d02cea7f7c@github.com>

On Mon, 22 May 2023 05:04:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>>> > 
>>> > 
>>> > Sure, I will run this test. Thanks!
>>> 
>>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
>> 
>> With -XX:-TieredCompilation I see following crash right at the start for the regression run, looks like we need to handle [mask type value during rematerialization.](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144)
>> 
>> [hs_err_pid718455.log](https://github.com/openjdk/valhalla/files/11506850/hs_err_pid718455.log)
>
>> Hi @jatin-bhateja , could you please help to run and test whether the issue you met is fixed with the latest commit? I met other regressions and am working in progress to see what is going on. Thanks a lot!
> 
> Hi @XiaohongGong,
> 
> I floated a patch to merge latest changes from lword into lworld+vector since there have been changes in InlineTypeNode IR.
> https://github.com/openjdk/valhalla/pull/847
> 
> With following patch most of the JTreg tests are passing. Load/Store tests are failing because EnablePrimitiveClass not getting set with --add-modules=jdk.incubator.vector.
> 
> [regression_fixes_post_merge.txt](https://github.com/openjdk/valhalla/files/11527140/regression_fixes_post_merge.txt)
> 
> You may integrate it along with your patch to validate and avoid duplications,  alternatively, I can post this as a stand alone patch once merge patch is integrated, I see couple of more issues and in process of fixing them.  Will re-review and validate your shuffle/mask changes and share my comments.
> 
> Thanks!

Hi @jatin-bhateja ,

I'm sorry that I forgot to tell you that there are several fixes in this PR, which may conflict with your fixing. Could you please help to review this patch and do the testing? It will be better if this patch can be merged soon, so that we can have a whole testing and bug fixing based on it.

Thanks,
Xiaohong

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1558969198


From mandy.chung at oracle.com  Tue May 23 16:25:13 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Tue, 23 May 2023 09:25:13 -0700
Subject: CFV: New Valhalla Committer: Jatin Bhateja
In-Reply-To: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
References: <6eba0389-b436-2632-6c6f-0e0e4da6d1dc@oracle.com>
Message-ID: <b97665e5-cc66-42a0-a83b-8fae05763a4d@oracle.com>

Vote: yes

Mandy



From jbhateja at openjdk.org  Wed May 24 05:47:14 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 24 May 2023 05:47:14 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v5]
In-Reply-To: <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
Message-ID: <C2nstGSv6TEaUGXjMQosrWK3VTJHJZ0Sg_Fji7MrzI0=.2bd5ed9a-34c0-4be0-8fe8-b2e5c24511e7@github.com>

On Fri, 19 May 2023 10:46:27 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract super class.
>>  - Minor code cleanup.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jtreg failures

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

> 306:   Node* klass_node = kit.makecon(TypeKlassPtr::make(vk));
> 307:   Node* alloc_oop  = kit.new_instance(klass_node, NULL, NULL, /* deoptimize_on_exception */ true, vector);
> 308:   vector->store(&kit, alloc_oop, alloc_oop, vk);

Do you think we should allocate explicit payload for non-flattened case before calling InlineTypeNode::store.
As per following 
https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L768
Flattening depends on InlineFieldMaxFlatSize (default 128 bytes so fine for current vectors) but its configurable and value can be reduced.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1203470184


From lomakin.andrey at gmail.com  Wed May 24 06:54:00 2023
From: lomakin.andrey at gmail.com (Andrey Lomakin)
Date: Wed, 24 May 2023 08:54:00 +0200
Subject: Usage of stack pointers
Message-ID: <CAJmD-=6TvyZpsCDwxM7qhOg_W4mm1=GQXHVjK1L7WzytgPxOPg@mail.gmail.com>

Hi guys.

I don't know whether it is the correct mailing list to ask, but I will try
it.

If I got JEP correctly, value objects are inlined in case of usage of the
C2 compiler if they are passed as function arguments. It means that we will
have an overhead of copying data. So likely, this optimization will depend
on the size of the value object. But what about passing the stack pointer
with the ability to convert stack-based value objects into heap objects if
the passed references leak the called method?

Are such optimizations considered or possible?

-- 
Best regards,
Andrii Lomakin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230524/e4684cf6/attachment.htm>

From jbhateja at openjdk.org  Wed May 24 08:16:19 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 24 May 2023 08:16:19 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v5]
In-Reply-To: <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
Message-ID: <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>

On Fri, 19 May 2023 10:46:27 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract super class.
>>  - Minor code cleanup.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix jtreg failures

src/hotspot/share/opto/cfgnode.cpp line 2574:

> 2572:         }
> 2573:         const Type* t = phase->type(n);
> 2574:         if (n->is_InlineType() && !n->is_VectorBox() && (vk == NULL || vk == t->inline_klass())) {

We should do an upfront check for VectorBoxes to set can_optimize to false on line#2545 so that we never invoke _push_inline_types_through_ , it creates a new InlineTypeNode whose Oop fields may get stitched to VBAs, anyways we have a seperate routine for Phi handling _merge_through_phi_,

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

> 446:           Matcher::match_rule_supported_vector(VectorNode::replicate_opcode(bt), vec_len, bt)) {
> 447:           value = kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, Type::get_const_type(field->type()), false));
> 448:         }

It may be needed for constant oops (gvn.zerocon(T_PRIMITIVE_OBJECT)) as created on following line.
Otherwise it may result into semantically incorrect IR which tries to load a vector from a constant.

src/hotspot/share/opto/library_call.cpp line 2323:

> 2321:       if (alloc != NULL) {
> 2322:         assert(alloc->_larval, "InlineType instance must be in _larval state for unsafe put operation.\n");
> 2323:       }

Larval bit check is needed to preserve the semantics of value objects which can be mutated only if its _larval bit is set,  allocation expansion explicitly generates IR to set this information in the mark word.  We should add a FIXME over if condition.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1203504921
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1203545309
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1203551961


From jbhateja at openjdk.org  Wed May 24 08:30:17 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 24 May 2023 08:30:17 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v2]
In-Reply-To: <9yfISOCGIuMsolGOMbZEebxvyjtMhAQIwVg2MkdNquU=.d64b688a-17f4-4e89-9bff-c1620a7d8465@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
 <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
 <9yfISOCGIuMsolGOMbZEebxvyjtMhAQIwVg2MkdNquU=.d64b688a-17f4-4e89-9bff-c1620a7d8465@github.com>
Message-ID: <PLUOqGB8CPQCMSkWVTmzluLuH13cCy3I54zNS-Ev1WM=.a5c7efb3-49b6-41fb-bff2-fd1284ee60ab@github.com>

On Mon, 22 May 2023 05:04:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > > I am seeing some new regression failures with -XX:TieredStopAtLevel=3 and -XX:-TieredCompilation. Can you kindly check. Relevant test : Float256VectorTest.java.
>>> > 
>>> > 
>>> > Sure, I will run this test. Thanks!
>>> 
>>> There are some failures that are related to the `larval` state check, and deoptimization issue for a multifield, which I think is not related this patch. And I have created a local fix to the multifield deoptimization issue and will push it in future. Besides, did you see any other known failures before? Thanks!
>> 
>> With -XX:-TieredCompilation I see following crash right at the start for the regression run, looks like we need to handle [mask type value during rematerialization.](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144)
>> 
>> [hs_err_pid718455.log](https://github.com/openjdk/valhalla/files/11506850/hs_err_pid718455.log)
>
>> Hi @jatin-bhateja , could you please help to run and test whether the issue you met is fixed with the latest commit? I met other regressions and am working in progress to see what is going on. Thanks a lot!
> 
> Hi @XiaohongGong,
> 
> I floated a patch to merge latest changes from lword into lworld+vector since there have been changes in InlineTypeNode IR.
> https://github.com/openjdk/valhalla/pull/847
> 
> With following patch most of the JTreg tests are passing. Load/Store tests are failing because EnablePrimitiveClass not getting set with --add-modules=jdk.incubator.vector.
> 
> [regression_fixes_post_merge.txt](https://github.com/openjdk/valhalla/files/11527140/regression_fixes_post_merge.txt)
> 
> You may integrate it along with your patch to validate and avoid duplications,  alternatively, I can post this as a stand alone patch once merge patch is integrated, I see couple of more issues and in process of fixing them.  Will re-review and validate your shuffle/mask changes and share my comments.
> 
> Thanks!

> Hi @jatin-bhateja ,
> 
> I'm sorry that I forgot to tell you that there are several fixes in this PR, which may conflict with your fixing. Could you please help to review this patch and do the testing? It will be better if this patch can be merged soon, so that we can have a whole testing and bug fixing based on it.
> 
> Thanks, Xiaohong

Hi @XiaohongGong ,
I went over entire patch and added few comments, overall the patch looks good to me.

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1560674092


From dsimms at openjdk.org  Wed May 24 08:51:39 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 24 May 2023 08:51:39 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <Cjtz3PDjxHR-ZGQjQNnnXHSQXUuAL6cv6Vta5x_kJ3g=.bfde5e26-94ef-4d52-9929-361ad6ba1480@github.com>

Merge tags
* 'jdk-21+11'
* 'jdk-21+12'
* 'jdk-21+13'

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

Commit messages:
 - Merge tag 'jdk-21+13' into lworld_merge_jdk_incr_from_21_10
 - 8171156: Class java.util.LocaleISOData has outdated information for country Code NP
 - 8299570: [JVMCI] Insufficient error handling when CodeBuffer is exhausted
 - 8303833: java.util.LocaleISOData has wrong comments for 'Norwegian Bokm?l' and 'Volap?k'
 - 8303839: [BACKOUT] JDK-8302799 and JDK-8302189
 - 8282201: Consider removal of expiry check in VerifyCACerts.java test
 - 8302508: Add timestamp to the output TraceCompilerThreads
 - 8302161: Upgrade jQuery UI to version 1.13.2
 - 8303617: update for deprecated sprintf for jdk.jdwp.agent
 - 8303605: Memory leaks in Metaspace gtests
 - ... and 297 more: https://git.openjdk.org/valhalla/compare/fc300fa9...169bff1f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=849&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=849&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/849/files
  Stats: 40515 lines in 1433 files changed: 25757 ins; 7851 del; 6907 mod
  Patch: https://git.openjdk.org/valhalla/pull/849.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/849/head:pull/849

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


From dsimms at openjdk.org  Wed May 24 08:51:41 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 24 May 2023 08:51:41 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <Cjtz3PDjxHR-ZGQjQNnnXHSQXUuAL6cv6Vta5x_kJ3g=.bfde5e26-94ef-4d52-9929-361ad6ba1480@github.com>
References: <Cjtz3PDjxHR-ZGQjQNnnXHSQXUuAL6cv6Vta5x_kJ3g=.bfde5e26-94ef-4d52-9929-361ad6ba1480@github.com>
Message-ID: <G5bP86wqUM0XUS7gFeGngtV4iLmj0Wa3Cx-CUqYxAxk=.ea1bbd9e-2ac2-4094-be95-5d63c6147222@github.com>

On Wed, 24 May 2023 08:38:27 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tags
> * 'jdk-21+11'
> * 'jdk-21+12'
> * 'jdk-21+13'

This pull request has now been integrated.

Changeset: 8d229049
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8d2290498b59ad2f07418538ab90433e005d587e
Stats:     40515 lines in 1433 files changed: 25757 ins; 7851 del; 6907 mod

Merge jdk

Merge jdk-21+11, jdk-21+12 and jdk-21+13

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

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


From dsimms at openjdk.org  Wed May 24 13:52:31 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 24 May 2023 13:52:31 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <PgCrWq2cMQJo3iltgPL03o0Vklq5YikF5l_p7DxBqss=.113ab6d2-9483-4e11-9fe3-13fa7fae6658@github.com>

Merge jdk-21+14

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

Commit messages:
 - Problem list classfile and jshell issues
 - Merge jdk-21+14
 - Logical merge fixed Metadata.EMPTY removed
 - Logic merge fix: flush_dependents_on_method was removed
 - Merge tag 'jdk-21+14' into lworld_merge_jdk_incr_from_21_10
 - 8303022: "assert(allocates2(pc)) failed: not in CodeBuffer memory" When linking downcall handle
 - 8304264: Debug messages always show up for NativeGSS
 - 8304287: Problemlist java/net/SocketOption/OptionsTest.java
 - 8304267: JDK-8303415 missed change in Zero Interpreter
 - 8284047: Harmonize/Standardize the SSLSocket/SSLEngine/SSLSocketSSLEngine test templates
 - ... and 101 more: https://git.openjdk.org/valhalla/compare/8d229049...4be3702a

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=850&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=850&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/850/files
  Stats: 135677 lines in 1148 files changed: 99707 ins; 21378 del; 14592 mod
  Patch: https://git.openjdk.org/valhalla/pull/850.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/850/head:pull/850

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


From dsimms at openjdk.org  Wed May 24 13:52:33 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 24 May 2023 13:52:33 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <PgCrWq2cMQJo3iltgPL03o0Vklq5YikF5l_p7DxBqss=.113ab6d2-9483-4e11-9fe3-13fa7fae6658@github.com>
References: <PgCrWq2cMQJo3iltgPL03o0Vklq5YikF5l_p7DxBqss=.113ab6d2-9483-4e11-9fe3-13fa7fae6658@github.com>
Message-ID: <sxRmb5gyNFTcR06QG6pyFfTNNyu7Lx8CmVRuSDwzE7s=.2e2ef821-c96d-4835-a184-1349bf08e0e1@github.com>

On Wed, 24 May 2023 13:36:52 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-21+14

This pull request has now been integrated.

Changeset: 8367d288
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8367d28821c6e5328822544a5594d05855fad32b
Stats:     135677 lines in 1148 files changed: 99707 ins; 21378 del; 14592 mod

Merge jdk

Merge jdk-21+14

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

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


From liangchenblue at gmail.com  Wed May 24 17:52:53 2023
From: liangchenblue at gmail.com (-)
Date: Wed, 24 May 2023 12:52:53 -0500
Subject: Non-atomicity field questions
Message-ID: <CABe8uE0cem8o_B4-fYQsG-VUC1N3g2D3DCAoKCQjiSx5UaDXmQ@mail.gmail.com>

Hello, quick question:
If there's a nullable reference field in a null-restricted non-atomic value
class, is this possible:
1. Declare a reference field, like a String, without heap pollution
concerns;
2. Limit the values of fields (of course, permit zero-default values) for
all instances of this class, such as nonnegative long field, null or String
reference containing no tabs, etc.
This requires constructors to be executed for non-default instance
creation, but individual field validation is independent, and valid object
state is still the cartesian product of valid individual field states.

If these two features are present in null-restricted non-atomic value
classes, it will make those classes very useful. If not, it's a good lesson
against misuse of such classes.

Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230524/6108a960/attachment.htm>

From brian.goetz at oracle.com  Wed May 24 18:48:19 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 24 May 2023 14:48:19 -0400
Subject: Non-atomicity field questions
In-Reply-To: <CABe8uE0cem8o_B4-fYQsG-VUC1N3g2D3DCAoKCQjiSx5UaDXmQ@mail.gmail.com>
References: <CABe8uE0cem8o_B4-fYQsG-VUC1N3g2D3DCAoKCQjiSx5UaDXmQ@mail.gmail.com>
Message-ID: <43a963df-b903-a6ca-13bb-e35242bb69d1@oracle.com>



On 5/24/2023 1:52 PM, - wrote:
> Hello, quick question:
> If there's a nullable reference field in a null-restricted non-atomic 
> value class, is this possible:

We don't null-restrict classes, we null-restrict variables.? So I think 
the above pencils out to:

 ??? __non-atomic value class X {
 ??????? public String? s;

 ??????? public implicit X();
 ??????? public X(String! s) { this.s = s; }
 ??? }

 ??? X! x;

right?

> 1. Declare a reference field, like a String, without heap pollution 
> concerns;
> 2. Limit the values of fields (of course, permit zero-default values) 
> for all instances of this class, such as nonnegative long field, null 
> or String reference containing no tabs, etc.

If I understand your question, you want to impose representational 
invariants, with the proviso that the zero-default representation is 
always valid.? To do so, you can declare an implicit constructor (which 
produces the zero-default value) and an explicit constructor which does 
the plain vanilla argument validation / mapping to representation that 
constructors always do.

> This requires constructors to be executed for non-default instance 
> creation, but individual field validation is independent, and valid 
> object state is still the cartesian product of valid individual field 
> states.

The role of a constructor is to establish an object's state consistent 
with its invariants.? But some invariants are per-field, and some are 
cross-field:

 ??? class NonNegativeInt {
 ??????? // per-field invariants
 ??????? NonNegativeInt(int i) {
 ??????????? if (i < 0) throw ...
 ??????????? this.i = i;
 ??????? }
 ??? }

 ??? class Range {
 ??????? // cross-field invariant
 ??????? Range(int lo, int hi) {
 ???????????? if (lo > hi) throw ...
 ???????????? ...
 ??????? }
 ??? }

The choice to accept non-atomicity should include "no cross-field 
invariants", since a non-atomic value could tear under race.? Plenty of 
classes, though, are more like NonNegativeInt than Range.

Does this answer your question?


From liangchenblue at gmail.com  Wed May 24 19:38:52 2023
From: liangchenblue at gmail.com (-)
Date: Wed, 24 May 2023 14:38:52 -0500
Subject: Non-atomicity field questions
In-Reply-To: <ea4a889d-7141-b38c-9148-6a0a56da3d3c@oracle.com>
References: <CABe8uE0cem8o_B4-fYQsG-VUC1N3g2D3DCAoKCQjiSx5UaDXmQ@mail.gmail.com>
 <43a963df-b903-a6ca-13bb-e35242bb69d1@oracle.com>
 <CABe8uE0KCVd8PU4yVELdgOJAvSZqRg6M82nez=hX+Aq+gqyQtA@mail.gmail.com>
 <ea4a889d-7141-b38c-9148-6a0a56da3d3c@oracle.com>
Message-ID: <CABe8uE2OAUnWTm24GL0Ya_hz0Cm+3zrUo8AZg9hOB9kdv-gUvw@mail.gmail.com>

Oops, sorry!

On Wed, May 24, 2023, 2:16 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Did you mean to reply off-list?
>
> On 5/24/2023 3:11 PM, - wrote:
>
>
>
> On Wed, May 24, 2023, 1:48 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>>
>>
>> On 5/24/2023 1:52 PM, - wrote:
>> > Hello, quick question:
>> > If there's a nullable reference field in a null-restricted non-atomic
>> > value class, is this possible:
>>
>> We don't null-restrict classes, we null-restrict variables.  So I think
>> the above pencils out to:
>>
>>      __non-atomic value class X {
>>          public String? s;
>>
>>          public implicit X();
>>          public X(String! s) { this.s = s; }
>>      }
>>
>>      X! x;
>>
>> right?
>>
>
> Yes. The field will be a reference than inlined as values. The constructor
> can be null-friendly in my question as well.
>
>>
>> > 1. Declare a reference field, like a String, without heap pollution
>> > concerns;
>> > 2. Limit the values of fields (of course, permit zero-default values)
>> > for all instances of this class, such as nonnegative long field, null
>> > or String reference containing no tabs, etc.
>>
>> If I understand your question, you want to impose representational
>> invariants, with the proviso that the zero-default representation is
>> always valid.  To do so, you can declare an implicit constructor (which
>> produces the zero-default value) and an explicit constructor which does
>> the plain vanilla argument validation / mapping to representation that
>> constructors always do.
>>
>
> That is exactly what I am looking for. Great!
>
>>
>> > This requires constructors to be executed for non-default instance
>> > creation, but individual field validation is independent, and valid
>> > object state is still the cartesian product of valid individual field
>> > states.
>>
>> The role of a constructor is to establish an object's state consistent
>> with its invariants.  But some invariants are per-field, and some are
>> cross-field:
>>
>>      class NonNegativeInt {
>>          // per-field invariants
>>          NonNegativeInt(int i) {
>>              if (i < 0) throw ...
>>              this.i = i;
>>          }
>>      }
>>
>>      class Range {
>>          // cross-field invariant
>>          Range(int lo, int hi) {
>>               if (lo > hi) throw ...
>>               ...
>>          }
>>      }
>>
>> The choice to accept non-atomicity should include "no cross-field
>> invariants", since a non-atomic value could tear under race.  Plenty of
>> classes, though, are more like NonNegativeInt than Range.
>>
>> Does this answer your question?
>>
>
> Yes. Thank you so much, I indeed just need per-field invariants to hold
> true. The ability to have per-field invariants and nullable object
> reference fields in these classes also makes me think the current name,
> null-restricted (non-atomic) value classes is indeed a better name than
> primitive classes, which suggests behaviors in contrary to the two you've
> confirmed here.
>
> Chen Liang
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230524/91caef05/attachment.htm>

From xgong at openjdk.org  Thu May 25 02:02:19 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 02:02:19 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v5]
In-Reply-To: <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
Message-ID: <VEilWkkeaUcDhL2ycb4Ft_9rURAlsds41XFGvM0FN0I=.8d0a53d2-a3a8-4546-8db3-097a69dc13d3@github.com>

On Wed, 24 May 2023 06:19:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix jtreg failures
>
> src/hotspot/share/opto/cfgnode.cpp line 2574:
> 
>> 2572:         }
>> 2573:         const Type* t = phase->type(n);
>> 2574:         if (n->is_InlineType() && !n->is_VectorBox() && (vk == NULL || vk == t->inline_klass())) {
> 
> We should do an upfront check for VectorBoxes to set can_optimize to false on line#2545 so that we never invoke _push_inline_types_through_ , it creates a new InlineTypeNode whose Oop fields may get stitched to VBAs, anyways we have a seperate routine for Phi handling _merge_through_phi_,

Agree, I will change this as what you'v changed in your attached patch. Thanks!

> src/hotspot/share/opto/vector.cpp line 308:
> 
>> 306:   Node* klass_node = kit.makecon(TypeKlassPtr::make(vk));
>> 307:   Node* alloc_oop  = kit.new_instance(klass_node, NULL, NULL, /* deoptimize_on_exception */ true, vector);
>> 308:   vector->store(&kit, alloc_oop, alloc_oop, vk);
> 
> Do you think we should explicitly allocate payload for non-flattened case before calling InlineTypeNode::store.
> As per following 
> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L768
> Flattening depends on InlineFieldMaxFlatSize (default 128 bytes so fine for current vectors) but its configurable and value can be reduced.

Yes, allocating a buffer is needed. And the `InlineTypeNode::store()` can handled such cases. If the field type is an inline type and is not flattened, it goes to https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L518, which will create a buffer for the InlineTypeNode. Please see: https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/graphKit.cpp#L1656

I also tested the case with `-XX:InlineFieldMaxFlatSize=0` to force it not be flattened. The VectorBox expanding code is the expected one like before, which includes both the payload buffer and vector buffer and the relative stores. 

BTW, currently this flag cannot work well since there is issue when handling this option. You may need to apply the following changes when testing:

diff --git a/src/hotspot/share/classfile/fieldLayoutBuilder.cpp b/src/hotspot/share/classfile/fieldLayoutBuilder.cpp
index 516ad9bb7..538f31ae6 100644
--- a/src/hotspot/share/classfile/fieldLayoutBuilder.cpp
+++ b/src/hotspot/share/classfile/fieldLayoutBuilder.cpp
@@ -774,7 +774,7 @@ void FieldLayoutBuilder::regular_field_sorting() {
               //too_volatile_to_flatten = false; //FIXME
               // volatile fields are currently never inlined, this could change in the future
             }
-            if (!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten) || fs.access_flags().is_final()) {
+            if (!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten) && fs.access_flags().is_final()) {
               group->add_inlined_field(fs, vk);
               _nonstatic_oopmap_count += vk->nonstatic_oop_map_count();
               fs.set_inlined(true);
@@ -877,7 +877,7 @@ void FieldLayoutBuilder::inline_class_field_sorting(TRAPS) {
               //too_volatile_to_flatten = false; //FIXME
               // volatile fields are currently never inlined, this could change in the future
             }
-            if (!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten) || fs.access_flags().is_final()) {
+            if (!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten) && fs.access_flags().is_final()) {
               group->add_inlined_field(fs, vk);
               _nonstatic_oopmap_count += vk->nonstatic_oop_map_count();
               field_alignment = vk->get_alignment();


Also there are other issues when the payload is not flattened. But it seems not related to the box/unbox expanding part. I'v recorded the issues and plan to look at in future. You can also take a look if interested. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1204916621
PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1204916095


From xgong at openjdk.org  Thu May 25 02:10:16 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 02:10:16 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v5]
In-Reply-To: <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
Message-ID: <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>

On Wed, 24 May 2023 06:50:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix jtreg failures
>
> src/hotspot/share/opto/inlinetypenode.cpp line 448:
> 
>> 446:           Matcher::match_rule_supported_vector(VectorNode::replicate_opcode(bt), vec_len, bt)) {
>> 447:           value = kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, Type::get_const_type(field->type()), false));
>> 448:         }
> 
> It may be needed for constant oops (gvn.zerocon(T_PRIMITIVE_OBJECT)) as created on following line.
> Otherwise it may result into semantically incorrect IR which tries to load a vector from a constant.

The reason that I change this here is I met another issue when the constant oops is `IOTA` which saves the index values. For such cases, the `scalar2vector` will result into wrong result. Besides, for subtype vectors, the basic type from line-443 (i.e. `BasicType bt = con_type->basic_type();`) is promoted to `int`. I cannot see the issue if loading a vector from a constant oop.  Could you please give an example? Alternatively, I was thinking about generating different IRs for the `ZERO` and `IOTA` constants. But we need to do more check about the actual values, which I think is not so urgent now.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1204919614


From xgong at openjdk.org  Thu May 25 03:55:05 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 03:55:05 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
Message-ID: <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>

> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
> 
> Java side changes include:
>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>  - Move several VectorMask default operations to the abstract super class.
>  - Minor code cleanup.
> 
> Compiler changes include:
>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>  - Minor code cleanup.
> 
> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
> and the basic unit tests work well after enabling vector support.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/845/files
  - new: https://git.openjdk.org/valhalla/pull/845/files/d34f4020..cc776d06

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

  Stats: 18 lines in 3 files changed: 15 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/845.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/845/head:pull/845

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


From jbhateja at openjdk.org  Thu May 25 07:01:22 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 May 2023 07:01:22 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
Message-ID: <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>

On Thu, 25 May 2023 02:07:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/inlinetypenode.cpp line 448:
>> 
>>> 446:           Matcher::match_rule_supported_vector(VectorNode::replicate_opcode(bt), vec_len, bt)) {
>>> 447:           value = kit->gvn().transform(VectorNode::scalar2vector(value, vec_len, Type::get_const_type(field->type()), false));
>>> 448:         }
>> 
>> It may be needed for constant oops (gvn.zerocon(T_PRIMITIVE_OBJECT)) as created on following line.
>> Otherwise it may result into semantically incorrect IR which tries to load a vector from a constant.
>
> The reason that I change this here is I met another issue when the constant oops is `IOTA` which saves the index values. For such cases, the `scalar2vector` will result into wrong result. Besides, for subtype vectors, the basic type from line-443 (i.e. `BasicType bt = con_type->basic_type();`) is promoted to `int`. I cannot see the issue if loading a vector from a constant oop.  Could you please give an example? Alternatively, I was thinking about generating different IRs for the `ZERO` and `IOTA` constants. But we need to do more check about the actual values, which I think is not so urgent now.

It will not be a problem with constant oops or even default values which are value_mirrors, but gvn.zerocon(T_PRIMITIVE_OBJECT) will be create a ConP node representing a NULL_PTR, any address commutation w.r.t. base is will result into illegal address.  

We should keep multi-field handling in both the control paths and add an extract check for ConP (TypePtr::NULL_PTR) in if condition for Type::NULL_PTR  it will handle all the cases.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205077032


From jbhateja at openjdk.org  Thu May 25 07:01:22 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 May 2023 07:01:22 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v5]
In-Reply-To: <VEilWkkeaUcDhL2ycb4Ft_9rURAlsds41XFGvM0FN0I=.8d0a53d2-a3a8-4546-8db3-097a69dc13d3@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <VEilWkkeaUcDhL2ycb4Ft_9rURAlsds41XFGvM0FN0I=.8d0a53d2-a3a8-4546-8db3-097a69dc13d3@github.com>
Message-ID: <rOuXQJB-SSaxadVpSM564Uvl0TndPd6JdDCHSlnPJcw=.805b4be0-25ac-4b84-af80-09fd4ca868e9@github.com>

On Thu, 25 May 2023 01:58:35 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/vector.cpp line 308:
>> 
>>> 306:   Node* klass_node = kit.makecon(TypeKlassPtr::make(vk));
>>> 307:   Node* alloc_oop  = kit.new_instance(klass_node, NULL, NULL, /* deoptimize_on_exception */ true, vector);
>>> 308:   vector->store(&kit, alloc_oop, alloc_oop, vk);
>> 
>> Do you think we should explicitly allocate payload for non-flattened case before calling InlineTypeNode::store.
>> As per following 
>> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L768
>> Flattening depends on InlineFieldMaxFlatSize (default 128 bytes so fine for current vectors) but its configurable and value can be reduced.
>
> Yes, allocating a buffer is needed. And the `InlineTypeNode::store()` can handled such cases. If the field type is an inline type and is not flattened, it goes to https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L518, which will create a buffer for the InlineTypeNode. Please see: https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/graphKit.cpp#L1656
> 
> I also tested the case with `-XX:InlineFieldMaxFlatSize=0` to force it not be flattened. The VectorBox expanding code is the expected one like before, which includes both the payload buffer and vector buffer and the relative stores. 
> 
> BTW, currently this flag cannot work well since there is issue when handling this option. You may need to apply the following changes when testing:
> 
> diff --git a/src/hotspot/share/classfile/fieldLayoutBuilder.cpp b/src/hotspot/share/classfile/fieldLayoutBuilder.cpp
> index 516ad9bb7..538f31ae6 100644
> --- a/src/hotspot/share/classfile/fieldLayoutBuilder.cpp
> +++ b/src/hotspot/share/classfile/fieldLayoutBuilder.cpp
> @@ -774,7 +774,7 @@ void FieldLayoutBuilder::regular_field_sorting() {
>                //too_volatile_to_flatten = false; //FIXME
>                // volatile fields are currently never inlined, this could change in the future
>              }
> -            if (!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten) || fs.access_flags().is_final()) {
> +            if (!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten) && fs.access_flags().is_final()) {
>                group->add_inlined_field(fs, vk);
>                _nonstatic_oopmap_count += vk->nonstatic_oop_map_count();
>                fs.set_inlined(true);
> @@ -877,7 +877,7 @@ void FieldLayoutBuilder::inline_class_field_sorting(TRAPS) {
>                //too_volatile_to_flatten = false; //FIXME
>                // volatile fields are currently never inlined, this could change in the future
>              }
> -            if (!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten) || fs.access_flags().is_final()) {
> +            if (!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten) && fs.access_flags().is_final()) {
>                group->add_inlined_field(fs, vk);
>                _nonstatic_oopmap_count += vk->nonstatic_oop_map_count();
>                field_alignment = vk->get_alignment();
> 
> 
> Also there are other issues when the payload is not flattened. But it...

Thanks for your explanations, yes for non-flattened case buffering happens underneath _access_store_at_

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205076247


From jbhateja at openjdk.org  Thu May 25 07:05:19 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 May 2023 07:05:19 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
Message-ID: <eg18qZa_hxQDLZ3OiuZZCPdXZeAf3aFlkup5ERwHNig=.33409dc0-c8d2-4071-84b5-a487f04d2163@github.com>

On Thu, 25 May 2023 03:55:05 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract super class.
>>  - Minor code cleanup.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Hi @XiaohongGong ,
Apart from my last comment, patch looks good to me.

Best Regards,
Jatin

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

Marked as reviewed by jbhateja (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/845#pullrequestreview-1443210718


From xgong at openjdk.org  Thu May 25 07:17:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 07:17:30 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
Message-ID: <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>

On Thu, 25 May 2023 06:58:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The reason that I change this here is I met another issue when the constant oops is `IOTA` which saves the index values. For such cases, the `scalar2vector` will result into wrong result. Besides, for subtype vectors, the basic type from line-443 (i.e. `BasicType bt = con_type->basic_type();`) is promoted to `int`. I cannot see the issue if loading a vector from a constant oop.  Could you please give an example? Alternatively, I was thinking about generating different IRs for the `ZERO` and `IOTA` constants. But we need to do more check about the actual values, which I think is not so urgent now.
>
> It will not be a problem with constant oops or even default values which are value_mirrors, but gvn.zerocon(T_PRIMITIVE_OBJECT) will be create a ConP node representing a NULL_PTR, any address commutation w.r.t. base is will result into illegal address.  
> 
> We should keep multi-field handling in both the control paths and add an extract check for ConP of  TypePtr::NULL_PTR in if condition, it will handle all the cases.

Make sense to me. But if  the constant oop is `gvn.zerocon(T_PRIMITIVE_OBJECT)`, it's more reasonable that accessing the multi-fields is invalid in runtime, right? I think compiler should exclude such cases before calling `InlineTypeNode::load`.  WDYT?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205088977


From xgong at openjdk.org  Thu May 25 07:17:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 07:17:30 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
Message-ID: <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>

On Thu, 25 May 2023 07:10:57 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> It will not be a problem with constant oops or even default values which are value_mirrors, but gvn.zerocon(T_PRIMITIVE_OBJECT) will be create a ConP node representing a NULL_PTR, any address commutation w.r.t. base is will result into illegal address.  
>> 
>> We should keep multi-field handling in both the control paths and add an extract check for ConP of  TypePtr::NULL_PTR in if condition, it will handle all the cases.
>
> Make sense to me. But if  the constant oop is `gvn.zerocon(T_PRIMITIVE_OBJECT)`, it's more reasonable that accessing the multi-fields is invalid in runtime, right? I think compiler should exclude such cases before calling `InlineTypeNode::load`.  WDYT?

Do you have a test when the constant oop's type is NULL_PTR? I can prepare a fixing and testing. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205091494


From xgong at openjdk.org  Thu May 25 07:17:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 07:17:30 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v5]
In-Reply-To: <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
Message-ID: <A2OfLcm061u7auxD9IBzFNepL_OrHn5vZ3ufcGqVg-4=.9db16386-8c5a-470b-a051-e8e591afe5db@github.com>

On Wed, 24 May 2023 06:56:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix jtreg failures
>
> src/hotspot/share/opto/library_call.cpp line 2323:
> 
>> 2321:       if (alloc != NULL) {
>> 2322:         assert(alloc->_larval, "InlineType instance must be in _larval state for unsafe put operation.\n");
>> 2323:       }
> 
> Larval bit check is needed to preserve the semantics of value objects which can be mutated only if its _larval bit is set,  allocation expansion explicitly generates IR to set this information in the mark word.  We should add a FIXME over if condition.

Yes, the issue here is the `oop` of the `InlineTypeNode` is not always the `AllocateNode`. We may need to add an utility method to check the oop's larval state. I will add a FIXME for further fixing.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1204922284


From jbhateja at openjdk.org  Thu May 25 08:08:21 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 May 2023 08:08:21 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
Message-ID: <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>

On Thu, 25 May 2023 07:13:44 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Make sense to me. But if  the constant oop is `gvn.zerocon(T_PRIMITIVE_OBJECT)`, it's more reasonable that accessing the multi-fields is invalid in runtime, right? I think compiler should exclude such cases before calling `InlineTypeNode::load`.  WDYT?
>
> Do you have a test when the constant oop's type is NULL_PTR? I can prepare a fixing and testing. Thanks!

I encountered this issue during my implementation when we attempt to create a VectorBoxNode while ciInlineKlass was not initialized.
https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/vectornode.hpp#L1692
You can make the change in above line to always create gvn.zerocon(T_PRIMITIVE_OBJECT) oop and remove special multifield handlings for constant case in InlineTypeNode::load, it will result into creation of imbalanced PhiNodes.

test Float256VectorTests.blendFloat256VectorTestsBroadcastLongSmokeTest(float[-i * 5], float[cornerCaseValue(i)], mask[false]): success

Error mixing types: vectory[8]:{float} and ftcon:0.000000

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205147334


From xgong at openjdk.org  Thu May 25 08:14:22 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 08:14:22 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
Message-ID: <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>

On Thu, 25 May 2023 08:05:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Do you have a test when the constant oop's type is NULL_PTR? I can prepare a fixing and testing. Thanks!
>
> I encountered this issue during my implementation when we attempt to create a VectorBoxNode while ciInlineKlass was not initialized.
> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/vectornode.hpp#L1692
> You can make the change in above line to always create gvn.zerocon(T_PRIMITIVE_OBJECT) oop and remove special multifield handlings for constant case in InlineTypeNode::load, it will result into creation of imbalanced PhiNodes.
> 
> test Float256VectorTests.blendFloat256VectorTestsBroadcastLongSmokeTest(float[-i * 5], float[cornerCaseValue(i)], mask[false]): success
> 
> Error mixing types: vectory[8]:{float} and ftcon:0.000000

Thanks! I will take a look at this issue.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205154246


From xgong at openjdk.org  Thu May 25 08:34:24 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 08:34:24 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
Message-ID: <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>

On Thu, 25 May 2023 08:11:09 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> I encountered this issue during my implementation when we attempt to create a VectorBoxNode while ciInlineKlass was not initialized.
>> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/vectornode.hpp#L1692
>> You can make the change in above line to always create gvn.zerocon(T_PRIMITIVE_OBJECT) oop and remove special multifield handlings for constant case in InlineTypeNode::load, it will result into creation of imbalanced PhiNodes.
>> 
>> test Float256VectorTests.blendFloat256VectorTestsBroadcastLongSmokeTest(float[-i * 5], float[cornerCaseValue(i)], mask[false]): success
>> 
>> Error mixing types: vectory[8]:{float} and ftcon:0.000000
>
> Thanks! I will take a look at this issue.

As per my understanding, oop from `gvn.zerocon(T_PRIMITIVE_OBJECT)` is a NULL_PTR, which should be handled in `InlineTypeNode::make_from_oop()` before calling `InlineTypeNode::load()` (see:  https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L857). Not sure why such issue happens.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205179495


From jbhateja at openjdk.org  Thu May 25 09:07:37 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 May 2023 09:07:37 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
Message-ID: <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUNBUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>

On Thu, 25 May 2023 08:31:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> As per my understanding, oop from `gvn.zerocon(T_PRIMITIVE_OBJECT)` is a NULL_PTR, which should be handled in `InlineTypeNode::make_from_oop()` before calling `InlineTypeNode::load()` (see: https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L857). Not sure why such issue happens.

VectorPayloadMF* classes are primitive classes and their instances are non-nullable.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205219805


From xgong at openjdk.org  Thu May 25 09:17:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 25 May 2023 09:17:29 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUNBUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
Message-ID: <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>

On Thu, 25 May 2023 09:04:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> As per my understanding, oop from `gvn.zerocon(T_PRIMITIVE_OBJECT)` is a NULL_PTR, which should be handled in `InlineTypeNode::make_from_oop()` before calling `InlineTypeNode::load()` (see:  https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L857). Not sure why such issue happens.
>
>> As per my understanding, oop from `gvn.zerocon(T_PRIMITIVE_OBJECT)` is a NULL_PTR, which should be handled in `InlineTypeNode::make_from_oop()` before calling `InlineTypeNode::load()` (see: https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L857). Not sure why such issue happens.
> 
> I see, VectorPayloadMF* classes are primitive classes and type of their instances are non-nullable, looks like problem in initialization of _zero_type[T_PRIMITIVE_TYPE] should be initialized by a TypePtr::NOTNULL.
> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/type.cpp#L728

Make sense. But the condition in [line-854](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L854) is checking the oop itself instead of the `null_free` input. So if the oop is the `NULL_PTR`, it will be catched as well? I tried to hard the oop to be `gvn.zerocon(T_PRIMITIVE_OBJECT)`, and the code goes to [line-859](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L859). Hence the followed `load()` cannot be executed.  

BTW, did you run the test again with the latest patch of this PR?  Not sure whether the issue you met before is fixed, since we have changed a lot in compiler.  Maybe we can add an assertion that the constant oop is not `NULL_PTR`, WDYT?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205231798


From jbhateja at openjdk.org  Thu May 25 10:35:25 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 25 May 2023 10:35:25 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
Message-ID: <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>

On Thu, 25 May 2023 09:14:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Make sense. But the condition in [line-854](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L854) is checking the oop itself instead of the `null_free` input. So if the oop is the `NULL_PTR`, it will be catched as well? I tried to hard the oop to be `gvn.zerocon(T_PRIMITIVE_OBJECT)`, and the code goes to [line-859](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L859). Hence the followed `load()` cannot be executed.
> 
Unbalanced PhiNode indicate creation of a scalar, you can put a FIXME over the specific code, we can then address it in subsequent patches.

> BTW, did you run the test again with the latest patch of this PR? Not sure whether the issue you met before is fixed, since we have changed a lot in compiler. Maybe we can add an assertion that the constant oop is not `NULL_PTR`, WDYT?

Thanks, did not do a test re-run with latest patch as there were several regressions in pervious one, one quick comment, kindly set can_optimize = false before following line,
https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584

I have bug fix patch ready over my pending merge patch with which I see 90% *VectorTests*.java test passing,  I shall float it once all tests are green.

Its ok to integrate your patch first, followed by a re-merge and then bug fixes for failing JTREG regression over it. WDYT ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1205320889


From dsimms at openjdk.org  Thu May 25 13:22:19 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 25 May 2023 13:22:19 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <rWQDrNCZyrQmLttnpjT-1RQXuAVefFh0DSHsEB9MjCc=.2b7e21a9-0c97-4e4e-9e5c-85bbda397fb2@github.com>

Merge jdk-21+15
Merge branch 'lworld_merge_jdk_incr_from_21_10' into lworld_merge_jdk_21_15a

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

Commit messages:
 - Merge jdk-21+15
 - Missing symbol from inline
 - Logical merge fixes, java_fields_count not available until fill_instance
 - Compilation fixes for logical merge errors
 - Merge tag 'jdk-21+15' into lworld_merge_jdk_incr_from_21_10
 - 8304134: jib bootstrapper fails to quote filename when checking download filetype
 - 8301498: Replace NULL with nullptr in cpu/x86
 - 8304089: Convert TraceDependencies to UL
 - 8294972: Convert jdk.jlink internal plugins to use the Classfile API
 - 8304657: G1: Rename set_state_empty to set_state_untracked
 - ... and 75 more: https://git.openjdk.org/valhalla/compare/8367d288...acbe4ab7

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=852&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=852&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/852/files
  Stats: 11718 lines in 531 files changed: 6510 ins; 2399 del; 2809 mod
  Patch: https://git.openjdk.org/valhalla/pull/852.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/852/head:pull/852

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


From dsimms at openjdk.org  Thu May 25 14:39:33 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 25 May 2023 14:39:33 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <rWQDrNCZyrQmLttnpjT-1RQXuAVefFh0DSHsEB9MjCc=.2b7e21a9-0c97-4e4e-9e5c-85bbda397fb2@github.com>
References: <rWQDrNCZyrQmLttnpjT-1RQXuAVefFh0DSHsEB9MjCc=.2b7e21a9-0c97-4e4e-9e5c-85bbda397fb2@github.com>
Message-ID: <NKeeBN4G6UdKonuxsSNR4lXsAdnkQifiRwLLj5_nBCE=.985aca95-49d9-4e81-852f-11b6cba730fd@github.com>

On Thu, 25 May 2023 13:10:40 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-21+15
> Merge branch 'lworld_merge_jdk_incr_from_21_10' into lworld_merge_jdk_21_15a

This pull request has now been integrated.

Changeset: 3b84e3c7
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3b84e3c7d9975fc3d116f25ac1617a786b732b1e
Stats:     11718 lines in 531 files changed: 6510 ins; 2399 del; 2809 mod

Merge jdk

Merge jdk-21+15

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

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


From dsimms at openjdk.org  Fri May 26 09:27:02 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 26 May 2023 09:27:02 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <dTyHkj46KRio0uln7-iFmt7phd-MGsNXVU3E80nmTjk=.32e6dd52-df0f-4094-94cf-7e1c629525f3@github.com>

* jdk-21+16
* jdk-21+17
* jdk-21+18
* jdk-21+19
* jdk-21+20

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

Commit messages:
 - Merge tag 'jdk-21+20' into lworld_merge_jdk_incr_from_21_15
 - 8305771: SA ClassWriter.java fails to skip overpass methods
 - 8306951: [BACKOUT] JDK-8305252 make_method_handle_intrinsic may call java code under a lock
 - 8306409: Open source AWT KeyBoardFocusManger, LightWeightComponent related tests
 - 8306705: com/sun/jdi/PopAndInvokeTest.java fails with NativeMethodException
 - 8302182: Update Public Suffix List to 88467c9
 - 8305853: java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught exception thrown in test method Test4089106"
 - 8306374: (bf) Improve performance of DirectCharBuffer::append(CharSequence[,int,int])
 - 8302328: [s390x] Simplify asm_assert definition
 - 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries
 - ... and 452 more: https://git.openjdk.org/valhalla/compare/3b84e3c7...1cc6ae11

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=853&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=853&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/853/files
  Stats: 313515 lines in 3095 files changed: 263465 ins; 32412 del; 17638 mod
  Patch: https://git.openjdk.org/valhalla/pull/853.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/853/head:pull/853

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


From dsimms at openjdk.org  Fri May 26 09:27:03 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 26 May 2023 09:27:03 GMT
Subject: [lworld] RFR: Merge jdk
In-Reply-To: <dTyHkj46KRio0uln7-iFmt7phd-MGsNXVU3E80nmTjk=.32e6dd52-df0f-4094-94cf-7e1c629525f3@github.com>
References: <dTyHkj46KRio0uln7-iFmt7phd-MGsNXVU3E80nmTjk=.32e6dd52-df0f-4094-94cf-7e1c629525f3@github.com>
Message-ID: <0uQkCrGpVIK-zwuXvBk9IhL0tK06SpunsdGa7rj34JY=.e6676dac-a42c-49c0-9d6c-40265c93a7a7@github.com>

On Fri, 26 May 2023 09:17:20 GMT, David Simms <dsimms at openjdk.org> wrote:

> * jdk-21+16
> * jdk-21+17
> * jdk-21+18
> * jdk-21+19
> * jdk-21+20

Merge jdk-21+16, jdk-21+17, jdk-21+18, jdk-21+19 and jdk-21+20

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

PR Comment: https://git.openjdk.org/valhalla/pull/853#issuecomment-1564082011


From dsimms at openjdk.org  Fri May 26 14:37:30 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 26 May 2023 14:37:30 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <dTyHkj46KRio0uln7-iFmt7phd-MGsNXVU3E80nmTjk=.32e6dd52-df0f-4094-94cf-7e1c629525f3@github.com>
References: <dTyHkj46KRio0uln7-iFmt7phd-MGsNXVU3E80nmTjk=.32e6dd52-df0f-4094-94cf-7e1c629525f3@github.com>
Message-ID: <NTx1P6jHC0FkWiw-Gx22i_JrgLqx9sbj2xubd1DRDlM=.ba7d87b3-7e15-4339-b933-34a67bd34414@github.com>

On Fri, 26 May 2023 09:17:20 GMT, David Simms <dsimms at openjdk.org> wrote:

> * jdk-21+16
> * jdk-21+17
> * jdk-21+18
> * jdk-21+19
> * jdk-21+20

This pull request has now been integrated.

Changeset: a8576b4b
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a8576b4b3f353aa2be498f197e0e5750bc18b492
Stats:     313515 lines in 3095 files changed: 263465 ins; 32412 del; 17638 mod

Merge jdk

Merge jdk-21+16, jdk-21+17, jdk-21+18, jdk-21+19 and jdk-21+20

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

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


From xgong at openjdk.org  Mon May 29 01:45:19 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 01:45:19 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
 <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
Message-ID: <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>

On Thu, 25 May 2023 10:31:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Its ok to integrate your patch first, followed by a re-merge and then bug fixes for failing JTREG regression over it. WDYT ?

Sounds good to me! Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1208751251


From xgong at openjdk.org  Mon May 29 06:33:21 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 06:33:21 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
 <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
 <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>
Message-ID: <0Pn_Jpun52Cf1wt-Rwm2kh1V9gFWZnAq5VqrWZpvLg8=.116a27a8-76fd-43d8-8267-ce27783b34d9@github.com>

On Mon, 29 May 2023 01:42:17 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> Make sense. But the condition in [line-854](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L854) is checking the oop itself instead of the `null_free` input. So if the oop is the `NULL_PTR`, it will be catched as well? I tried to hard the oop to be `gvn.zerocon(T_PRIMITIVE_OBJECT)`, and the code goes to [line-859](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L859). Hence the followed `load()` cannot be executed.
>>> 
>> Unbalanced PhiNode indicate creation of a scalar, you can put a FIXME over the specific code, we can then address it in subsequent patches.
>> 
>>> BTW, did you run the test again with the latest patch of this PR? Not sure whether the issue you met before is fixed, since we have changed a lot in compiler. Maybe we can add an assertion that the constant oop is not `NULL_PTR`, WDYT?
>> 
>> Thanks, did not do a test re-run with latest patch as there were several regressions in pervious one, one quick comment, kindly set can_optimize = false before following line,
>> https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584
>> 
>> I have bug fix patch ready over my pending merge patch with which I see 90% *VectorTests*.java test passing,  I shall float it once all tests are green.
>> 
>> Its ok to integrate your patch first, followed by a re-merge and then bug fixes for failing JTREG regression over it. WDYT ?
>
>> Its ok to integrate your patch first, followed by a re-merge and then bug fixes for failing JTREG regression over it. WDYT ?
> 
> Sounds good to me! Thanks!

> Thanks, did not do a test re-run with latest patch as there were several regressions in pervious one, one quick comment, kindly set can_optimize = false before following line,
https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584

It seems not right setting `can_optimize = false` before line-2584 for me. This will break the inner loop anyway, since it doesn't set `can_optimize = true` in the followed code, does it?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1208756664


From xgong at openjdk.org  Mon May 29 06:49:43 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 06:49:43 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v7]
In-Reply-To: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
Message-ID: <6LVUFZ9-DqDWQSGb_5pYSskgViHcW9SyH2xUu5lwKQs=.71252acb-487c-4a95-86ca-741c33693d80@github.com>

> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
> 
> Java side changes include:
>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>  - Move several VectorMask default operations to the abstract super class.
>  - Minor code cleanup.
> 
> Compiler changes include:
>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>  - Minor code cleanup.
> 
> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
> and the basic unit tests work well after enabling vector support.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Assert "base" is not null in InlineTypeNode::load()

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/845/files
  - new: https://git.openjdk.org/valhalla/pull/845/files/cc776d06..39ca3e71

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

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

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


From xgong at openjdk.org  Mon May 29 06:49:45 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 06:49:45 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v2]
In-Reply-To: <PLUOqGB8CPQCMSkWVTmzluLuH13cCy3I54zNS-Ev1WM=.a5c7efb3-49b6-41fb-bff2-fd1284ee60ab@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <o9D52A2oXwxmHNvFFLXifnCrNFox_HazZQ75lE8d1BA=.0a31742b-ee57-49d8-aeeb-5caaac95a2e2@github.com>
 <yT5wZPcJRyEFV1Mw-Ih8myyiyqKUc-TO6_3NgSKOi3A=.d423d1e4-69cf-499f-b433-1f9c881eaaed@github.com>
 <s8fr0g0i1g9MzmGYH1af7C76I3xS6FeHokyOnB8O-VI=.0556e68d-06d2-48f4-9a70-965072c1e2d6@github.com>
 <9yfISOCGIuMsolGOMbZEebxvyjtMhAQIwVg2MkdNquU=.d64b688a-17f4-4e89-9bff-c1620a7d8465@github.com>
 <PLUOqGB8CPQCMSkWVTmzluLuH13cCy3I54zNS-Ev1WM=.a5c7efb3-49b6-41fb-bff2-fd1284ee60ab@github.com>
Message-ID: <pnuKO34Oy4kkqVer4C0idB8ANyWJHsPUpPHrEZG4M90=.434650ce-90b9-4bbe-958f-145f43a3408f@github.com>

On Wed, 24 May 2023 08:27:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Hi @jatin-bhateja , could you please help to run and test whether the issue you met is fixed with the latest commit? I met other regressions and am working in progress to see what is going on. Thanks a lot!
>> 
>> Hi @XiaohongGong,
>> 
>> I floated a patch to merge latest changes from lword into lworld+vector since there have been changes in InlineTypeNode IR.
>> https://github.com/openjdk/valhalla/pull/847
>> 
>> With following patch most of the JTreg tests are passing. Load/Store tests are failing because EnablePrimitiveClass not getting set with --add-modules=jdk.incubator.vector.
>> 
>> [regression_fixes_post_merge.txt](https://github.com/openjdk/valhalla/files/11527140/regression_fixes_post_merge.txt)
>> 
>> You may integrate it along with your patch to validate and avoid duplications,  alternatively, I can post this as a stand alone patch once merge patch is integrated, I see couple of more issues and in process of fixing them.  Will re-review and validate your shuffle/mask changes and share my comments.
>> 
>> Thanks!
>
>> Hi @jatin-bhateja ,
>> 
>> I'm sorry that I forgot to tell you that there are several fixes in this PR, which may conflict with your fixing. Could you please help to review this patch and do the testing? It will be better if this patch can be merged soon, so that we can have a whole testing and bug fixing based on it.
>> 
>> Thanks, Xiaohong
> 
> Hi @XiaohongGong ,
> I went over entire patch and added few comments, overall the patch looks good to me.
> 
> Best Regards,
> Jatin

Hi @jatin-bhateja , I'v added the assertion and FIXME in `InlineTypeNode::load()`. Could you please help to check whether it is ok? Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1566637693


From xgong at openjdk.org  Mon May 29 06:49:47 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 06:49:47 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
Message-ID: <hIMQKtovb_BPvnqD7J7IPaLJ9LgRr0gdB4pq84WeinE=.02d05e64-41af-4481-be42-fb810ebafcb1@github.com>

On Thu, 25 May 2023 03:55:05 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract super class.
>>  - Minor code cleanup.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Hi @iwanowww @PaulSandoz, could you please help to take a look at this patch? Thanks in advance!

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1566638642


From jbhateja at openjdk.org  Mon May 29 06:49:49 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 29 May 2023 06:49:49 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v7]
In-Reply-To: <0Pn_Jpun52Cf1wt-Rwm2kh1V9gFWZnAq5VqrWZpvLg8=.116a27a8-76fd-43d8-8267-ce27783b34d9@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
 <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
 <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>
 <0Pn_Jpun52Cf1wt-Rwm2kh1V9gFWZnAq5VqrWZpvLg8=.116a27a8-76fd-43d8-8267-ce27783b34d9@github.com>
Message-ID: <2h9gqWA_HVm0gVwxXZ9rJhGSj3CkhPsNlwksOtHBSWg=.16323b83-8801-477a-8048-86e1a093bf02@github.com>

On Mon, 29 May 2023 01:50:15 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Thanks, did not do a test re-run with latest patch as there were several regressions in pervious one, one quick comment, kindly set can_optimize = false before following line,
> > https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584
> 
> It seems not right setting `can_optimize = false` before line-2584 for me. This will break the inner loop anyway, since it doesn't set `can_optimize = true` in the followed code, does it?

I am seeing an incorrect graph shape here for ABSMaskedByte256VectorTests


 2970  VectorBox  === _ 2967 34 2969  [[ 562 557 ]]  #jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact *  Oop:jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact * !orig=[3040],... !jvms: VectorMask::fromArray @ bci:47 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
  561  IfTrue  === 559  [[ 2883 562 ]] #1 !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
 2883  If  === 561 2882  [[ 2884 2885 ]] P=0.000001, C=-1.000000 !orig=[584] !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
 1181  LoadVector  === 2876 2991 1180  [[ 1179 3038 ]]  @jdk/incubator/vector/Byte256Vector$Byte256Mask:exact+16 *, name=mfield, idx=10; mismatched #vectory[32]:{bool} !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
   51  ConP  === 0  [[ 52 60 137 146 252 259 332 340 452 434 557 565 801 788 2286 1058 1066 1081 1179 2286 3018 1808 1823 1907 1915 1969 1956 2279 2969 2994 3030 3031 3034 3036 3036 ]]  #NULL
    0  Root  === 0 64 83 150 166 263 280 344 360 438 456 569 597 620 633 646 684 696 708 792 805 1070 1090 1188 1812 1832 1919 1960 1973 2243 2255 2267 2290 2305 2365 2394 2463 2834 2557 2833 2627 2826 2669 2813 2731 2756  |2152 2172 2504  [[ 0 1 3 2487 23 2435 26 2349 2343 32 34 50 51 59 69 78 2205 107 134 145 2155 2154 601 2821 329 1914 1771 1166 411 413 433 451 478 1099 500 502 1036 935 506 858 641 628 534 554 615 ]] 
 2876  IfFalse  === 2875  [[ 1181 1177 3002 ]] #0 !orig=[1175] !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
  668  If  === 652 667  [[ 669 670 ]] P=0.010156, C=23040.000000 !jvms: Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:86 (line 5259)
 2162  If  === 2152 2161  [[ 2163 2164 ]] P=0.989844, C=22806.000000 !jvms: Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:86 (line 5259)
  562  CastPP  === 561 2970  [[ 593 570 587 ]]  #jdk/internal/vm/vector/VectorSupport$VectorPayload:NotNull *  Oop:jdk/internal/vm/vector/VectorSupport$VectorPayload:NotNull * !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
 2884  IfFalse  === 2883  [[ 587 611 3041 ]] #0 !orig=[585] !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
 1179  InlineType  === _ 51 34 1181  [[ 1178 ]]  #jdk/internal/vm/vector/VectorSupport$VectorPayloadMF256Z:NotNull:exact *  Oop:jdk/internal/vm/vector/VectorSupport$VectorPayloadMF256Z:NotNull:exact * !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
   34  ConI  === 0  [[ 2503 2257 2245 2233 2171 1823 1822 1179 1178 1081 1080 698 609 622 635 674 686 3019 3018 2969 2970 2994 2995 1801 3033 3037 3042 ]]  #int:1
 1177  CheckCastPP  === 2876 587  [[ 1178 1180 1180 3034 ]]  #jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact *  Oop:jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact * !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
  669  IfTrue  === 668  [[ 673 ]] #1 !jvms: Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:86 (line 5259)
 2164  IfFalse  === 2162  [[ 673 ]] #0 !jvms: Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:86 (line 5259)
  587  CheckCastPP  === 2884 562  [[ 1828 1808 3002 1184 616 629 642 1177 2170 680 692 704 1169 1169 788 801 2978 1066 1086 1184 ]]  #jdk/incubator/vector/VectorMask:NotNull *  Oop:jdk/incubator/vector/VectorMask:NotNull * !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
 1178  InlineType  === _ 1177 34 1179  [[ 2152 2170 3002 1969 1956 ]]  #jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact *  Oop:jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact * !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
  673  Region  === 673 2164 669  [[ 673 2176 2167 2168 2893 2170 2172 3034 3036 3037 3038 ]]  !jvms: Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:132 (line 5258)
 2170  Phi  === 673 1178 587  [[ ]]  #jdk/incubator/vector/VectorMask:NotNull *  Oop:jdk/incubator/vector/VectorMask:NotNull * !jvms: Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:86 (line 5259)


Can you check why are we injecting InlineTypeNode in first (Byte256Mask) input of  Phi, when phi itself is an oop. I suspect this could be an artifact of moving functionality into AbstractMask.java

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1208974675


From jbhateja at openjdk.org  Mon May 29 06:50:22 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 29 May 2023 06:50:22 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v7]
In-Reply-To: <2h9gqWA_HVm0gVwxXZ9rJhGSj3CkhPsNlwksOtHBSWg=.16323b83-8801-477a-8048-86e1a093bf02@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
 <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
 <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>
 <0Pn_Jpun52Cf1wt-Rwm2kh1V9gFWZnAq5VqrWZpvLg8=.116a27a8-76fd-43d8-8267-ce27783b34d9@github.com>
 <2h9gqWA_HVm0gVwxXZ9rJhGSj3CkhPsNlwksOtHBSWg=.16323b83-8801-477a-8048-86e1a093bf02@github.com>
Message-ID: <huokmnn5jADl33cMvDwvWKFIvHGzwt1lSPuVfobObqI=.29651838-25ac-479d-a7dc-812656df0f08@github.com>

On Mon, 29 May 2023 06:44:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Thanks, did not do a test re-run with latest patch as there were several regressions in pervious one, one quick comment, kindly set can_optimize = false before following line,
>> https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584
>> 
>> It seems not right setting `can_optimize = false` before line-2584 for me. This will break the inner loop anyway, since it doesn't set `can_optimize = true` in the followed code, does it?
>
>> > Thanks, did not do a test re-run with latest patch as there were several regressions in pervious one, one quick comment, kindly set can_optimize = false before following line,
>> > https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584
>> 
>> It seems not right setting `can_optimize = false` before line-2584 for me. This will break the inner loop anyway, since it doesn't set `can_optimize = true` in the followed code, does it?
> 
> I am seeing an incorrect graph shape here for ABSMaskedByte256VectorTests
> 
> 
>  2970  VectorBox  === _ 2967 34 2969  [[ 562 557 ]]  #jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact *  Oop:jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact * !orig=[3040],... !jvms: VectorMask::fromArray @ bci:47 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
>   561  IfTrue  === 559  [[ 2883 562 ]] #1 !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
>  2883  If  === 561 2882  [[ 2884 2885 ]] P=0.000001, C=-1.000000 !orig=[584] !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
>  1181  LoadVector  === 2876 2991 1180  [[ 1179 3038 ]]  @jdk/incubator/vector/Byte256Vector$Byte256Mask:exact+16 *, name=mfield, idx=10; mismatched #vectory[32]:{bool} !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
>    51  ConP  === 0  [[ 52 60 137 146 252 259 332 340 452 434 557 565 801 788 2286 1058 1066 1081 1179 2286 3018 1808 1823 1907 1915 1969 1956 2279 2969 2994 3030 3031 3034 3036 3036 ]]  #NULL
>     0  Root  === 0 64 83 150 166 263 280 344 360 438 456 569 597 620 633 646 684 696 708 792 805 1070 1090 1188 1812 1832 1919 1960 1973 2243 2255 2267 2290 2305 2365 2394 2463 2834 2557 2833 2627 2826 2669 2813 2731 2756  |2152 2172 2504  [[ 0 1 3 2487 23 2435 26 2349 2343 32 34 50 51 59 69 78 2205 107 134 145 2155 2154 601 2821 329 1914 1771 1166 411 413 433 451 478 1099 500 502 1036 935 506 858 641 628 534 554 615 ]] 
>  2876  IfFalse  === 2875  [[ 1181 1177 3002 ]] #0 !orig=[1175] !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
>   668  If  === 652 667  [[ 669 670 ]] P=0.010156, C=23040....

Phi is still carrying an abstract VectorMask type where as one of its input is concrete mask which is why C2 injects InlineTypeNode for it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1208976885


From jbhateja at openjdk.org  Mon May 29 07:06:29 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 29 May 2023 07:06:29 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
Message-ID: <WIBfikxMNsiZTzIWXYzvvraDWj-UpQju8z3eNDrdSKA=.c3c90dad-02a5-4192-b25b-413c2c76ded7@github.com>

On Thu, 25 May 2023 03:55:05 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract super class.
>>  - Minor code cleanup.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

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

> 152: // Merges 'this' with 'other' by updating the input PhiNodes added by 'clone_with_phis'
> 153: InlineTypeNode* InlineTypeNode::merge_with(PhaseGVN* gvn, const InlineTypeNode* other, int pnum, bool transform) {
> 154:   assert(this->Opcode() == other->Opcode(), "");

May I know the reason to remove this assertion? it ensures we never merge an InlineTypeNode with VectorBoxNode.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1208985042


From xgong at openjdk.org  Mon May 29 07:06:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 07:06:29 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <WIBfikxMNsiZTzIWXYzvvraDWj-UpQju8z3eNDrdSKA=.c3c90dad-02a5-4192-b25b-413c2c76ded7@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
 <WIBfikxMNsiZTzIWXYzvvraDWj-UpQju8z3eNDrdSKA=.c3c90dad-02a5-4192-b25b-413c2c76ded7@github.com>
Message-ID: <_AR8nR4JqYkBnXoca8icMGcN9Gw7VewTKPeByaZdF_c=.abf6d655-fdd8-4d9a-a2ab-bfd01bc0af46@github.com>

On Mon, 29 May 2023 06:59:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/hotspot/share/opto/inlinetypenode.cpp line 154:
> 
>> 152: // Merges 'this' with 'other' by updating the input PhiNodes added by 'clone_with_phis'
>> 153: InlineTypeNode* InlineTypeNode::merge_with(PhaseGVN* gvn, const InlineTypeNode* other, int pnum, bool transform) {
>> 154:   assert(this->Opcode() == other->Opcode(), "");
> 
> May I know the reason to remove this assertion? it ensures we never merge an InlineTypeNode with VectorBoxNode.

This assertion fails when I run jtreg tests like Float128VectorTests.java at the start of running the tests. I didn't figure out what was wrong. Maybe we can add it back and look at this issue.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1208987786


From xgong at openjdk.org  Mon May 29 07:06:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 07:06:29 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v7]
In-Reply-To: <huokmnn5jADl33cMvDwvWKFIvHGzwt1lSPuVfobObqI=.29651838-25ac-479d-a7dc-812656df0f08@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
 <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
 <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>
 <0Pn_Jpun52Cf1wt-Rwm2kh1V9gFWZnAq5VqrWZpvLg8=.116a27a8-76fd-43d8-8267-ce27783b34d9@github.com>
 <2h9gqWA_HVm0gVwxXZ9rJhGSj3CkhPsNlwksOtHBSWg=.16323b83-8801-477a-8048-86e1a093bf02@github.com>
 <huokmnn5jADl33cMvDwvWKFIvHGzwt1lSPuVfobObqI=.29651838-25ac-479d-a7dc-812656df0f08@github.com>
Message-ID: <1my4ZLFF-Wc1ywRByYsbnpPp38A9GNQTGQHg7rq8VAE=.f31bf92d-9a3c-4dba-8e7f-260bf94665be@github.com>

On Mon, 29 May 2023 06:47:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > Thanks, did not do a test re-run with latest patch as there were several regressions in pervious one, one quick comment, kindly set can_optimize = false before following line,
>>> > https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584
>>> 
>>> It seems not right setting `can_optimize = false` before line-2584 for me. This will break the inner loop anyway, since it doesn't set `can_optimize = true` in the followed code, does it?
>> 
>> I am seeing an incorrect graph shape here for ABSMaskedByte256VectorTests
>> 
>> 
>>  2970  VectorBox  === _ 2967 34 2969  [[ 562 557 ]]  #jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact *  Oop:jdk/incubator/vector/Byte256Vector$Byte256Mask:NotNull:exact * !orig=[3040],... !jvms: VectorMask::fromArray @ bci:47 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
>>   561  IfTrue  === 559  [[ 2883 562 ]] #1 !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
>>  2883  If  === 561 2882  [[ 2884 2885 ]] P=0.000001, C=-1.000000 !orig=[584] !jvms: VectorMask::fromArray @ bci:50 (line 212) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:63 (line 5256)
>>  1181  LoadVector  === 2876 2991 1180  [[ 1179 3038 ]]  @jdk/incubator/vector/Byte256Vector$Byte256Mask:exact+16 *, name=mfield, idx=10; mismatched #vectory[32]:{bool} !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
>>    51  ConP  === 0  [[ 52 60 137 146 252 259 332 340 452 434 557 565 801 788 2286 1058 1066 1081 1179 2286 3018 1808 1823 1907 1915 1969 1956 2279 2969 2994 3030 3031 3034 3036 3036 ]]  #NULL
>>     0  Root  === 0 64 83 150 166 263 280 344 360 438 456 569 597 620 633 646 684 696 708 792 805 1070 1090 1188 1812 1832 1919 1960 1973 2243 2255 2267 2290 2305 2365 2394 2463 2834 2557 2833 2627 2826 2669 2813 2731 2756  |2152 2172 2504  [[ 0 1 3 2487 23 2435 26 2349 2343 32 34 50 51 59 69 78 2205 107 134 145 2155 2154 601 2821 329 1914 1771 1166 411 413 433 451 478 1099 500 502 1036 935 506 858 641 628 534 554 615 ]] 
>>  2876  IfFalse  === 2875  [[ 1181 1177 3002 ]] #0 !orig=[1175] !jvms: Byte256Vector::lanewise @ bci:5 (line 279) Byte256Vector::lanewise @ bci:3 (line 42) Byte256VectorTests::ABSMaskedByte256VectorTests @ bci:107 (line 5261)
>>   668  If  === 652 667  [[ 669 670 ]] P=0.010...
>
> Phi is still carrying an abstract VectorMask type where as one of its input is concrete mask which is why C2 injects InlineTypeNode for it.

Yes, so do you know how this PhiNode is generated and what it is used for? From the log, I can see the two inputs of Phi are all from `VectorBox`. I guess the abstract VectorMask is from the return type of `VectorMask.fromArray()` ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1208986445


From xgong at openjdk.org  Mon May 29 07:13:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 07:13:27 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v7]
In-Reply-To: <1my4ZLFF-Wc1ywRByYsbnpPp38A9GNQTGQHg7rq8VAE=.f31bf92d-9a3c-4dba-8e7f-260bf94665be@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
 <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
 <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>
 <0Pn_Jpun52Cf1wt-Rwm2kh1V9gFWZnAq5VqrWZpvLg8=.116a27a8-76fd-43d8-8267-ce27783b34d9@github.com>
 <2h9gqWA_HVm0gVwxXZ9rJhGSj3CkhPsNlwksOtHBSWg=.16323b83-8801-477a-8048-86e1a093bf02@github.com>
 <huokmnn5jADl33cMvDwvWKFIvHGzwt1lSPuVfobObqI=.29651838-25ac-479d-a7dc-812656df0f08@github.com>
 <1my4ZLFF-Wc1ywRByYsbnpPp38A9GNQTGQHg7rq8VAE=.f31bf92d-9a3c-4dba-8e7f-260bf94665be@github.com>
Message-ID: <ud79uZniwhzF4RCQICcTm62rCAXXUHVhxRxHRrUHKRg=.a8473282-a1e6-4e13-b0ec-90e34c0cb9e2@github.com>

On Mon, 29 May 2023 07:01:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Phi is still carrying an abstract VectorMask type where as one of its input is concrete mask which is why C2 injects InlineTypeNode for it.
>
> Yes, so do you know how this PhiNode is generated and what it is used for? From the log, I can see the two inputs of Phi are all from `VectorBox`. I guess the abstract VectorMask is from the return type of `VectorMask.fromArray()` ?

I also met several issues due to the VectorAPI abstract classes and its concrete vector classes. As I see, in compiler, sometimes the argument/return type is calculated from the sigunature type of the method, but sometimes it is calculated based on the speculative type which use the profiling info as a reference.  Following is part of my fixing for such cases:

diff --git a/src/hotspot/share/opto/callGenerator.cpp b/src/hotspot/share/opto/callGenerator.cpp
index 985f7f1c8..b77aa11d9 100644
--- a/src/hotspot/share/opto/callGenerator.cpp
+++ b/src/hotspot/share/opto/callGenerator.cpp
@@ -1169,7 +1169,7 @@ static void cast_argument(int nargs, int arg_nb, ciType* t, GraphKit& kit, bool
     kit.set_argument(arg_nb, arg);
   }
   if (sig_type->is_inlinetypeptr()) {
-    arg = InlineTypeNode::make_from_oop(&kit, arg, t->as_inline_klass(), !kit.gvn().type(arg)->maybe_null());
+    arg = InlineTypeNode::make_from_oop(&kit, arg, sig_type->inline_klass(), !kit.gvn().type(arg)->maybe_null());
     kit.set_argument(arg_nb, arg);
   }
 }
diff --git a/src/hotspot/share/opto/graphKit.cpp b/src/hotspot/share/opto/graphKit.cpp
index bce8d7781..bab94b204 100644
--- a/src/hotspot/share/opto/graphKit.cpp
+++ b/src/hotspot/share/opto/graphKit.cpp
@@ -1914,20 +1914,25 @@ Node* GraphKit::set_results_for_java_call(CallJavaNode* call, bool separate_io_p
   }
 
   // Capture the return value, if any.
-  Node* ret;
   if (call->method() == NULL || call->method()->return_type()->basic_type() == T_VOID) {
-    ret = top();
+    return top();
   } else if (call->tf()->returns_inline_type_as_fields()) {
     // Return of multiple values (inline type fields): we create a
     // InlineType node, each field is a projection from the call.
     ciInlineKlass* vk = call->method()->return_type()->as_inline_klass();
     uint base_input = TypeFunc::Parms;
-    ret = InlineTypeNode::make_from_multi(this, call, vk, base_input, false, call->method()->signature()->returns_null_free_inline_type());
+    return InlineTypeNode::make_from_multi(this, call, vk, base_input, false, call->method()->signature()->returns_null_free_inline_type());
   } else {
-    ret = _gvn.transform(new ProjNode(call, TypeFunc::Parms));
+    Node* ret = _gvn.transform(new ProjNode(call, TypeFunc::Parms));
+    ciType* t = call->method()->return_type();
+    if (t->is_klass()) {
+      const Type* sig_type = TypeOopPtr::make_from_klass(t->as_klass());
+      if (sig_type->is_inlinetypeptr()) {
+        ret = InlineTypeNode::make_from_oop(this, ret, sig_type->inline_klass(), false);
+      }
+    }
+    return ret;
   }
-
-  return ret;
 }
 
 //--------------------set_predefined_input_for_runtime_call--------------------

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1208993080


From jbhateja at openjdk.org  Mon May 29 07:34:27 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 29 May 2023 07:34:27 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v7]
In-Reply-To: <ud79uZniwhzF4RCQICcTm62rCAXXUHVhxRxHRrUHKRg=.a8473282-a1e6-4e13-b0ec-90e34c0cb9e2@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
 <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
 <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>
 <0Pn_Jpun52Cf1wt-Rwm2kh1V9gFWZnAq5VqrWZpvLg8=.116a27a8-76fd-43d8-8267-ce27783b34d9@github.com>
 <2h9gqWA_HVm0gVwxXZ9rJhGSj3CkhPsNlwksOtHBSWg=.16323b83-8801-477a-8048-86e1a093bf02@github.com>
 <huokmnn5jADl33cMvDwvWKFIvHGzwt1lSPuVfobObqI=.29651838-25ac-479d-a7dc-812656df0f08@github.com>
 <1my4ZLFF-Wc1ywRByYsbnpPp38A9GNQTGQHg7rq8VAE=.f31bf92d-9a3c-4dba-8e7f-260bf94665be@github.com>
 <ud79uZniwhzF4RCQICcTm62rCAXXUHVhxRxHRrUHKRg=.a8473282-a1e6-4e13-b0ec-90e34c0cb9e2@github.com>
Message-ID: <DscAztZDbyuQrbuMFwtGRodbN3oMonVu3RkbuGXdYuA=.c9490892-fb57-4b70-8497-8b081fe1a549@github.com>

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

>> Yes, so do you know how this PhiNode is generated and what it is used for? From the log, I can see the two inputs of Phi are all from `VectorBox`. I guess the abstract VectorMask is from the return type of `VectorMask.fromArray()` ?
>
> I also met several issues due to the VectorAPI abstract classes and its concrete vector classes. As I see, in compiler, sometimes the argument/return type is calculated from the sigunature type of the method, but sometimes it is calculated based on the speculative type which use the profiling info as a reference.  Following is part of my fixing for such cases:
> 
> diff --git a/src/hotspot/share/opto/callGenerator.cpp b/src/hotspot/share/opto/callGenerator.cpp
> index 985f7f1c8..b77aa11d9 100644
> --- a/src/hotspot/share/opto/callGenerator.cpp
> +++ b/src/hotspot/share/opto/callGenerator.cpp
> @@ -1169,7 +1169,7 @@ static void cast_argument(int nargs, int arg_nb, ciType* t, GraphKit& kit, bool
>      kit.set_argument(arg_nb, arg);
>    }
>    if (sig_type->is_inlinetypeptr()) {
> -    arg = InlineTypeNode::make_from_oop(&kit, arg, t->as_inline_klass(), !kit.gvn().type(arg)->maybe_null());
> +    arg = InlineTypeNode::make_from_oop(&kit, arg, sig_type->inline_klass(), !kit.gvn().type(arg)->maybe_null());
>      kit.set_argument(arg_nb, arg);
>    }
>  }
> diff --git a/src/hotspot/share/opto/graphKit.cpp b/src/hotspot/share/opto/graphKit.cpp
> index bce8d7781..bab94b204 100644
> --- a/src/hotspot/share/opto/graphKit.cpp
> +++ b/src/hotspot/share/opto/graphKit.cpp
> @@ -1914,20 +1914,25 @@ Node* GraphKit::set_results_for_java_call(CallJavaNode* call, bool separate_io_p
>    }
>  
>    // Capture the return value, if any.
> -  Node* ret;
>    if (call->method() == NULL || call->method()->return_type()->basic_type() == T_VOID) {
> -    ret = top();
> +    return top();
>    } else if (call->tf()->returns_inline_type_as_fields()) {
>      // Return of multiple values (inline type fields): we create a
>      // InlineType node, each field is a projection from the call.
>      ciInlineKlass* vk = call->method()->return_type()->as_inline_klass();
>      uint base_input = TypeFunc::Parms;
> -    ret = InlineTypeNode::make_from_multi(this, call, vk, base_input, false, call->method()->signature()->returns_null_free_inline_type());
> +    return InlineTypeNode::make_from_multi(this, call, vk, base_input, false, call->method()->signature()->returns_null_free_inline_type());
>    } else {
> -    ret = _gvn.transform(new ProjNode(call, TypeFunc::Parms));
> +    Node* ret = _gvn.transform(new ProjNode(call, TypeFunc::Parms));
> +    ciType* t = call->method()->return_type();
> +    if (t->is_klass()) {
> +      const Type* sig_type = TypeOopPtr::make_from_klass(t->as_klass());
> +      if (sig_type->is_inlinetyp...

> Yes, so do you know how this PhiNode is generated and what it is used for? From the log, I can see the two inputs of Phi are all from `VectorBox`. I guess the abstract VectorMask is from the return type of `VectorMask.fromArray()` ?

Do not consider empty output list of the PhiNode, this dump was taken from debugger during a reverse debugging step, so it may appear its not getting used. 

All the signatures of top level VectorAPIs methods always deal in abstract types, its only due to aggressive in-lining boxes (concrete vector/mask/shuffle) gets exposed. 

We have currently disabled value scalarization for vectors, please also add mask/shuffle to [that list](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L88)

https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/inlineKlass.cpp#L341
https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/inlineKlass.cpp#L336

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1209011789


From xgong at openjdk.org  Mon May 29 07:38:23 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 07:38:23 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v7]
In-Reply-To: <DscAztZDbyuQrbuMFwtGRodbN3oMonVu3RkbuGXdYuA=.c9490892-fb57-4b70-8497-8b081fe1a549@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <fGSIV3qkjPTaFUkr-Sv4tXjbA8ljhlpejksDO81Q8uc=.ae50e5bd-7399-4c44-8802-a315bf929c37@github.com>
 <FzQWLJRcnYJP9_dFHIyka1LbWcfF78_TcaVl7cL6QAw=.3f295a72-9c25-46bf-9a3c-58b2bd6aa987@github.com>
 <xgBo-HRnO6ThO3ZFZdFLSAgwYqSDO6tEDpu_2qNDuBA=.5264c692-7664-4c8d-9a66-517804728224@github.com>
 <eczUT6kK2bLejBBpSK5NQZVOg8W7225DC_9hav56t2M=.446aef12-7a5e-494c-8f9b-9657eb541a61@github.com>
 <KNOP2Yo73f7SevoOOtMaHnVYl533-dpplHas5o3KgNM=.346fb2ae-b815-4ae1-a194-d948bcb45108@github.com>
 <Dau0Zyrq9r51QmTxMyJ92JMibPwFCrracRKeFDJ8qmI=.bac01628-f4db-4bd0-aa71-71dfbb2cae02@github.com>
 <_5Gqh0m0mW_WzCQ9i3Nm-YAyHNR9cEchyD1Az4MyVNU=.1f64210f-bcd9-45ab-9f86-e864dc68808a@github.com>
 <otJ9709UhXvRlqTzvhivKqn170eHwE8p2YBZXNDCEew=.74f0689d-6644-4a58-8ebf-22de1a07b107@github.com>
 <HgLX_I9OveMpCBbjP1bepY196cqT-xM5qNgaDhigILI=.abfd9a90-8103-44cd-834a-528ee8b9205a@github.com>
 <Rrit2mQ0nsjYQYqMj7PN1zzzthAUi7kpTUN
 BUH30NjU=.55ecf5ee-a13d-47f5-a025-520898d2c8c9@github.com>
 <zi-30CzCKO04McW1L5oNSIyXUJdfkSiwrG4W3FITFo4=.b3fa263a-feac-4e45-9f8f-c6ef161115d5@github.com>
 <4cibur-AqKLKsLlLiBLLQMDxj_vzvNcLhYnql-kxcFU=.d4ad7fe1-b9e3-4cd4-9871-ad4fc99b8ee1@github.com>
 <y6zWWQK4uAewc7p4_srUl3xK4TR0jW7RnRDrlrkU2NU=.7a13f9d9-e3e0-4b29-ad34-bd2edd008dc0@github.com>
 <0Pn_Jpun52Cf1wt-Rwm2kh1V9gFWZnAq5VqrWZpvLg8=.116a27a8-76fd-43d8-8267-ce27783b34d9@github.com>
 <2h9gqWA_HVm0gVwxXZ9rJhGSj3CkhPsNlwksOtHBSWg=.16323b83-8801-477a-8048-86e1a093bf02@github.com>
 <huokmnn5jADl33cMvDwvWKFIvHGzwt1lSPuVfobObqI=.29651838-25ac-479d-a7dc-812656df0f08@github.com>
 <1my4ZLFF-Wc1ywRByYsbnpPp38A9GNQTGQHg7rq8VAE=.f31bf92d-9a3c-4dba-8e7f-260bf94665be@github.com>
 <ud79uZniwhzF4RCQICcTm62rCAXXUHVhxRxHRrUHKRg=.a8473282-a1e6-4e13-b0ec-90e34c0cb9e2@github.com>
 <DscAztZDbyuQrbuMFwtGRodbN3oMonVu3RkbuGXdYuA=.c9490892-fb57-4b70-8497-8b081fe1a549@github.com>
Message-ID: <J1AGmGXEbPjdUpiG9tv1hU1ID8FMQ2EN2E27vD-CwUQ=.1aae8ee7-4a18-4875-ad3f-dd432a6d367d@github.com>

On Mon, 29 May 2023 07:31:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I also met several issues due to the VectorAPI abstract classes and its concrete vector classes. As I see, in compiler, sometimes the argument/return type is calculated from the sigunature type of the method, but sometimes it is calculated based on the speculative type which use the profiling info as a reference.  Following is part of my fixing for such cases:
>> 
>> diff --git a/src/hotspot/share/opto/callGenerator.cpp b/src/hotspot/share/opto/callGenerator.cpp
>> index 985f7f1c8..b77aa11d9 100644
>> --- a/src/hotspot/share/opto/callGenerator.cpp
>> +++ b/src/hotspot/share/opto/callGenerator.cpp
>> @@ -1169,7 +1169,7 @@ static void cast_argument(int nargs, int arg_nb, ciType* t, GraphKit& kit, bool
>>      kit.set_argument(arg_nb, arg);
>>    }
>>    if (sig_type->is_inlinetypeptr()) {
>> -    arg = InlineTypeNode::make_from_oop(&kit, arg, t->as_inline_klass(), !kit.gvn().type(arg)->maybe_null());
>> +    arg = InlineTypeNode::make_from_oop(&kit, arg, sig_type->inline_klass(), !kit.gvn().type(arg)->maybe_null());
>>      kit.set_argument(arg_nb, arg);
>>    }
>>  }
>> diff --git a/src/hotspot/share/opto/graphKit.cpp b/src/hotspot/share/opto/graphKit.cpp
>> index bce8d7781..bab94b204 100644
>> --- a/src/hotspot/share/opto/graphKit.cpp
>> +++ b/src/hotspot/share/opto/graphKit.cpp
>> @@ -1914,20 +1914,25 @@ Node* GraphKit::set_results_for_java_call(CallJavaNode* call, bool separate_io_p
>>    }
>>  
>>    // Capture the return value, if any.
>> -  Node* ret;
>>    if (call->method() == NULL || call->method()->return_type()->basic_type() == T_VOID) {
>> -    ret = top();
>> +    return top();
>>    } else if (call->tf()->returns_inline_type_as_fields()) {
>>      // Return of multiple values (inline type fields): we create a
>>      // InlineType node, each field is a projection from the call.
>>      ciInlineKlass* vk = call->method()->return_type()->as_inline_klass();
>>      uint base_input = TypeFunc::Parms;
>> -    ret = InlineTypeNode::make_from_multi(this, call, vk, base_input, false, call->method()->signature()->returns_null_free_inline_type());
>> +    return InlineTypeNode::make_from_multi(this, call, vk, base_input, false, call->method()->signature()->returns_null_free_inline_type());
>>    } else {
>> -    ret = _gvn.transform(new ProjNode(call, TypeFunc::Parms));
>> +    Node* ret = _gvn.transform(new ProjNode(call, TypeFunc::Parms));
>> +    ciType* t = call->method()->return_type();
>> +    if (t->is_klass()) {
>> +      const Type* sig_type = TypeOopPtr::make_from_klass(t->as_kla...
>
>> Yes, so do you know how this PhiNode is generated and what it is used for? From the log, I can see the two inputs of Phi are all from `VectorBox`. I guess the abstract VectorMask is from the return type of `VectorMask.fromArray()` ?
> 
> Do not consider empty output list of the PhiNode, this dump was taken from debugger during a reverse debugging step, so it may appear its not getting used. 
> 
> All the signatures of top level VectorAPIs methods always deal in abstract types, its only due to aggressive in-lining boxes (concrete vector/mask/shuffle) gets exposed. 
> 
> We have currently disabled value scalarization for vectors, please also add mask/shuffle to [that list](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L88)
> 
> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/inlineKlass.cpp#L341
> https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/inlineKlass.cpp#L336

Have added by extending `is_vector()` like before. Please see: https://github.com/openjdk/valhalla/pull/845/files#diff-c1589334a72930c5756e3048bd8b272463f980e2cba4cb3a0f0568afacb719f3

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1209015025


From jbhateja at openjdk.org  Mon May 29 08:49:24 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 29 May 2023 08:49:24 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <_AR8nR4JqYkBnXoca8icMGcN9Gw7VewTKPeByaZdF_c=.abf6d655-fdd8-4d9a-a2ab-bfd01bc0af46@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
 <WIBfikxMNsiZTzIWXYzvvraDWj-UpQju8z3eNDrdSKA=.c3c90dad-02a5-4192-b25b-413c2c76ded7@github.com>
 <_AR8nR4JqYkBnXoca8icMGcN9Gw7VewTKPeByaZdF_c=.abf6d655-fdd8-4d9a-a2ab-bfd01bc0af46@github.com>
Message-ID: <k6_eNNqERSJjK1v-wdVNrmIGZDgpFTo7VdOZpeUf8hw=.d527de32-88f6-4ef2-92ff-5bc7fdeeac4d@github.com>

On Mon, 29 May 2023 07:03:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> This assertion fails when I run jtreg tests like Float128VectorTests.java at the start of running the tests. I didn't figure out what was wrong.
> 
> I noticed that you added this assertion rebased on your merging patch. I'm not sure whether something is changed related to `InlineTypeNode::merge_with` which could make this assertion pass. So I think we can add this assertion back after your merging patch is in and re-see the issue if it exists. WDYT?

It fails because one of the input could be InlineTypeNode and other being VectorBoxNode.  _merge_with_ gets called from _PhiNode::push_inline_types_through_ which should not handle VectorBoxes, we have a separate routine to push boxes across phi (_merge_through_phi_).  So again it may be related to  incorrect invocation of https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/cfgnode.cpp#L2596

Problem here is that if we merge VectorBox with InlineTypeNode then resulting InlineTypeNode's oop (Phi) input may have VBA in one of its input, this will create a problem during [VBA elimination ](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/vector.cpp#L628) where VBA get replaced by SafePoint without being expanded and results into a crash during subsequent loop optimization when it tries to query the type of a SafePoint node which is not a typed IR.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1209083010


From xgong at openjdk.org  Mon May 29 08:57:25 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 08:57:25 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <k6_eNNqERSJjK1v-wdVNrmIGZDgpFTo7VdOZpeUf8hw=.d527de32-88f6-4ef2-92ff-5bc7fdeeac4d@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
 <WIBfikxMNsiZTzIWXYzvvraDWj-UpQju8z3eNDrdSKA=.c3c90dad-02a5-4192-b25b-413c2c76ded7@github.com>
 <_AR8nR4JqYkBnXoca8icMGcN9Gw7VewTKPeByaZdF_c=.abf6d655-fdd8-4d9a-a2ab-bfd01bc0af46@github.com>
 <k6_eNNqERSJjK1v-wdVNrmIGZDgpFTo7VdOZpeUf8hw=.d527de32-88f6-4ef2-92ff-5bc7fdeeac4d@github.com>
Message-ID: <uan9oV8gll8W5BRH6tppQhGvKTEaDtjK8Cl-U_LjPqc=.2c4cac01-dc62-4eb8-a26c-bc2343f7a8ef@github.com>

On Mon, 29 May 2023 08:45:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This assertion fails when I run jtreg tests like Float128VectorTests.java at the start of running the tests. I didn't figure out what was wrong. 
>> 
>> I noticed that you added this assertion rebased on your merging patch. I'm not sure whether something is changed related to `InlineTypeNode::merge_with` which could make this assertion pass. So I think we can add this assertion back after your merging patch is in and re-see the issue if it exists. WDYT?
>
>> This assertion fails when I run jtreg tests like Float128VectorTests.java at the start of running the tests. I didn't figure out what was wrong.
>> 
>> I noticed that you added this assertion rebased on your merging patch. I'm not sure whether something is changed related to `InlineTypeNode::merge_with` which could make this assertion pass. So I think we can add this assertion back after your merging patch is in and re-see the issue if it exists. WDYT?
> 
> It fails because one of the input could be InlineTypeNode and other being VectorBoxNode.  _merge_with_ gets called from _PhiNode::push_inline_types_through_ which should not handle VectorBoxes, we have a separate routine to push boxes across phi (_merge_through_phi_).  So again it may be related to  incorrect invocation of https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/cfgnode.cpp#L2596
> 
> Problem here is that if we merge VectorBox with InlineTypeNode then resulting InlineTypeNode's oop (Phi) input may have VBA in one of its input, this will create a problem during [VBA elimination ](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/vector.cpp#L628) where VBA get replaced by SafePoint without being expanded and results into a crash during subsequent loop optimization when it tries to query the type of a SafePoint node which is not a typed IR.

Yes, so we have added the changes https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2570 to forbit such cases. But it seems we have to add the `VectorBox` check in a later stage (i.e. https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584), since the `VectorBox` maybe wrapped inside a cast node. I will change this back as before and have a test with adding the assertion.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1209090376


From xgong at openjdk.org  Mon May 29 09:08:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 09:08:27 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v6]
In-Reply-To: <uan9oV8gll8W5BRH6tppQhGvKTEaDtjK8Cl-U_LjPqc=.2c4cac01-dc62-4eb8-a26c-bc2343f7a8ef@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <xZnJrUT98JOEDCbQtoKljXHnKeGNgVcr4vCfYM-s0K8=.261e2e9c-8b68-42c8-a2e7-4881be946272@github.com>
 <WIBfikxMNsiZTzIWXYzvvraDWj-UpQju8z3eNDrdSKA=.c3c90dad-02a5-4192-b25b-413c2c76ded7@github.com>
 <_AR8nR4JqYkBnXoca8icMGcN9Gw7VewTKPeByaZdF_c=.abf6d655-fdd8-4d9a-a2ab-bfd01bc0af46@github.com>
 <k6_eNNqERSJjK1v-wdVNrmIGZDgpFTo7VdOZpeUf8hw=.d527de32-88f6-4ef2-92ff-5bc7fdeeac4d@github.com>
 <uan9oV8gll8W5BRH6tppQhGvKTEaDtjK8Cl-U_LjPqc=.2c4cac01-dc62-4eb8-a26c-bc2343f7a8ef@github.com>
Message-ID: <hZ4l5oCd9oN2SdufcvER1HiZoG_iJUhRQ59KvPPpinA=.912e60e1-2ad5-4593-a4a8-eb8b8ac03e59@github.com>

On Mon, 29 May 2023 08:54:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> This assertion fails when I run jtreg tests like Float128VectorTests.java at the start of running the tests. I didn't figure out what was wrong.
>>> 
>>> I noticed that you added this assertion rebased on your merging patch. I'm not sure whether something is changed related to `InlineTypeNode::merge_with` which could make this assertion pass. So I think we can add this assertion back after your merging patch is in and re-see the issue if it exists. WDYT?
>> 
>> It fails because one of the input could be InlineTypeNode and other being VectorBoxNode.  _merge_with_ gets called from _PhiNode::push_inline_types_through_ which should not handle VectorBoxes, we have a separate routine to push boxes across phi (_merge_through_phi_).  So again it may be related to  incorrect invocation of https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/cfgnode.cpp#L2596
>> 
>> Problem here is that if we merge VectorBox with InlineTypeNode then resulting InlineTypeNode's oop (Phi) input may have VBA in one of its input, this will create a problem during [VBA elimination ](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/vector.cpp#L628) where VBA get replaced by SafePoint without being expanded and results into a crash during subsequent loop optimization when it tries to query the type of a SafePoint node which is not a typed IR.
>
> Yes, so we have added the changes https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2570 to forbit such cases. But it seems we have to add the `VectorBox` check in a later stage (i.e. https://github.com/openjdk/valhalla/pull/845/files#diff-e368502932198721c3ee52ace2397c5a9c6281930e83fc53a429573f6adf44fcR2584), since the `VectorBox` maybe wrapped inside a cast node. I will change this back as before and have a test with adding the assertion.

Test pass by moving the VectorBox checking later and adding the assertion. I will push the change later. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/845#discussion_r1209099130


From xgong at openjdk.org  Mon May 29 09:21:41 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 09:21:41 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v8]
In-Reply-To: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
Message-ID: <6dtsFo2BPmj2CEtt8PvsZ5GoHeXS6K6LRoJwLtFUQVE=.53cce549-b3eb-467d-a991-9af5987b7aca@github.com>

> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
> 
> Java side changes include:
>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>  - Move several VectorMask default operations to the abstract super class.
>  - Minor code cleanup.
> 
> Compiler changes include:
>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>  - Minor code cleanup.
> 
> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
> and the basic unit tests work well after enabling vector support.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Check VectorBox later during merging through phi for InlineTypeNode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/845/files
  - new: https://git.openjdk.org/valhalla/pull/845/files/39ca3e71..91659739

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

  Stats: 23 lines in 2 files changed: 11 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/845.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/845/head:pull/845

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


From xgong at openjdk.org  Mon May 29 10:07:28 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 29 May 2023 10:07:28 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v8]
In-Reply-To: <6dtsFo2BPmj2CEtt8PvsZ5GoHeXS6K6LRoJwLtFUQVE=.53cce549-b3eb-467d-a991-9af5987b7aca@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <6dtsFo2BPmj2CEtt8PvsZ5GoHeXS6K6LRoJwLtFUQVE=.53cce549-b3eb-467d-a991-9af5987b7aca@github.com>
Message-ID: <wq9WyF736jmGoNDjvPXVoHkeBuflw2PdDqOljvK7r5c=.285f9f54-d743-47b7-b8e3-0a94c8765faf@github.com>

On Mon, 29 May 2023 09:21:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract super class.
>>  - Minor code cleanup.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check VectorBox later during merging through phi for InlineTypeNode

Hi Jatin, 

With following two patches applied on this PR, all the jtreg tests inside `[Byte|Short|Int|Float]256VectorTests.java` can pass on X86 AVX2 systems:
[fix.patch](https://github.com/openjdk/valhalla/files/11590714/fix.patch)
[deoptimize.patch](https://github.com/openjdk/valhalla/files/11590716/deoptimize.patch)

The first one (fix.patch) is used to fix the inlinetype mismatch issues that I also pasted above. I think it can also be pushed to the lworld branch. And the similar logic has been added in latest lworld. So I plan to push the patch after your merging patch is in. 

The second one is used to fix the deoptimization issue for the vectorized multifields. It's just a prototype which needs to be refine. I will try to publish it after this PR is merged.

You can run the tests by applying these two patches, or modify them if anything is wrong. Hope this could avoid some conflicts with you.

Thanks,
Xiaohong

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1566889270


From jbhateja at openjdk.org  Mon May 29 11:51:23 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 29 May 2023 11:51:23 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v8]
In-Reply-To: <wq9WyF736jmGoNDjvPXVoHkeBuflw2PdDqOljvK7r5c=.285f9f54-d743-47b7-b8e3-0a94c8765faf@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <6dtsFo2BPmj2CEtt8PvsZ5GoHeXS6K6LRoJwLtFUQVE=.53cce549-b3eb-467d-a991-9af5987b7aca@github.com>
 <wq9WyF736jmGoNDjvPXVoHkeBuflw2PdDqOljvK7r5c=.285f9f54-d743-47b7-b8e3-0a94c8765faf@github.com>
Message-ID: <vMWAvr13hJQjN1s7WA5JdCYp8_a6GQW-FNf3jwha6aI=.4927f507-b990-4df3-92fc-c5f69c7fbec5@github.com>

On Mon, 29 May 2023 10:04:02 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Hi Jatin,
> 
> With following two patches applied on this PR, all the jtreg tests inside `[Byte|Short|Int|Float]256VectorTests.java` can pass on X86 AVX2 systems: [fix.patch](https://github.com/openjdk/valhalla/files/11590714/fix.patch) [deoptimize.patch](https://github.com/openjdk/valhalla/files/11590716/deoptimize.patch)
> 
> The first one (fix.patch) is used to fix the inlinetype mismatch issues that I also pasted above. I think it can also be pushed to the lworld branch. And the similar logic has been added in latest lworld. So I plan to push the patch after your merging patch is in.
> 
> The second one is used to fix the deoptimization issue for the vectorized multifields. It's just a prototype which needs to be refine. I will try to publish it after this PR is merged.
> 
> You can run the tests by applying these two patches, or modify them if anything is wrong. Hope this could avoid some conflicts with you.
> 
> Thanks, Xiaohong

Great, kindly integrate this PR.  I understand that we plan to fix regressions in subsequent commits.

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1567033118


From xgong at openjdk.org  Tue May 30 01:40:22 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 30 May 2023 01:40:22 GMT
Subject: [lworld+vector] RFR: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes [v8]
In-Reply-To: <6dtsFo2BPmj2CEtt8PvsZ5GoHeXS6K6LRoJwLtFUQVE=.53cce549-b3eb-467d-a991-9af5987b7aca@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
 <6dtsFo2BPmj2CEtt8PvsZ5GoHeXS6K6LRoJwLtFUQVE=.53cce549-b3eb-467d-a991-9af5987b7aca@github.com>
Message-ID: <bINCTC7CNqGVH08RbaHG5xUkIeKShnIIM_MGu7OnabA=.b70db2f1-c9d3-4193-99df-5100dec188df@github.com>

On Mon, 29 May 2023 09:21:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch changes the Vector API java side and hotspot compiler code to make the `VectorMask` and `VectorShuffle` operations work well after integrating with valhalla value/primitive classes.
>> 
>> Java side changes include:
>>  - Define the concrete `VectorMask/VectorShuffle `classes as value class.
>>  - Define the payload field type as primitive classes, which defines `MultiField` annotated field to save the element values.
>>  - Change all the relative API implementations, which use Unsafe APIs to access the new payload.
>>  - Move several VectorMask default operations to the abstract super class.
>>  - Minor code cleanup.
>> 
>> Compiler changes include:
>>  - Enable intrinsification for `VectorMask/VectorShuffle` related operations.
>>    Mask input/output of `VectorBox/VectorUnbox` is changed to the boolean vector format, to adapt C2's `InlineTypeNode`
>>    and new `VectorBox` features. Note that the mask input/output is a normal vector or predicate before.
>>  - Refine `VectorBox` expanding logic to make it right when the primitive payload instance is not flattened.
>>  - Minor code cleanup.
>> 
>> Basic VectorMask/VectorShuffle jtreg tests pass with"`-XX:+UnlockExperimentalVMOptions -XX:-EnableVectorSupport`",
>> and the basic unit tests work well after enabling vector support.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check VectorBox later during merging through phi for InlineTypeNode

Hi @TobiHartmann, could you please help to sponsor this PR? Thanks a lot in advance!

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

PR Comment: https://git.openjdk.org/valhalla/pull/845#issuecomment-1567653794


From thartmann at openjdk.org  Tue May 30 15:06:28 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 May 2023 15:06:28 GMT
Subject: [lworld] RFR: 8309036: [lworld] Assert during C2 compilation
 "possible deadlock"
Message-ID: <VMKNymgt3GakIffXPVi7u464xyRIbMqxTF95YnfGPGU=.b30cb9ab-c6d1-46b1-9658-7fb67ed619a1@github.com>

The fix for [JDK-8304743](https://bugs.openjdk.org/browse/JDK-8304743) that came in with the recent merge removed the `ttyUnlocker` from `ciEnv::get_klass_by_name_impl` which revealed an old regression from [JDK-8206144](https://bugs.openjdk.org/browse/JDK-8206144): A call to `ciField::layout_type()` triggers a re-computation of the type via a SystemDictionary lookup while holding the ttyLock.

Thanks,
Tobias

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

Commit messages:
 - Updated fix
 - 8309036: [lworld] Assert during C2 compilation "possible deadlock"

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

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


From thartmann at openjdk.org  Tue May 30 15:09:27 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 May 2023 15:09:27 GMT
Subject: [lworld] Integrated: 8309036: [lworld] Assert during C2 compilation
 "possible deadlock"
In-Reply-To: <VMKNymgt3GakIffXPVi7u464xyRIbMqxTF95YnfGPGU=.b30cb9ab-c6d1-46b1-9658-7fb67ed619a1@github.com>
References: <VMKNymgt3GakIffXPVi7u464xyRIbMqxTF95YnfGPGU=.b30cb9ab-c6d1-46b1-9658-7fb67ed619a1@github.com>
Message-ID: <HDrg2hPmj9nHsgGv7DGKSNYDq20cfKYJUMZFw2Wr6p4=.d37a0cbb-8a15-448e-b592-6fea12c05a22@github.com>

On Tue, 30 May 2023 14:59:51 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The fix for [JDK-8304743](https://bugs.openjdk.org/browse/JDK-8304743) that came in with the recent merge removed the `ttyUnlocker` from `ciEnv::get_klass_by_name_impl` which revealed an old regression from [JDK-8206144](https://bugs.openjdk.org/browse/JDK-8206144): A call to `ciField::layout_type()` triggers a re-computation of the type via a SystemDictionary lookup while holding the ttyLock.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8309036: [lworld] Assert during C2 compilation "possible deadlock"

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

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


From dsimms at openjdk.org  Wed May 31 13:47:15 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 31 May 2023 13:47:15 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <g6jhONU1kqbOqzAou1pGBC-WHVSzPFHl60Eb8K5UzZM=.2f23ac6e-7167-4751-bef7-6b49d2f6d3b5@github.com>

* jdk-21+21
* jdk-21+22
* jdk-21+23
* jdk-21+24

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

Commit messages:
 - Merge tag 'jdk-21+24' into lworld_merge_jdk_incr_from_21_20
 - 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
 - 8306698: Add overloads to MethodTypeDesc::of
 - 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries
 - 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64
 - 8303942: os::write should write completely
 - 8306706: Support out-of-line code generation for MachNodes
 - 8308016: Use snippets in java.io package
 - 8308116: jdk.test.lib.compiler.InMemoryJavaCompiler.compile does not close files
 - 8307523: [vectorapi] Optimize MaskFromLongBenchmark.java
 - ... and 411 more: https://git.openjdk.org/valhalla/compare/a8576b4b...962b36a0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=855&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=855&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/855/files
  Stats: 190826 lines in 3289 files changed: 137112 ins; 27649 del; 26065 mod
  Patch: https://git.openjdk.org/valhalla/pull/855.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/855/head:pull/855

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