From Xiaohong.Gong at arm.com  Mon Jul  3 01:23:58 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Mon, 3 Jul 2023 01:23:58 +0000
Subject: Question on the inline type flattening decision
In-Reply-To: <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
Message-ID: <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>

Hi Frederic,

Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not sure how to handle the relationship with "final" fields. 

One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.

Another is changing the followed "||" to "&&", so that only the "final" fields that match the preconditions can be flattened.

So which one do you think is the defined behavior? The first one sounds reasonable to me. WDYT? Thanks a lot! 

BTW, I'v filed this issue to: https://bugs.openjdk.org/browse/JDK-8311219

Best Regards,
Xiaohong

-----Original Message-----
From: Frederic Parain <frederic.parain at oracle.com> 
Sent: Friday, June 30, 2023 9:28 PM
To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
Cc: nd <nd at arm.com>
Subject: Re: Question on the inline type flattening decision

Hi Xiaohong,


Thank you for reporting this. It looks like a bug to me, specifying
-XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including final fields.

Do you want to fill a bug report or do you want me to take care of it?


Best Regards,


Fred


On 6/30/23 3:04 AM, Xiaohong Gong wrote:
>
> Hi,
>
> I guess this is the right place to ask this question related to the 
> flattening decision on inline type fields?
>
> I met an issue when I was running the tests under 
> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with 
> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing by 
> forcing the inline type fields not be flattened. ?And I debugged some
> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`. ?But I 
> found that the code path has no difference, which means this flag 
> cannot work and the field is flattened as without this flag.
>
> And then, I checked the relative code
> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas
> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks 
> the three necessary conditions (i.e.
> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or 
> ?volatile? fields) firstly, which is the right behavior I think. But 
> then the result is ?||? with the `final` access flag. Which means if 
> the field is `final`, it will be flattened anyway regardless of the 
> necessary three limitations.
>
> So is this the expected behavior? Does this mean the inline type field 
> can always be flattened if it is declared with `final`? But I didn?t 
> find any descriptions on the flattening decision related to the 
> `final` flag.
>
> Many thanks if any help on this!
>
> Best Regards,
>
> Xiaohong
>

From xgong at openjdk.org  Mon Jul  3 08:53:55 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 3 Jul 2023 08:53:55 GMT
Subject: [lworld+vector] RFR: 8311080: [lworld+vector] Fix jdk build failures
 with different options
Message-ID: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>

There are several issues exposed by building jdk image with following different options:
 - `--disable-precompiled-headers`
 - `--with-jvm-variants=client`
 - `--with-jvm-variants=minimal` or `--disable-cds`

1. With `--disable-precompiled-headers`, using `class MultiFieldInfo` in `oops/fieldInfo.hpp` and `oops/fieldInfo.inline.hpp` builds error with "invalid use of incomplete type".

The reason is that class `MultiFieldInfo` is used in `fieldInfo.hpp`, but the header declaring the class is not included in it. A direct
fixing is including its header file `oops/instanceKlass.hpp` before using it. But it cannot work here since `oops/instanceKlass.hpp` has included `oops/fieldInfo.hpp`.

To resolve the circle, we can move the definition of class `MultiFieldInfo` to `oops/fieldInfo.hpp`, which I think is also reasonable since `multifield` is a kind of `field`.

2. With `--with-jvm-variants=client`, calling `Deoptimization::reassign_fields_by_klass()` in `vectorsupport.cpp` builds error since `reassign_fields_by_klass()` is defined when C2 or JVMCI compiler is enabled (See [1]).

Consider the caller method in `vectorSupport.cpp` is used only for C2 compiler (See [2]), adding the same limitation for definition of all the relative methods in `vectorSupport.cpp` is better and can fix this issue.

3. With `--with-jvm-variants=minimal` or `--disable-cds`, calling several CDS specific methods ([3]) in `oops/inlineKlass.cpp` builds error. Those caller methods defined in `inlineKlass.hpp` are all CDS related as well. Hence, adding the same CDS condition for them sounds reasonable and can fix this issue.

This patch also fixed an return type mismatch issue exposed by building the jdk image on aarch64 windows system. The relative method is:


jint SharedRuntime::skip_value_scalarization(InlineKlass *)

The declaration type is `int` (see [4]).

[1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.hpp#L195
[2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1278
[3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/instanceKlass.hpp#L1236
[4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/sharedRuntime.hpp#L186

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

Commit messages:
 - 8311080: [lworld+vector] Fix jdk build failures with different options

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

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


From xgong at openjdk.org  Tue Jul  4 01:47:19 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 4 Jul 2023 01:47:19 GMT
Subject: [lworld+vector] RFR: 8311080: [lworld+vector] Fix jdk build
 failures with different options
In-Reply-To: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
References: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
Message-ID: <mMQayYcPrlPC9FcQXVRmxGGcSIjVRqS_QZD2ahphFtc=.4d949a33-e502-4a23-a7ec-5924b377577e@github.com>

On Mon, 3 Jul 2023 08:46:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> There are several issues exposed by building jdk image with following different options:
>  - `--disable-precompiled-headers`
>  - `--with-jvm-variants=client`
>  - `--with-jvm-variants=minimal` or `--disable-cds`
> 
> 1. With `--disable-precompiled-headers`, using `class MultiFieldInfo` in `oops/fieldInfo.hpp` and `oops/fieldInfo.inline.hpp` builds error with "invalid use of incomplete type".
> 
> The reason is that class `MultiFieldInfo` is used in `fieldInfo.hpp`, but the header declaring the class is not included in it. A direct
> fixing is including its header file `oops/instanceKlass.hpp` before using it. But it cannot work here since `oops/instanceKlass.hpp` has included `oops/fieldInfo.hpp`.
> 
> To resolve the circle, we can move the definition of class `MultiFieldInfo` to `oops/fieldInfo.hpp`, which I think is also reasonable since `multifield` is a kind of `field`.
> 
> 2. With `--with-jvm-variants=client`, calling `Deoptimization::reassign_fields_by_klass()` in `vectorsupport.cpp` builds error since `reassign_fields_by_klass()` is defined when C2 or JVMCI compiler is enabled (See [1]).
> 
> Consider the caller method in `vectorSupport.cpp` is used only for C2 compiler (See [2]), adding the same limitation for definition of all the relative methods in `vectorSupport.cpp` is better and can fix this issue.
> 
> 3. With `--with-jvm-variants=minimal` or `--disable-cds`, calling several CDS specific methods ([3]) in `oops/inlineKlass.cpp` builds error. Those caller methods defined in `inlineKlass.hpp` are all CDS related as well. Hence, adding the same CDS condition for them sounds reasonable and can fix this issue.
> 
> This patch also fixed an return type mismatch issue exposed by building the jdk image on aarch64 windows system. The relative method is:
> 
> 
> jint SharedRuntime::skip_value_scalarization(InlineKlass *)
> 
> The declaration type is `int` (see [4]).
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.hpp#L195
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1278
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/instanceKlass.hpp#L1236
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/sharedRuntime.hpp#L186

Hi @jatin-bhateja , could you please help to take a look at this PR? Thanks a lot!

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

PR Comment: https://git.openjdk.org/valhalla/pull/881#issuecomment-1619340723


From jbhateja at openjdk.org  Wed Jul  5 05:25:20 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Jul 2023 05:25:20 GMT
Subject: [lworld+vector] RFR: 8311080: [lworld+vector] Fix jdk build
 failures with different options
In-Reply-To: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
References: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
Message-ID: <P--8aFO4h1ufbeKIqZ6jOehW21jlCIg0Tp6n5fxvYmE=.d2bd7431-e82a-4b61-98c5-3df341b6bfde@github.com>

On Mon, 3 Jul 2023 08:46:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> There are several issues exposed by building jdk image with following different options:
>  - `--disable-precompiled-headers`
>  - `--with-jvm-variants=client`
>  - `--with-jvm-variants=minimal` or `--disable-cds`
> 
> 1. With `--disable-precompiled-headers`, using `class MultiFieldInfo` in `oops/fieldInfo.hpp` and `oops/fieldInfo.inline.hpp` builds error with "invalid use of incomplete type".
> 
> The reason is that class `MultiFieldInfo` is used in `fieldInfo.hpp`, but the header declaring the class is not included in it. A direct
> fixing is including its header file `oops/instanceKlass.hpp` before using it. But it cannot work here since `oops/instanceKlass.hpp` has included `oops/fieldInfo.hpp`.
> 
> To resolve the circle, we can move the definition of class `MultiFieldInfo` to `oops/fieldInfo.hpp`, which I think is also reasonable since `multifield` is a kind of `field`.
> 
> 2. With `--with-jvm-variants=client`, calling `Deoptimization::reassign_fields_by_klass()` in `vectorsupport.cpp` builds error since `reassign_fields_by_klass()` is defined when C2 or JVMCI compiler is enabled (See [1]).
> 
> Consider the caller method in `vectorSupport.cpp` is used only for C2 compiler (See [2]), adding the same limitation for definition of all the relative methods in `vectorSupport.cpp` is better and can fix this issue.
> 
> 3. With `--with-jvm-variants=minimal` or `--disable-cds`, calling several CDS specific methods ([3]) in `oops/inlineKlass.cpp` builds error. Those caller methods defined in `inlineKlass.hpp` are all CDS related as well. Hence, adding the same CDS condition for them sounds reasonable and can fix this issue.
> 
> This patch also fixed an return type mismatch issue exposed by building the jdk image on aarch64 windows system. The relative method is:
> 
> 
> jint SharedRuntime::skip_value_scalarization(InlineKlass *)
> 
> The declaration type is `int` (see [4]).
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.hpp#L195
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1278
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/instanceKlass.hpp#L1236
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/sharedRuntime.hpp#L186

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

> 553: 
> 554: JRT_LEAF(int, SharedRuntime::skip_value_scalarization(InlineKlass* klass))
> 555:   return (int) VectorSupport::skip_value_scalarization(klass);

Thanks for addressing these, it will also fix the build issues with default options on Windows,  I was planning to address these with JDK-8311383

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/881#discussion_r1252545951


From jbhateja at openjdk.org  Wed Jul  5 05:42:20 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Jul 2023 05:42:20 GMT
Subject: [lworld+vector] RFR: 8311080: [lworld+vector] Fix jdk build
 failures with different options
In-Reply-To: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
References: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
Message-ID: <zWI82KYYOdUQIpMC2ptQcnMyxw-zi-Jz9y-UBHbPs_U=.76c0a2da-5bf1-42ef-a807-fab4e1a05621@github.com>

On Mon, 3 Jul 2023 08:46:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> There are several issues exposed by building jdk image with following different options:
>  - `--disable-precompiled-headers`
>  - `--with-jvm-variants=client`
>  - `--with-jvm-variants=minimal` or `--disable-cds`
> 
> 1. With `--disable-precompiled-headers`, using `class MultiFieldInfo` in `oops/fieldInfo.hpp` and `oops/fieldInfo.inline.hpp` builds error with "invalid use of incomplete type".
> 
> The reason is that class `MultiFieldInfo` is used in `fieldInfo.hpp`, but the header declaring the class is not included in it. A direct
> fixing is including its header file `oops/instanceKlass.hpp` before using it. But it cannot work here since `oops/instanceKlass.hpp` has included `oops/fieldInfo.hpp`.
> 
> To resolve the circle, we can move the definition of class `MultiFieldInfo` to `oops/fieldInfo.hpp`, which I think is also reasonable since `multifield` is a kind of `field`.
> 
> 2. With `--with-jvm-variants=client`, calling `Deoptimization::reassign_fields_by_klass()` in `vectorsupport.cpp` builds error since `reassign_fields_by_klass()` is defined when C2 or JVMCI compiler is enabled (See [1]).
> 
> Consider the caller method in `vectorSupport.cpp` is used only for C2 compiler (See [2]), adding the same limitation for definition of all the relative methods in `vectorSupport.cpp` is better and can fix this issue.
> 
> 3. With `--with-jvm-variants=minimal` or `--disable-cds`, calling several CDS specific methods ([3]) in `oops/inlineKlass.cpp` builds error. Those caller methods defined in `inlineKlass.hpp` are all CDS related as well. Hence, adding the same CDS condition for them sounds reasonable and can fix this issue.
> 
> This patch also fixed an return type mismatch issue exposed by building the jdk image on aarch64 windows system. The relative method is:
> 
> 
> jint SharedRuntime::skip_value_scalarization(InlineKlass *)
> 
> The declaration type is `int` (see [4]).
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.hpp#L195
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1278
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/instanceKlass.hpp#L1236
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/sharedRuntime.hpp#L186

I still see some issues with minimal and 32 bit build with following configuration in x86 builds.
sudo ./configure --with-conf-name=linux--minimal --enable-debug --disable-precompiled-headers --with-jvm-variants=minimal --with-boot-jdk=/home/jatinbha/softwares/jdk-20  --with-default-make-target="hotspot" --with-zlib=system

We can either address it with this patch else I can handle them in a follow up RFE

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

PR Comment: https://git.openjdk.org/valhalla/pull/881#issuecomment-1621056955


From xgong at openjdk.org  Wed Jul  5 06:11:16 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 5 Jul 2023 06:11:16 GMT
Subject: [lworld+vector] RFR: 8311080: [lworld+vector] Fix jdk build
 failures with different options
In-Reply-To: <zWI82KYYOdUQIpMC2ptQcnMyxw-zi-Jz9y-UBHbPs_U=.76c0a2da-5bf1-42ef-a807-fab4e1a05621@github.com>
References: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
 <zWI82KYYOdUQIpMC2ptQcnMyxw-zi-Jz9y-UBHbPs_U=.76c0a2da-5bf1-42ef-a807-fab4e1a05621@github.com>
Message-ID: <NQ-2WxpXrocRAcnT5hlNavQ4uIxb1ENuz53aSzJbWZk=.88202062-a6d1-4e30-8fad-7b3f4bab7780@github.com>

On Wed, 5 Jul 2023 05:37:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> I still see some issues with minimal and 32 bit build with following configuration on x86. sudo ./configure --with-conf-name=linux--minimal --enable-debug --disable-precompiled-headers --with-jvm-variants=minimal --with-boot-jdk=/home/jatinbha/softwares/jdk-20 --with-default-make-target="hotspot" --with-zlib=system
> 
> We can either address it with this patch else I can handle them in a follow up RFE

Thanks for the review! I'm not familiar with x86 systems, so a separate patch to fix the x86 failure is better to me. Besides, I also met another issue with `--with-jvm-variants=client` on x86 systems, which also exists on `lworld` branch. You may take a look as well if possible.

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

PR Comment: https://git.openjdk.org/valhalla/pull/881#issuecomment-1621085517


From jbhateja at openjdk.org  Wed Jul  5 06:22:21 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Jul 2023 06:22:21 GMT
Subject: [lworld+vector] RFR: 8311080: [lworld+vector] Fix jdk build
 failures with different options
In-Reply-To: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
References: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
Message-ID: <eUUiZxuGDhF22fAiqzFpy4Wmb9ZVV61xkojRiQc7rSI=.247e2090-867e-4416-b5c4-2d906e114ddf@github.com>

On Mon, 3 Jul 2023 08:46:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> There are several issues exposed by building jdk image with following different options:
>  - `--disable-precompiled-headers`
>  - `--with-jvm-variants=client`
>  - `--with-jvm-variants=minimal` or `--disable-cds`
> 
> 1. With `--disable-precompiled-headers`, using `class MultiFieldInfo` in `oops/fieldInfo.hpp` and `oops/fieldInfo.inline.hpp` builds error with "invalid use of incomplete type".
> 
> The reason is that class `MultiFieldInfo` is used in `fieldInfo.hpp`, but the header declaring the class is not included in it. A direct
> fixing is including its header file `oops/instanceKlass.hpp` before using it. But it cannot work here since `oops/instanceKlass.hpp` has included `oops/fieldInfo.hpp`.
> 
> To resolve the circle, we can move the definition of class `MultiFieldInfo` to `oops/fieldInfo.hpp`, which I think is also reasonable since `multifield` is a kind of `field`.
> 
> 2. With `--with-jvm-variants=client`, calling `Deoptimization::reassign_fields_by_klass()` in `vectorsupport.cpp` builds error since `reassign_fields_by_klass()` is defined when C2 or JVMCI compiler is enabled (See [1]).
> 
> Consider the caller method in `vectorSupport.cpp` is used only for C2 compiler (See [2]), adding the same limitation for definition of all the relative methods in `vectorSupport.cpp` is better and can fix this issue.
> 
> 3. With `--with-jvm-variants=minimal` or `--disable-cds`, calling several CDS specific methods ([3]) in `oops/inlineKlass.cpp` builds error. Those caller methods defined in `inlineKlass.hpp` are all CDS related as well. Hence, adding the same CDS condition for them sounds reasonable and can fix this issue.
> 
> This patch also fixed an return type mismatch issue exposed by building the jdk image on aarch64 windows system. The relative method is:
> 
> 
> jint SharedRuntime::skip_value_scalarization(InlineKlass *)
> 
> The declaration type is `int` (see [4]).
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.hpp#L195
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1278
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/instanceKlass.hpp#L1236
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/sharedRuntime.hpp#L186

Thanks for addressing these.

Best Regards,
Jatin

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

Marked as reviewed by jbhateja (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/881#pullrequestreview-1513741283


From jbhateja at openjdk.org  Wed Jul  5 06:22:21 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Jul 2023 06:22:21 GMT
Subject: [lworld+vector] RFR: 8311080: [lworld+vector] Fix jdk build
 failures with different options
In-Reply-To: <NQ-2WxpXrocRAcnT5hlNavQ4uIxb1ENuz53aSzJbWZk=.88202062-a6d1-4e30-8fad-7b3f4bab7780@github.com>
References: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
 <zWI82KYYOdUQIpMC2ptQcnMyxw-zi-Jz9y-UBHbPs_U=.76c0a2da-5bf1-42ef-a807-fab4e1a05621@github.com>
 <NQ-2WxpXrocRAcnT5hlNavQ4uIxb1ENuz53aSzJbWZk=.88202062-a6d1-4e30-8fad-7b3f4bab7780@github.com>
Message-ID: <3Wd9PSG_1oGaN1-mrE5sKXh2ZGw8uVucGA73J1TIlGE=.3528771f-936e-401a-baca-b26f031b9a24@github.com>

On Wed, 5 Jul 2023 06:08:55 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > I still see some issues with minimal and 32 bit build with following configuration on x86. sudo ./configure --with-conf-name=linux--minimal --enable-debug --disable-precompiled-headers --with-jvm-variants=minimal --with-boot-jdk=/home/jatinbha/softwares/jdk-20 --with-default-make-target="hotspot" --with-zlib=system
> > We can either address it with this patch else I can handle them in a follow up RFE
> 
> Thanks for the review! I'm not familiar with x86 systems, so a separate patch to fix the x86 failure is better to me. Besides, I also met another issue with `--with-jvm-variants=client` on x86 systems, which also exists on `lworld` branch. You may take a look as well if possible.

Ok, I will address them with JDK-8311383

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

PR Comment: https://git.openjdk.org/valhalla/pull/881#issuecomment-1621097231


From xgong at openjdk.org  Wed Jul  5 06:22:21 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 5 Jul 2023 06:22:21 GMT
Subject: [lworld+vector] RFR: 8311080: [lworld+vector] Fix jdk build
 failures with different options
In-Reply-To: <eUUiZxuGDhF22fAiqzFpy4Wmb9ZVV61xkojRiQc7rSI=.247e2090-867e-4416-b5c4-2d906e114ddf@github.com>
References: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
 <eUUiZxuGDhF22fAiqzFpy4Wmb9ZVV61xkojRiQc7rSI=.247e2090-867e-4416-b5c4-2d906e114ddf@github.com>
Message-ID: <iPagZkzzw5SuAOx8cuSfecMN7GmYjyb89SAU1BuPJgc=.35457b7c-8cb6-4ba8-92c9-9022500954eb@github.com>

On Wed, 5 Jul 2023 06:18:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Thanks for addressing these.
> 
> Best Regards, Jatin

Thanks for the fixing the review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/881#issuecomment-1621098664


From xgong at openjdk.org  Wed Jul  5 06:25:21 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 5 Jul 2023 06:25:21 GMT
Subject: [lworld+vector] Integrated: 8311080: [lworld+vector] Fix jdk build
 failures with different options
In-Reply-To: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
References: <63yMGTY1RrINMDhBc2yJy4mLWuNjNZCKLcNYhLkIZJw=.ef9ee4ad-b634-4fb3-950e-03aaf8ae68ce@github.com>
Message-ID: <r9pLypZPbjShkwu0wiOKI8osZ-xTZfu7ZNGvsKvRT4E=.2fd5c125-b2d8-4d7d-a3a6-e682973a161a@github.com>

On Mon, 3 Jul 2023 08:46:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> There are several issues exposed by building jdk image with following different options:
>  - `--disable-precompiled-headers`
>  - `--with-jvm-variants=client`
>  - `--with-jvm-variants=minimal` or `--disable-cds`
> 
> 1. With `--disable-precompiled-headers`, using `class MultiFieldInfo` in `oops/fieldInfo.hpp` and `oops/fieldInfo.inline.hpp` builds error with "invalid use of incomplete type".
> 
> The reason is that class `MultiFieldInfo` is used in `fieldInfo.hpp`, but the header declaring the class is not included in it. A direct
> fixing is including its header file `oops/instanceKlass.hpp` before using it. But it cannot work here since `oops/instanceKlass.hpp` has included `oops/fieldInfo.hpp`.
> 
> To resolve the circle, we can move the definition of class `MultiFieldInfo` to `oops/fieldInfo.hpp`, which I think is also reasonable since `multifield` is a kind of `field`.
> 
> 2. With `--with-jvm-variants=client`, calling `Deoptimization::reassign_fields_by_klass()` in `vectorsupport.cpp` builds error since `reassign_fields_by_klass()` is defined when C2 or JVMCI compiler is enabled (See [1]).
> 
> Consider the caller method in `vectorSupport.cpp` is used only for C2 compiler (See [2]), adding the same limitation for definition of all the relative methods in `vectorSupport.cpp` is better and can fix this issue.
> 
> 3. With `--with-jvm-variants=minimal` or `--disable-cds`, calling several CDS specific methods ([3]) in `oops/inlineKlass.cpp` builds error. Those caller methods defined in `inlineKlass.hpp` are all CDS related as well. Hence, adding the same CDS condition for them sounds reasonable and can fix this issue.
> 
> This patch also fixed an return type mismatch issue exposed by building the jdk image on aarch64 windows system. The relative method is:
> 
> 
> jint SharedRuntime::skip_value_scalarization(InlineKlass *)
> 
> The declaration type is `int` (see [4]).
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.hpp#L195
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1278
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/oops/instanceKlass.hpp#L1236
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/sharedRuntime.hpp#L186

This pull request has now been integrated.

Changeset: bb135138
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/bb135138d1314e84bc1371cc9a9d425eafc26c70
Stats:     53 lines in 7 files changed: 28 ins; 18 del; 7 mod

8311080: [lworld+vector] Fix jdk build failures with different options

Reviewed-by: jbhateja

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

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


From vromero at openjdk.org  Wed Jul  5 21:20:45 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 5 Jul 2023 21:20:45 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v4]
In-Reply-To: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
Message-ID: <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>

> addressing some review comments related to PR [1]
> 
> [1] https://github.com/openjdk/valhalla/pull/872

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  adding more regression tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/880/files
  - new: https://git.openjdk.org/valhalla/pull/880/files/b605e9ce..c6f88ac7

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

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

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


From frederic.parain at oracle.com  Thu Jul  6 12:57:26 2023
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 6 Jul 2023 08:57:26 -0400
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
Message-ID: <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>

Hi Xiaohong,


I would recommend to modify the test driving the flattening decisions 
the following way:

if (InlineFieldMaxFlatSize != 0

 ???? && (!(too_big_to_flatten | too_atomic_to_flatten | 
too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {


By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be 
obvious that this is the way to completely disable field flattening.

The second term would remain the more specific tests on the field's 
properties to decide to flatten or not when flattening is enabled.


What do you think of this proposal?


Best Regards,


Fred


On 7/2/23 9:23 PM, Xiaohong Gong wrote:
> Hi Frederic,
>
> Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not sure how to handle the relationship with "final" fields.
>
> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.
>
> Another is changing the followed "||" to "&&", so that only the "final" fields that match the preconditions can be flattened.
>
> So which one do you think is the defined behavior? The first one sounds reasonable to me. WDYT? Thanks a lot!
>
> BTW, I'v filed this issue to: https://bugs.openjdk.org/browse/JDK-8311219
>
> Best Regards,
> Xiaohong
>
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com>
> Sent: Friday, June 30, 2023 9:28 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
> Cc: nd <nd at arm.com>
> Subject: Re: Question on the inline type flattening decision
>
> Hi Xiaohong,
>
>
> Thank you for reporting this. It looks like a bug to me, specifying
> -XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including final fields.
>
> Do you want to fill a bug report or do you want me to take care of it?
>
>
> Best Regards,
>
>
> Fred
>
>
> On 6/30/23 3:04 AM, Xiaohong Gong wrote:
>> Hi,
>>
>> I guess this is the right place to ask this question related to the
>> flattening decision on inline type fields?
>>
>> I met an issue when I was running the tests under
>> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with
>> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing by
>> forcing the inline type fields not be flattened. ?And I debugged some
>> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`. ?But I
>> found that the code path has no difference, which means this flag
>> cannot work and the field is flattened as without this flag.
>>
>> And then, I checked the relative code
>> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$
>> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
>> the three necessary conditions (i.e.
>> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or
>> ?volatile? fields) firstly, which is the right behavior I think. But
>> then the result is ?||? with the `final` access flag. Which means if
>> the field is `final`, it will be flattened anyway regardless of the
>> necessary three limitations.
>>
>> So is this the expected behavior? Does this mean the inline type field
>> can always be flattened if it is declared with `final`? But I didn?t
>> find any descriptions on the flattening decision related to the
>> `final` flag.
>>
>> Many thanks if any help on this!
>>
>> Best Regards,
>>
>> Xiaohong
>>


From jatin.bhateja at intel.com  Thu Jul  6 16:07:01 2023
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Thu, 6 Jul 2023 16:07:01 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
Message-ID: <PH8PR11MB796782DCCA513334196ED8D7E82CA@PH8PR11MB7967.namprd11.prod.outlook.com>

Hi Xiaohong, Fred,


> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.

On final field flatting, it's good to always flatten them to enhance constant folding opportunities for C2 compiler. We may have an InlineTypeNodes with high indegree, but a getfield will always get hold of constant value.

For a field to be a true constant should we not check for both static and final accesses?

Alternatively, since a primitive/value class objects are immutable with implicit final fields unless object in larval state so we may also relax final access check, WDYT ?

Best Regards,
Jatin


________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Frederic Parain <frederic.parain at oracle.com>
Sent: Thursday, July 6, 2023 6:28:16 PM
To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Cc: nd <nd at arm.com>
Subject: Re: [External] : RE: Question on the inline type flattening decision

Hi Xiaohong,


I would recommend to modify the test driving the flattening decisions
the following way:

if (InlineFieldMaxFlatSize != 0

      && (!(too_big_to_flatten | too_atomic_to_flatten |
too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {


By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
obvious that this is the way to completely disable field flattening.

The second term would remain the more specific tests on the field's
properties to decide to flatten or not when flattening is enabled.


What do you think of this proposal?


Best Regards,


Fred


On 7/2/23 9:23 PM, Xiaohong Gong wrote:
> Hi Frederic,
>
> Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not sure how to handle the relationship with "final" fields.
>
> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.
>
> Another is changing the followed "||" to "&&", so that only the "final" fields that match the preconditions can be flattened.
>
> So which one do you think is the defined behavior? The first one sounds reasonable to me. WDYT? Thanks a lot!
>
> BTW, I'v filed this issue to: https://bugs.openjdk.org/browse/JDK-8311219
>
> Best Regards,
> Xiaohong
>
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com>
> Sent: Friday, June 30, 2023 9:28 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
> Cc: nd <nd at arm.com>
> Subject: Re: Question on the inline type flattening decision
>
> Hi Xiaohong,
>
>
> Thank you for reporting this. It looks like a bug to me, specifying
> -XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including final fields.
>
> Do you want to fill a bug report or do you want me to take care of it?
>
>
> Best Regards,
>
>
> Fred
>
>
> On 6/30/23 3:04 AM, Xiaohong Gong wrote:
>> Hi,
>>
>> I guess this is the right place to ask this question related to the
>> flattening decision on inline type fields?
>>
>> I met an issue when I was running the tests under
>> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with
>> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing by
>> forcing the inline type fields not be flattened.  And I debugged some
>> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`.  But I
>> found that the code path has no difference, which means this flag
>> cannot work and the field is flattened as without this flag.
>>
>> And then, I checked the relative code
>> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$
>> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
>> the three necessary conditions (i.e.
>> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or
>> ?volatile? fields) firstly, which is the right behavior I think. But
>> then the result is ?||? with the `final` access flag. Which means if
>> the field is `final`, it will be flattened anyway regardless of the
>> necessary three limitations.
>>
>> So is this the expected behavior? Does this mean the inline type field
>> can always be flattened if it is declared with `final`? But I didn?t
>> find any descriptions on the flattening decision related to the
>> `final` flag.
>>
>> Many thanks if any help on this!
>>
>> Best Regards,
>>
>> Xiaohong
>>

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

From Xiaohong.Gong at arm.com  Fri Jul  7 01:53:41 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Fri, 7 Jul 2023 01:53:41 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
Message-ID: <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>

Hi Fred,

> I would recommend to modify the test driving the flattening decisions the following way:
> 
> if (InlineFieldMaxFlatSize != 0
> 
>       && (!(too_big_to_flatten | too_atomic_to_flatten |
> too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
> 
> 
> By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be 
> obvious that this is the way to completely disable field flattening.
> 
> The second term would remain the more specific tests on the field's 
> properties to decide to flatten or not when flattening is enabled.
> 
> 
> What do you think of this proposal?

Thanks for the proposal! But this looks more like a workaround for me. Actually this can
disable the field flattening with "-XX:InlineFieldMaxFlatSize=0". But what if setting it to
other small value like "2" ? That is, the field can be flattened if its holder class size is larger
than the specified max flat size, isn't it?

Thanks,
Xiaohong

-----Original Message-----
From: Frederic Parain <frederic.parain at oracle.com> 
Sent: Thursday, July 6, 2023 8:57 PM
To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
Cc: nd <nd at arm.com>
Subject: Re: [External] : RE: Question on the inline type flattening decision

Hi Xiaohong,


I would recommend to modify the test driving the flattening decisions the following way:

if (InlineFieldMaxFlatSize != 0

 ???? && (!(too_big_to_flatten | too_atomic_to_flatten |
too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {


By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be 
obvious that this is the way to completely disable field flattening.

The second term would remain the more specific tests on the field's 
properties to decide to flatten or not when flattening is enabled.


What do you think of this proposal?


Best Regards,


Fred


On 7/2/23 9:23 PM, Xiaohong Gong wrote:
> Hi Frederic,
>
> Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not sure how to handle the relationship with "final" fields.
>
> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.
>
> Another is changing the followed "||" to "&&", so that only the "final" fields that match the preconditions can be flattened.
>
> So which one do you think is the defined behavior? The first one sounds reasonable to me. WDYT? Thanks a lot!
>
> BTW, I'v filed this issue to: https://bugs.openjdk.org/browse/JDK-8311219
>
> Best Regards,
> Xiaohong
>
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com>
> Sent: Friday, June 30, 2023 9:28 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
> Cc: nd <nd at arm.com>
> Subject: Re: Question on the inline type flattening decision
>
> Hi Xiaohong,
>
>
> Thank you for reporting this. It looks like a bug to me, specifying
> -XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including final fields.
>
> Do you want to fill a bug report or do you want me to take care of it?
>
>
> Best Regards,
>
>
> Fred
>
>
> On 6/30/23 3:04 AM, Xiaohong Gong wrote:
>> Hi,
>>
>> I guess this is the right place to ask this question related to the
>> flattening decision on inline type fields?
>>
>> I met an issue when I was running the tests under
>> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with
>> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing by
>> forcing the inline type fields not be flattened. ?And I debugged some
>> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`. ?But I
>> found that the code path has no difference, which means this flag
>> cannot work and the field is flattened as without this flag.
>>
>> And then, I checked the relative code
>> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$
>> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
>> the three necessary conditions (i.e.
>> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or
>> ?volatile? fields) firstly, which is the right behavior I think. But
>> then the result is ?||? with the `final` access flag. Which means if
>> the field is `final`, it will be flattened anyway regardless of the
>> necessary three limitations.
>>
>> So is this the expected behavior? Does this mean the inline type field
>> can always be flattened if it is declared with `final`? But I didn?t
>> find any descriptions on the flattening decision related to the
>> `final` flag.
>>
>> Many thanks if any help on this!
>>
>> Best Regards,
>>
>> Xiaohong
>>

From Xiaohong.Gong at arm.com  Fri Jul  7 02:01:30 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Fri, 7 Jul 2023 02:01:30 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <PH8PR11MB796782DCCA513334196ED8D7E82CA@PH8PR11MB7967.namprd11.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <PH8PR11MB796782DCCA513334196ED8D7E82CA@PH8PR11MB7967.namprd11.prod.outlook.com>
Message-ID: <AS8PR08MB776667B0C755BC0B2502BD81F52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>

Hi Jatin,

Thanks for looking at this issue!

> On final field flatting, it's good to always flatten them to enhance constant folding opportunities for C2 compiler. We may have an InlineTypeNodes with high indegree, but a getfield will always get hold of constant value.

This sounds reasonable to me! And I think this is the current behavior. So the final field is always to be flattened even its size is larger than the specified max flat size?

>  Alternatively, since a primitive/value class objects are immutable with implicit final fields unless object in larval state so we may also relax final access check, WDYT ?

I think it's different. One is the fields in the value/primitive class is immutable (final). Another is the field with the type of value/primitive class is final. The latter is mutable if no "final" is set.

Thanks,
Xiaohong

From: Bhateja, Jatin <jatin.bhateja at intel.com>
Sent: Friday, July 7, 2023 12:07 AM
To: Frederic Parain <frederic.parain at oracle.com>; Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
Cc: nd <nd at arm.com>
Subject: Re: [External] : RE: Question on the inline type flattening decision

Hi Xiaohong, Fred,


> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.

On final field flatting, it's good to always flatten them to enhance constant folding opportunities for C2 compiler. We may have an InlineTypeNodes with high indegree, but a getfield will always get hold of constant value.

For a field to be a true constant should we not check for both static and final accesses?

Alternatively, since a primitive/value class objects are immutable with implicit final fields unless object in larval state so we may also relax final access check, WDYT ?

Best Regards,
Jatin


________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org<mailto:valhalla-dev-retn at openjdk.org>> on behalf of Frederic Parain <frederic.parain at oracle.com<mailto:frederic.parain at oracle.com>>
Sent: Thursday, July 6, 2023 6:28:16 PM
To: Xiaohong Gong <Xiaohong.Gong at arm.com<mailto:Xiaohong.Gong at arm.com>>; valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org> <valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org>>
Cc: nd <nd at arm.com<mailto:nd at arm.com>>
Subject: Re: [External] : RE: Question on the inline type flattening decision


Hi Xiaohong,


I would recommend to modify the test driving the flattening decisions
the following way:

if (InlineFieldMaxFlatSize != 0

      && (!(too_big_to_flatten | too_atomic_to_flatten |
too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {


By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
obvious that this is the way to completely disable field flattening.

The second term would remain the more specific tests on the field's
properties to decide to flatten or not when flattening is enabled.


What do you think of this proposal?


Best Regards,


Fred


On 7/2/23 9:23 PM, Xiaohong Gong wrote:
> Hi Frederic,
>
> Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not sure how to handle the relationship with "final" fields.
>
> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.
>
> Another is changing the followed "||" to "&&", so that only the "final" fields that match the preconditions can be flattened.
>
> So which one do you think is the defined behavior? The first one sounds reasonable to me. WDYT? Thanks a lot!
>
> BTW, I'v filed this issue to: https://bugs.openjdk.org/browse/JDK-8311219
>
> Best Regards,
> Xiaohong
>
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com<mailto:frederic.parain at oracle.com>>
> Sent: Friday, June 30, 2023 9:28 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com<mailto:Xiaohong.Gong at arm.com>>; valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org>
> Cc: nd <nd at arm.com<mailto:nd at arm.com>>
> Subject: Re: Question on the inline type flattening decision
>
> Hi Xiaohong,
>
>
> Thank you for reporting this. It looks like a bug to me, specifying
> -XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including final fields.
>
> Do you want to fill a bug report or do you want me to take care of it?
>
>
> Best Regards,
>
>
> Fred
>
>
> On 6/30/23 3:04 AM, Xiaohong Gong wrote:
>> Hi,
>>
>> I guess this is the right place to ask this question related to the
>> flattening decision on inline type fields?
>>
>> I met an issue when I was running the tests under
>> "hotspot/jtreg/compiler/valhalla/inlinetypes" with
>> "-XX:InlineFieldMaxFlatSize=0". The intention is doing some testing by
>> forcing the inline type fields not be flattened.  And I debugged some
>> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`.  But I
>> found that the code path has no difference, which means this flag
>> cannot work and the field is flattened as without this flag.
>>
>> And then, I checked the relative code
>> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$<https://urldefense.com/v3/__https:/github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$>
>> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
>> the three necessary conditions (i.e.
>> "the code size comparison with `InlineFieldMaxSize`", "atomic" or
>> "volatile" fields) firstly, which is the right behavior I think. But
>> then the result is "||" with the `final` access flag. Which means if
>> the field is `final`, it will be flattened anyway regardless of the
>> necessary three limitations.
>>
>> So is this the expected behavior? Does this mean the inline type field
>> can always be flattened if it is declared with `final`? But I didn't
>> find any descriptions on the flattening decision related to the
>> `final` flag.
>>
>> Many thanks if any help on this!
>>
>> Best Regards,
>>
>> Xiaohong
>>

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

From anhmdq at gmail.com  Fri Jul  7 02:08:34 2023
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Fri, 7 Jul 2023 10:08:34 +0800
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
Message-ID: <CAPvyiyKk+NtucjW6KZjk=-NvH8f9ZWk-KQKgwSQ_vBEiWXOa9g@mail.gmail.com>

Hi,

I believe the idea is that a final fields are not written to after
initialisation, which results in them not needing to adhere to the inline
limit, whose main purpose is to avoid the risk of issuing many memory write
per field store.

Regards,
Quan Anh


On Fri, 7 Jul 2023 at 09:54, Xiaohong Gong <Xiaohong.Gong at arm.com> wrote:

> Hi Fred,
>
> > I would recommend to modify the test driving the flattening decisions
> the following way:
> >
> > if (InlineFieldMaxFlatSize != 0
> >
> >       && (!(too_big_to_flatten | too_atomic_to_flatten |
> > too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
> >
> >
> > By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
> > obvious that this is the way to completely disable field flattening.
> >
> > The second term would remain the more specific tests on the field's
> > properties to decide to flatten or not when flattening is enabled.
> >
> >
> > What do you think of this proposal?
>
> Thanks for the proposal! But this looks more like a workaround for me.
> Actually this can
> disable the field flattening with "-XX:InlineFieldMaxFlatSize=0". But what
> if setting it to
> other small value like "2" ? That is, the field can be flattened if its
> holder class size is larger
> than the specified max flat size, isn't it?
>
> Thanks,
> Xiaohong
>
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com>
> Sent: Thursday, July 6, 2023 8:57 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
> Cc: nd <nd at arm.com>
> Subject: Re: [External] : RE: Question on the inline type flattening
> decision
>
> Hi Xiaohong,
>
>
> I would recommend to modify the test driving the flattening decisions the
> following way:
>
> if (InlineFieldMaxFlatSize != 0
>
>       && (!(too_big_to_flatten | too_atomic_to_flatten |
> too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
>
>
> By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
> obvious that this is the way to completely disable field flattening.
>
> The second term would remain the more specific tests on the field's
> properties to decide to flatten or not when flattening is enabled.
>
>
> What do you think of this proposal?
>
>
> Best Regards,
>
>
> Fred
>
>
> On 7/2/23 9:23 PM, Xiaohong Gong wrote:
> > Hi Frederic,
> >
> > Thanks for looking at this issue. Yes, I was planning to fix this. But
> I'm not sure how to handle the relationship with "final" fields.
> >
> > One is removing the followed "field" access check, which means the
> fields can be flattened no matter whether the field is "final" or not.
> >
> > Another is changing the followed "||" to "&&", so that only the "final"
> fields that match the preconditions can be flattened.
> >
> > So which one do you think is the defined behavior? The first one sounds
> reasonable to me. WDYT? Thanks a lot!
> >
> > BTW, I'v filed this issue to:
> https://bugs.openjdk.org/browse/JDK-8311219
> >
> > Best Regards,
> > Xiaohong
> >
> > -----Original Message-----
> > From: Frederic Parain <frederic.parain at oracle.com>
> > Sent: Friday, June 30, 2023 9:28 PM
> > To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
> > Cc: nd <nd at arm.com>
> > Subject: Re: Question on the inline type flattening decision
> >
> > Hi Xiaohong,
> >
> >
> > Thank you for reporting this. It looks like a bug to me, specifying
> > -XX:InlineFieldMaxFlatSize=0 should disable all field flattening,
> including final fields.
> >
> > Do you want to fill a bug report or do you want me to take care of it?
> >
> >
> > Best Regards,
> >
> >
> > Fred
> >
> >
> > On 6/30/23 3:04 AM, Xiaohong Gong wrote:
> >> Hi,
> >>
> >> I guess this is the right place to ask this question related to the
> >> flattening decision on inline type fields?
> >>
> >> I met an issue when I was running the tests under
> >> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with
> >> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing by
> >> forcing the inline type fields not be flattened.  And I debugged some
> >> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`.  But I
> >> found that the code path has no difference, which means this flag
> >> cannot work and the field is flattened as without this flag.
> >>
> >> And then, I checked the relative code
> >>
> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$
> >> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
> >> the three necessary conditions (i.e.
> >> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or
> >> ?volatile? fields) firstly, which is the right behavior I think. But
> >> then the result is ?||? with the `final` access flag. Which means if
> >> the field is `final`, it will be flattened anyway regardless of the
> >> necessary three limitations.
> >>
> >> So is this the expected behavior? Does this mean the inline type field
> >> can always be flattened if it is declared with `final`? But I didn?t
> >> find any descriptions on the flattening decision related to the
> >> `final` flag.
> >>
> >> Many thanks if any help on this!
> >>
> >> Best Regards,
> >>
> >> Xiaohong
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230707/ecf05c79/attachment.htm>

From jatin.bhateja at intel.com  Fri Jul  7 02:30:48 2023
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Fri, 7 Jul 2023 02:30:48 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <AS8PR08MB776667B0C755BC0B2502BD81F52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <PH8PR11MB796782DCCA513334196ED8D7E82CA@PH8PR11MB7967.namprd11.prod.outlook.com>
 <AS8PR08MB776667B0C755BC0B2502BD81F52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
Message-ID: <PH8PR11MB79676560A6BEEDA54603A12FE82DA@PH8PR11MB7967.namprd11.prod.outlook.com>

Hi Xiaohong,

Thanks for your response.


> I think it?s different. One is the fields in the value/primitive class is immutable (final). Another is the field with the type of value/primitive class is final. The latter is mutable if no ?final? is set

Yes, this is correct, and my earlier response was in this context. But to make a value object mutable it must transition into larval state.

> This sounds reasonable to me! And I think this is the current behavior. So the final field is always to be flattened even its size is larger than the specified max flat size?

Correct, only query was around usage of final along with static to treat it as a true constant.

  https://github.com/openjdk/valhalla/blob/cabc4d28c5c92f6386252851b0dede1ddde3129c/src/hotspot/share/ci/ciField.hpp#L126

Best Regards,
Jatin
________________________________
From: Xiaohong Gong <Xiaohong.Gong at arm.com>
Sent: Friday, July 7, 2023 7:31:30 AM
To: Bhateja, Jatin <jatin.bhateja at intel.com>; Frederic Parain <frederic.parain at oracle.com>; valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Cc: nd <nd at arm.com>
Subject: RE: [External] : RE: Question on the inline type flattening decision


Hi Jatin,



Thanks for looking at this issue!



> On final field flatting, it's good to always flatten them to enhance constant folding opportunities for C2 compiler. We may have an InlineTypeNodes with high indegree, but a getfield will always get hold of constant value.



This sounds reasonable to me! And I think this is the current behavior. So the final field is always to be flattened even its size is larger than the specified max flat size?



>  Alternatively, since a primitive/value class objects are immutable with implicit final fields unless object in larval state so we may also relax final access check, WDYT ?



I think it?s different. One is the fields in the value/primitive class is immutable (final). Another is the field with the type of value/primitive class is final. The latter is mutable if no ?final? is set.



Thanks,

Xiaohong



From: Bhateja, Jatin <jatin.bhateja at intel.com>
Sent: Friday, July 7, 2023 12:07 AM
To: Frederic Parain <frederic.parain at oracle.com>; Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
Cc: nd <nd at arm.com>
Subject: Re: [External] : RE: Question on the inline type flattening decision



Hi Xiaohong, Fred,





> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.



On final field flatting, it's good to always flatten them to enhance constant folding opportunities for C2 compiler. We may have an InlineTypeNodes with high indegree, but a getfield will always get hold of constant value.



For a field to be a true constant should we not check for both static and final accesses?



Alternatively, since a primitive/value class objects are immutable with implicit final fields unless object in larval state so we may also relax final access check, WDYT ?



Best Regards,

Jatin





________________________________

From: valhalla-dev <valhalla-dev-retn at openjdk.org<mailto:valhalla-dev-retn at openjdk.org>> on behalf of Frederic Parain <frederic.parain at oracle.com<mailto:frederic.parain at oracle.com>>
Sent: Thursday, July 6, 2023 6:28:16 PM
To: Xiaohong Gong <Xiaohong.Gong at arm.com<mailto:Xiaohong.Gong at arm.com>>; valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org> <valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org>>
Cc: nd <nd at arm.com<mailto:nd at arm.com>>
Subject: Re: [External] : RE: Question on the inline type flattening decision



Hi Xiaohong,


I would recommend to modify the test driving the flattening decisions
the following way:

if (InlineFieldMaxFlatSize != 0

      && (!(too_big_to_flatten | too_atomic_to_flatten |
too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {


By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
obvious that this is the way to completely disable field flattening.

The second term would remain the more specific tests on the field's
properties to decide to flatten or not when flattening is enabled.


What do you think of this proposal?


Best Regards,


Fred


On 7/2/23 9:23 PM, Xiaohong Gong wrote:
> Hi Frederic,
>
> Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not sure how to handle the relationship with "final" fields.
>
> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.
>
> Another is changing the followed "||" to "&&", so that only the "final" fields that match the preconditions can be flattened.
>
> So which one do you think is the defined behavior? The first one sounds reasonable to me. WDYT? Thanks a lot!
>
> BTW, I'v filed this issue to: https://bugs.openjdk.org/browse/JDK-8311219
>
> Best Regards,
> Xiaohong
>
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com<mailto:frederic.parain at oracle.com>>
> Sent: Friday, June 30, 2023 9:28 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com<mailto:Xiaohong.Gong at arm.com>>; valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org>
> Cc: nd <nd at arm.com<mailto:nd at arm.com>>
> Subject: Re: Question on the inline type flattening decision
>
> Hi Xiaohong,
>
>
> Thank you for reporting this. It looks like a bug to me, specifying
> -XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including final fields.
>
> Do you want to fill a bug report or do you want me to take care of it?
>
>
> Best Regards,
>
>
> Fred
>
>
> On 6/30/23 3:04 AM, Xiaohong Gong wrote:
>> Hi,
>>
>> I guess this is the right place to ask this question related to the
>> flattening decision on inline type fields?
>>
>> I met an issue when I was running the tests under
>> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with
>> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing by
>> forcing the inline type fields not be flattened.  And I debugged some
>> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`.  But I
>> found that the code path has no difference, which means this flag
>> cannot work and the field is flattened as without this flag.
>>
>> And then, I checked the relative code
>> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$<https://urldefense.com/v3/__https:/github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$>
>> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
>> the three necessary conditions (i.e.
>> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or
>> ?volatile? fields) firstly, which is the right behavior I think. But
>> then the result is ?||? with the `final` access flag. Which means if
>> the field is `final`, it will be flattened anyway regardless of the
>> necessary three limitations.
>>
>> So is this the expected behavior? Does this mean the inline type field
>> can always be flattened if it is declared with `final`? But I didn?t
>> find any descriptions on the flattening decision related to the
>> `final` flag.
>>
>> Many thanks if any help on this!
>>
>> Best Regards,
>>
>> Xiaohong
>>


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

From xgong at openjdk.org  Fri Jul  7 06:55:38 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 7 Jul 2023 06:55:38 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport
Message-ID: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>

PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.

Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.

This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.

[1] https://github.com/openjdk/valhalla/pull/866
[2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
[3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
[4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527

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

Commit messages:
 - 8311610: [lworld+vector] Clean-up of vector allocation in class VectorSupport

Changes: https://git.openjdk.org/valhalla/pull/882/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=882&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311610
  Stats: 332 lines in 4 files changed: 24 ins; 298 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/882.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/882/head:pull/882

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


From xgong at openjdk.org  Fri Jul  7 06:55:39 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 7 Jul 2023 06:55:39 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport
In-Reply-To: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
Message-ID: <ZiH8rm2f4grfZTOeVU7XCP-Ra8Vrv7Z6_eAyTd3TLE4=.f748f93e-8065-4f6c-9c78-d31a3306378b@github.com>

On Fri, 7 Jul 2023 06:47:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
> 
> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
> 
> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
> 
> [1] https://github.com/openjdk/valhalla/pull/866
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527

Hi @jatin-bhateja, could you please take a look at this PR? This is a cleanup to the vector allocation code in `vectorSupport.cpp`, which could also fix the jtreg regressions. Thanks a lot!

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1624842414


From jbhateja at openjdk.org  Fri Jul  7 08:13:23 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Jul 2023 08:13:23 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport
In-Reply-To: <ZiH8rm2f4grfZTOeVU7XCP-Ra8Vrv7Z6_eAyTd3TLE4=.f748f93e-8065-4f6c-9c78-d31a3306378b@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <ZiH8rm2f4grfZTOeVU7XCP-Ra8Vrv7Z6_eAyTd3TLE4=.f748f93e-8065-4f6c-9c78-d31a3306378b@github.com>
Message-ID: <g-QibAAWqGLvT1oI8heq7cKJLQN-QJPd1EPkUk9f9bM=.185bdb4c-416e-407e-877d-fa36e00ba8e8@github.com>

On Fri, 7 Jul 2023 06:51:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Hi @jatin-bhateja, could you please take a look at this PR? This is a cleanup to the vector allocation code in `vectorSupport.cpp`, which could also fix the jtreg regressions. Thanks a lot!

Hi @XiaohongGong , 

We can sweep out explicit handling related to vector/mask/shuffle during deoptimization, only two additional thing which may be needed are as follows :-  
1/ Explicit larval flag setting on re-allocated vector payloads.
2/ Handling for non-flattened payloads under influence of InlineFieldMaxFlatSize.

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1624983718


From xgong at openjdk.org  Fri Jul  7 08:18:13 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 7 Jul 2023 08:18:13 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport
In-Reply-To: <g-QibAAWqGLvT1oI8heq7cKJLQN-QJPd1EPkUk9f9bM=.185bdb4c-416e-407e-877d-fa36e00ba8e8@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <ZiH8rm2f4grfZTOeVU7XCP-Ra8Vrv7Z6_eAyTd3TLE4=.f748f93e-8065-4f6c-9c78-d31a3306378b@github.com>
 <g-QibAAWqGLvT1oI8heq7cKJLQN-QJPd1EPkUk9f9bM=.185bdb4c-416e-407e-877d-fa36e00ba8e8@github.com>
Message-ID: <0ZRuPC3Lx07X2WLjRjslq3qdajdpvEgkcOrzvq-okBo=.cdc344df-66e0-41e1-b592-bdc5bdb14cce@github.com>

On Fri, 7 Jul 2023 08:09:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Hi @jatin-bhateja, could you please take a look at this PR? This is a cleanup to the vector allocation code in `vectorSupport.cpp`, which could also fix the jtreg regressions. Thanks a lot!
> 
> Hi @XiaohongGong ,
> 
> We can sweep out explicit handling related to vector/mask/shuffle during deoptimization, only two additional thing which may be needed are as follows :- 1/ Explicit larval flag setting on re-allocated vector payloads. 2/ Handling for non-flattened payloads under influence of InlineFieldMaxFlatSize.
> 
> Best Regards, Jatin

Yes, I forgot the setting to larval flag. I will add this later. For 2, currently I don't know that the "final" flag influence to the flatten field. Since the payload field is final in Vector API, maybe it can always be flattened as you said in the maillist, right? Besides, I think the normal re-allocation in deoptimization.cpp should also consider the non-flattened fields as well, isn't it?

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1624996693


From xgong at openjdk.org  Fri Jul  7 08:22:24 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 7 Jul 2023 08:22:24 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport
In-Reply-To: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
Message-ID: <EycrAKxkWU9lSvB4YPhDJPuwKjYgy386ulCatN42ECs=.a7e67852-d284-4ba5-bfef-b6bf4978cf4b@github.com>

On Fri, 7 Jul 2023 06:47:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
> 
> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
> 
> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
> 
> [1] https://github.com/openjdk/valhalla/pull/866
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527

Besides the vector api regressions, I met lots of crashes due to nullptr of the payload field. It looks like being caused by deoptmization as well, where the payload field is not allocated I guess. With the change in this PR, the crash cases increased. Do you have any idea about this?

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1625004552


From jatin.bhateja at intel.com  Fri Jul  7 08:59:48 2023
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Fri, 7 Jul 2023 08:59:48 +0000
Subject: CFV: New Valhalla Committer: Xiaohong Gong
Message-ID: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>

I hereby nominate Xiaohong Gong (OpenJDK name: xgong) to Valhalla Committer.



Xiaohong is a long-time committer in JDK and Panama Project. She

authored numerous bug fixes and enhancements in C2 and Vector API.



In the context of Valhalla Project, Xiaohong has contributed 5 patches to Valhalla

w.r.t Vector API implementation as value objects and primitive values (most

notably, [3] [4] in lworld branch [7] and [5] [6] in lworld+vector branch [8]).



Votes are due by 2023-07-21 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,

Jatin Bhateja



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



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



[3] https://github.com/openjdk/valhalla/commit/d8e7d2eb3837c6b18a2c88955ae2ab89667889bb

         8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer



[4] https://github.com/openjdk/valhalla/commit/53b40f92b5af2d438a340209c56bcc6e5af0378e

    8309650: [lworld] Fix mismatch inline type issue during method calls



[5] https://github.com/openjdk/valhalla/commit/4ce98c10963a989fd3ecb52ca346f479c0ae181a

    8307715: Integrate VectorMask/Shuffle with value/primitive classes



[6] https://github.com/openjdk/valhalla/commit/bb135138d1314e84bc1371cc9a9d425eafc26c70

    8311080: [lworld+vector] Fix jdk build failures with different options



[7] https://github.com/openjdk/valhalla/tree/lworld



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

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

From jatin.bhateja at intel.com  Fri Jul  7 09:00:45 2023
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Fri, 7 Jul 2023 09:00:45 +0000
Subject: CFV: New Valhalla Committer: Xiaohong Gong
In-Reply-To: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
References: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
Message-ID: <PH8PR11MB7967A00162A4052DC3C09385E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>

Vote: Yes

Best Regards,
Jatin

From: Bhateja, Jatin
Sent: Friday, July 7, 2023 2:30 PM
To: valhalla-dev at openjdk.java.net
Subject: CFV: New Valhalla Committer: Xiaohong Gong


I hereby nominate Xiaohong Gong (OpenJDK name: xgong) to Valhalla Committer.



Xiaohong is a long-time committer in JDK and Panama Project. She

authored numerous bug fixes and enhancements in C2 and Vector API.



In the context of Valhalla Project, Xiaohong has contributed 5 patches to Valhalla

w.r.t Vector API implementation as value objects and primitive values (most

notably, [3] [4] in lworld branch [7] and [5] [6] in lworld+vector branch [8]).



Votes are due by 2023-07-21 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,

Jatin Bhateja



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



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



[3] https://github.com/openjdk/valhalla/commit/d8e7d2eb3837c6b18a2c88955ae2ab89667889bb

         8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer



[4] https://github.com/openjdk/valhalla/commit/53b40f92b5af2d438a340209c56bcc6e5af0378e

    8309650: [lworld] Fix mismatch inline type issue during method calls



[5] https://github.com/openjdk/valhalla/commit/4ce98c10963a989fd3ecb52ca346f479c0ae181a

    8307715: Integrate VectorMask/Shuffle with value/primitive classes



[6] https://github.com/openjdk/valhalla/commit/bb135138d1314e84bc1371cc9a9d425eafc26c70

    8311080: [lworld+vector] Fix jdk build failures with different options



[7] https://github.com/openjdk/valhalla/tree/lworld



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

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

From tobias.hartmann at oracle.com  Fri Jul  7 11:44:23 2023
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 7 Jul 2023 13:44:23 +0200
Subject: CFV: New Valhalla Committer: Xiaohong Gong
In-Reply-To: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
References: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
Message-ID: <9ce104f5-c4fc-7cf6-2f38-c350e53ce241@oracle.com>

Vote: yes

Best regards,
Tobias

On 07.07.23 10:59, Bhateja, Jatin wrote:
> I hereby nominate Xiaohong Gong (OpenJDK name: xgong) to Valhalla Committer.
> 
> ?
> 
> Xiaohong is a long-time committer in JDK and Panama Project. She
> 
> authored numerous bug fixes and enhancements in C2 and Vector API.
> 
> ?
> 
> In the context of Valhalla Project, Xiaohong has contributed 5 patchesto?Valhalla
> 
> w.r.t Vector API implementation as value objects and primitive values (most
> 
> notably, [3] [4]in lworld branch [7] and [5] [6] in lworld+vector branch [8]).
> 
> ?
> 
> Votes are due by 2023-07-21 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,
> 
> Jatin Bhateja
> 
> ?
> 
> [1] https://openjdk.java.net/census <https://openjdk.java.net/census>
> 
> ?
> 
> [2] https://openjdk.java.net/projects/#committer-vote
> <https://openjdk.java.net/projects/#committer-vote>
> 
> ?
> 
> [3] https://github.com/openjdk/valhalla/commit/d8e7d2eb3837c6b18a2c88955ae2ab89667889bb
> <https://github.com/openjdk/valhalla/commit/d8e7d2eb3837c6b18a2c88955ae2ab89667889bb>
> 
> ????????8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer
> 
> ?
> 
> [4] https://github.com/openjdk/valhalla/commit/53b40f92b5af2d438a340209c56bcc6e5af0378e
> <https://github.com/openjdk/valhalla/commit/53b40f92b5af2d438a340209c56bcc6e5af0378e>
> 
> ???8309650: [lworld] Fix mismatch inline type issue during method calls
> 
> ?
> 
> [5] https://github.com/openjdk/valhalla/commit/4ce98c10963a989fd3ecb52ca346f479c0ae181a
> <https://github.com/openjdk/valhalla/commit/4ce98c10963a989fd3ecb52ca346f479c0ae181a>
> 
> ???8307715: Integrate VectorMask/Shuffle with value/primitive classes
> 
> ?
> 
> [6] https://github.com/openjdk/valhalla/commit/bb135138d1314e84bc1371cc9a9d425eafc26c70
> <https://github.com/openjdk/valhalla/commit/bb135138d1314e84bc1371cc9a9d425eafc26c70>
> 
> ???8311080: [lworld+vector] Fix jdk build failures with different options
> 
> ?
> 
> [7] https://github.com/openjdk/valhalla/tree/lworld <https://github.com/openjdk/valhalla/tree/lworld>
> 
> ?
> 
> [8] https://github.com/openjdk/valhalla/tree/lworld+vector
> <https://github.com/openjdk/valhalla/tree/lworld+vector>
> 
> ?
> 


From xgong at openjdk.org  Fri Jul  7 13:14:33 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 7 Jul 2023 13:14:33 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v2]
In-Reply-To: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
Message-ID: <rI-dtR9jKGr_r0Ow6n2DYJA7Pyt6tB3hICizyaYrG7w=.f6dbec73-7b84-4aac-ad23-4cd0dcab9af2@github.com>

> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
> 
> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
> 
> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
> 
> [1] https://github.com/openjdk/valhalla/pull/866
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527

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

  Set larval state for inline type objects

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/882/files
  - new: https://git.openjdk.org/valhalla/pull/882/files/879a524e..df73fc82

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

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

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


From vladimir.x.ivanov at oracle.com  Fri Jul  7 17:16:54 2023
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 7 Jul 2023 10:16:54 -0700
Subject: CFV: New Valhalla Committer: Xiaohong Gong
In-Reply-To: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
References: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
Message-ID: <1d113f89-4a74-1245-2520-83ed8dd7a510@oracle.com>

Vote: yes

Best regards,
Vladimir Ivanov

On 7/7/23 01:59, Bhateja, Jatin wrote:
> I hereby nominate Xiaohong Gong (OpenJDK name: xgong) to Valhalla Committer.
> 


From fparain at openjdk.org  Fri Jul  7 18:05:33 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 7 Jul 2023 18:05:33 GMT
Subject: [lworld] RFR: 8309357: [lworld] CDS is broken with InlineKlasses after
 the merge
Message-ID: <yWKI5_AgeVg9fm8CePBIVnBEVC9JqnkECsdIIKuk34U=.e1e3a97f-e518-4503-a20a-ca7a8e06c0a0@github.com>

Fix the restoration of the internal pointer to the inlineklass_fixed_block when an InlineKlass is loaded from a CDS archive.
Fix the setting of the new calling convention flags when the constMethod object is shared through CDS.

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

Commit messages:
 - Fix inlineklass_fixed_block ptr and calling convention flags setting

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

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


From jbhateja at openjdk.org  Sat Jul  8 07:07:17 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 8 Jul 2023 07:07:17 GMT
Subject: [lworld] RFR: 8309357: [lworld] CDS is broken with InlineKlasses
 after the merge
In-Reply-To: <yWKI5_AgeVg9fm8CePBIVnBEVC9JqnkECsdIIKuk34U=.e1e3a97f-e518-4503-a20a-ca7a8e06c0a0@github.com>
References: <yWKI5_AgeVg9fm8CePBIVnBEVC9JqnkECsdIIKuk34U=.e1e3a97f-e518-4503-a20a-ca7a8e06c0a0@github.com>
Message-ID: <D_T2mPuT3MhBFYwnKp5rlP7r575JlzrfVqVh4RTEq1A=.39a58f24-2617-4022-97f1-81c405b14620@github.com>

On Fri, 7 Jul 2023 17:57:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix the restoration of the internal pointer to the inlineklass_fixed_block when an InlineKlass is loaded from a CDS archive.
> Fix the setting of the new calling convention flags when the constMethod object is shared through CDS.

Patch looks good to me.

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

> 3175:   if (ces.has_scalarized_args()) {
> 3176:     if (!method->has_scalarized_args()) {
> 3177:       assert(!method()->constMethod()->is_shared(), "Cannot update shared const object");

Is this assertion mandatory ? since shared archives are mapped with MAP_PRIVATE flag [ (on linux)](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/os/linux/os_linux.cpp#L3418) thus it  follow COW semantics, any update to shared mapped region will clone the physical frame before update.

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

PR Review: https://git.openjdk.org/valhalla/pull/883#pullrequestreview-1520663647
PR Review Comment: https://git.openjdk.org/valhalla/pull/883#discussion_r1257107264


From jbhateja at openjdk.org  Mon Jul 10 01:38:26 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 10 Jul 2023 01:38:26 GMT
Subject: [lworld] RFR: 8311383: Restoring inline class mirrors with CDS.
Message-ID: <OZPs14xUHUlTBjIA01K7YgQQpwudfQJy45DXb8HSCes=.fd7a9d40-77f3-473d-bc30-f4bd76bcd848@github.com>

Inline class encapsulate following two mirror objects
  - Value mirror : primitive value class instance
  - Reference mirror  : primitive reference class instance ( .ref)
 
Currently, runtime allocates and updates java mirror corresponding to a klass in a scratch memory and dumps [1] these into shared archive.  Skipping over allocating inline mirrors into scratch memory for the time being since they can be re-created while restoring unshared fields of inline class[2] during share archive read. 

[1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/cds/heapShared.cpp#L392
[2] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/oops/klass.cpp#L624

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

Commit messages:
 - 8311383: Restoring inline class mirrors with CDS.

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

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


From jbhateja at openjdk.org  Mon Jul 10 01:42:15 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 10 Jul 2023 01:42:15 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport
In-Reply-To: <EycrAKxkWU9lSvB4YPhDJPuwKjYgy386ulCatN42ECs=.a7e67852-d284-4ba5-bfef-b6bf4978cf4b@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <EycrAKxkWU9lSvB4YPhDJPuwKjYgy386ulCatN42ECs=.a7e67852-d284-4ba5-bfef-b6bf4978cf4b@github.com>
Message-ID: <iT1Akeuc4dKs9skANBK2_5Z0J7TTAe2eP6H_Jx0q57M=.f3793a86-a778-4aa0-84ff-2c41a236fda2@github.com>

On Fri, 7 Jul 2023 08:19:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Besides the vector api regressions, I met lots of crashes due to nullptr of the payload field. It looks like being caused by deoptmization as well, where the payload field is not allocated I guess. With the change in this PR, the crash cases increased. Do you have any idea about this?

Can you try integrating https://github.com/openjdk/valhalla/pull/884 locally and check if it resolves the crashes.

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1627933632


From xgong at openjdk.org  Mon Jul 10 02:12:18 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 10 Jul 2023 02:12:18 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v2]
In-Reply-To: <rI-dtR9jKGr_r0Ow6n2DYJA7Pyt6tB3hICizyaYrG7w=.f6dbec73-7b84-4aac-ad23-4cd0dcab9af2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <rI-dtR9jKGr_r0Ow6n2DYJA7Pyt6tB3hICizyaYrG7w=.f6dbec73-7b84-4aac-ad23-4cd0dcab9af2@github.com>
Message-ID: <k-90D-weDC93YWv2tocWsD9hzqnsx3gqig6aYmdBmZk=.f03e5834-7e37-4e32-87be-401455df3e2d@github.com>

On Fri, 7 Jul 2023 13:14:33 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
>> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
>> 
>> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
>> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
>> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
>> 
>> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
>> 
>> [1] https://github.com/openjdk/valhalla/pull/866
>> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
>> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
>> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set larval state for inline type objects

> > Besides the vector api regressions, I met lots of crashes due to nullptr of the payload field. It looks like being caused by deoptmization as well, where the payload field is not allocated I guess. With the change in this PR, the crash cases increased. Do you have any idea about this?
> 
> Can you try integrating #884 locally and check if it resolves the crashes.

Thanks for the patch! I tested with it, but unfortunatelly, the crash is still there. I will look at this issue today. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1627967582


From jbhateja at openjdk.org  Mon Jul 10 03:15:19 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 10 Jul 2023 03:15:19 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v2]
In-Reply-To: <rI-dtR9jKGr_r0Ow6n2DYJA7Pyt6tB3hICizyaYrG7w=.f6dbec73-7b84-4aac-ad23-4cd0dcab9af2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <rI-dtR9jKGr_r0Ow6n2DYJA7Pyt6tB3hICizyaYrG7w=.f6dbec73-7b84-4aac-ad23-4cd0dcab9af2@github.com>
Message-ID: <L2EGN8Z961p5zISauWmoHSFSIz_qiRpVAgvVq-K2IFM=.723a3a5d-61ee-4685-be90-bda89d37c3b2@github.com>

On Fri, 7 Jul 2023 13:14:33 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
>> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
>> 
>> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
>> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
>> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
>> 
>> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
>> 
>> [1] https://github.com/openjdk/valhalla/pull/866
>> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
>> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
>> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set larval state for inline type objects

> > > Besides the vector api regressions, I met lots of crashes due to nullptr of the payload field. It looks like being caused by deoptmization as well, where the payload field is not allocated I guess. With the change in this PR, the crash cases increased. Do you have any idea about this?
> > 
> > 
> > Can you try integrating #884 locally and check if it resolves the crashes.
> 
> Thanks for the patch! I tested with it, but unfortunatelly, the crash is still there. I will look at this issue today. Thanks!

> > > Besides the vector api regressions, I met lots of crashes due to nullptr of the payload field. It looks like being caused by deoptmization as well, where the payload field is not allocated I guess. With the change in this PR, the crash cases increased. Do you have any idea about this?
> > 
> > 
> > Can you try integrating #884 locally and check if it resolves the crashes.
> 
> Thanks for the patch! I tested with it, but unfortunatelly, the crash is still there. I will look at this issue today. Thanks!

Are you referring to following assertion failures which are seen without -Xshare:off

test Float256VectorTests.unsliceUnaryFloat256VectorTests(float[-i * 5]): failure
java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.vm.vector.VectorSupport$VectorPayloadMF256F
	at java.base/jdk.internal.vm.vector.VectorSupport$VectorPayloadMF.newInstanceFactory(VectorSupport.java:220)
	at jdk.incubator.vector/jdk.incubator.vector.AbstractSpecies.makeDummyVectorMF(AbstractSpecies.java:369)
	at jdk.incubator.vector/jdk.incubator.vector.AbstractSpecies.dummyVectorMF(AbstractSpecies.java:327)
	at jdk.incubator.vector/jdk.incubator.vector.FloatVector$FloatSpecies.dummyVectorMF(FloatVector.java:3859)
	at jdk.incubator.vector/jdk.incubator.vector.FloatVector.fromArray(FloatVector.java:2894)
	at Float256VectorTests.unsliceUnaryFloat256VectorTests(Float256VectorTests.java:3633)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1628019413


From xgong at openjdk.org  Mon Jul 10 03:26:16 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 10 Jul 2023 03:26:16 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v2]
In-Reply-To: <L2EGN8Z961p5zISauWmoHSFSIz_qiRpVAgvVq-K2IFM=.723a3a5d-61ee-4685-be90-bda89d37c3b2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <rI-dtR9jKGr_r0Ow6n2DYJA7Pyt6tB3hICizyaYrG7w=.f6dbec73-7b84-4aac-ad23-4cd0dcab9af2@github.com>
 <L2EGN8Z961p5zISauWmoHSFSIz_qiRpVAgvVq-K2IFM=.723a3a5d-61ee-4685-be90-bda89d37c3b2@github.com>
Message-ID: <Gv-aWFsU9xOmz0synBZVIBm151BIZKIA7BIPijkuEYQ=.c1386e86-cde9-4dbd-a7ae-808870004bbf@github.com>

On Mon, 10 Jul 2023 03:12:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > > Besides the vector api regressions, I met lots of crashes due to nullptr of the payload field. It looks like being caused by deoptmization as well, where the payload field is not allocated I guess. With the change in this PR, the crash cases increased. Do you have any idea about this?
> > > 
> > > 
> > > Can you try integrating #884 locally and check if it resolves the crashes.
> > 
> > 
> > Thanks for the patch! I tested with it, but unfortunatelly, the crash is still there. I will look at this issue today. Thanks!
> 
> > > > Besides the vector api regressions, I met lots of crashes due to nullptr of the payload field. It looks like being caused by deoptmization as well, where the payload field is not allocated I guess. With the change in this PR, the crash cases increased. Do you have any idea about this?
> > > 
> > > 
> > > Can you try integrating #884 locally and check if it resolves the crashes.
> > 
> > 
> > Thanks for the patch! I tested with it, but unfortunatelly, the crash is still there. I will look at this issue today. Thanks!
> 
> Are you referring to following assertion failures which are seen without -Xshare:off
> 
> ```
> test Float256VectorTests.unsliceUnaryFloat256VectorTests(float[-i * 5]): failure
> java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.vm.vector.VectorSupport$VectorPayloadMF256F
> 	at java.base/jdk.internal.vm.vector.VectorSupport$VectorPayloadMF.newInstanceFactory(VectorSupport.java:220)
> 	at jdk.incubator.vector/jdk.incubator.vector.AbstractSpecies.makeDummyVectorMF(AbstractSpecies.java:369)
> 	at jdk.incubator.vector/jdk.incubator.vector.AbstractSpecies.dummyVectorMF(AbstractSpecies.java:327)
> 	at jdk.incubator.vector/jdk.incubator.vector.FloatVector$FloatSpecies.dummyVectorMF(FloatVector.java:3859)
> 	at jdk.incubator.vector/jdk.incubator.vector.FloatVector.fromArray(FloatVector.java:2894)
> 	at Float256VectorTests.unsliceUnaryFloat256VectorTests(Float256VectorTests.java:3633)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> 	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> 	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> 	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> ```

I didn't see this failure without `-Xshare:off` on NEON. You could also reproduce the crash with "-XX:-EnableVectorSupport" when run a jtreg that the hardware doesn't support the vectorization for it. For example, maybe running the 512 species tests with "-XX:UseAVX=2". The crash I met looks like the null point for payload instance. Here is the log:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffffa8c47860, pid=263319, tid=263339
#
# JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-7aa742799)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-7aa742799, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# j  jdk.incubator.vector.FloatVector.uOpTemplateMF(Ljdk/incubator/vector/VectorMask;Ljdk/incubator/vector/FloatVector$FUnOp;)Ljdk/incubator/vector/FloatVector;+11 jdk.incubator.vector at 21-internal
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /mnt/local/code/jtreg/jtreg-git/build/images/jtreg/jtwork/scratch/0/core.263319)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1628035476


From frederic.parain at oracle.com  Mon Jul 10 15:09:28 2023
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 10 Jul 2023 11:09:28 -0400
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
Message-ID: <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>

Hi Xiaohong,


Field flattening has two major side effects: atomicity and size.

Final fields are not subject to atomicity issues because they are 
immutable after their initialization.

Both final and non-final fields have an impact on the object size, and 
potentially on cache behavior.
Bigger objects are less likely to fit in data caches, and bigger 
distances between fields would require
more cache lines and more cache misses to read them. This issue is not 
significant when accessing fields
of a single object, but it can become dominant when accessing fields of 
objects stored in a flat array.

So, in theory, the flattening test should be:

 ? if (!((!fieldinfo.access_flags().is_final() && (too_atomic_to_flatten 
|| too_volatile_to_flatten))
 ??????? || too_big_to_flatten)) {

Atomicity constraints are considered only for non-final fields, and size 
constraints are considered
for all fields.


That being said, we have always been more aggressive in the flattening 
of final fields because it was
beneficial to C2.

At this point, I don't think I have the data to say which flattening 
policy is better.

Best Regards,


Fred


On 7/6/23 9:53 PM, Xiaohong Gong wrote:
> Hi Fred,
>
>> I would recommend to modify the test driving the flattening decisions the following way:
>>
>> if (InlineFieldMaxFlatSize != 0
>>
>>        && (!(too_big_to_flatten | too_atomic_to_flatten |
>> too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
>>
>>
>> By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
>> obvious that this is the way to completely disable field flattening.
>>
>> The second term would remain the more specific tests on the field's
>> properties to decide to flatten or not when flattening is enabled.
>>
>>
>> What do you think of this proposal?
> Thanks for the proposal! But this looks more like a workaround for me. Actually this can
> disable the field flattening with "-XX:InlineFieldMaxFlatSize=0". But what if setting it to
> other small value like "2" ? That is, the field can be flattened if its holder class size is larger
> than the specified max flat size, isn't it?
>
> Thanks,
> Xiaohong
>
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com>
> Sent: Thursday, July 6, 2023 8:57 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
> Cc: nd <nd at arm.com>
> Subject: Re: [External] : RE: Question on the inline type flattening decision
>
> Hi Xiaohong,
>
>
> I would recommend to modify the test driving the flattening decisions the following way:
>
> if (InlineFieldMaxFlatSize != 0
>
>   ???? && (!(too_big_to_flatten | too_atomic_to_flatten |
> too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
>
>
> By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
> obvious that this is the way to completely disable field flattening.
>
> The second term would remain the more specific tests on the field's
> properties to decide to flatten or not when flattening is enabled.
>
>
> What do you think of this proposal?
>
>
> Best Regards,
>
>
> Fred
>
>
> On 7/2/23 9:23 PM, Xiaohong Gong wrote:
>> Hi Frederic,
>>
>> Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not sure how to handle the relationship with "final" fields.
>>
>> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.
>>
>> Another is changing the followed "||" to "&&", so that only the "final" fields that match the preconditions can be flattened.
>>
>> So which one do you think is the defined behavior? The first one sounds reasonable to me. WDYT? Thanks a lot!
>>
>> BTW, I'v filed this issue to: https://bugs.openjdk.org/browse/JDK-8311219
>>
>> Best Regards,
>> Xiaohong
>>
>> -----Original Message-----
>> From: Frederic Parain <frederic.parain at oracle.com>
>> Sent: Friday, June 30, 2023 9:28 PM
>> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
>> Cc: nd <nd at arm.com>
>> Subject: Re: Question on the inline type flattening decision
>>
>> Hi Xiaohong,
>>
>>
>> Thank you for reporting this. It looks like a bug to me, specifying
>> -XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including final fields.
>>
>> Do you want to fill a bug report or do you want me to take care of it?
>>
>>
>> Best Regards,
>>
>>
>> Fred
>>
>>
>> On 6/30/23 3:04 AM, Xiaohong Gong wrote:
>>> Hi,
>>>
>>> I guess this is the right place to ask this question related to the
>>> flattening decision on inline type fields?
>>>
>>> I met an issue when I was running the tests under
>>> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with
>>> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing by
>>> forcing the inline type fields not be flattened. ?And I debugged some
>>> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`. ?But I
>>> found that the code path has no difference, which means this flag
>>> cannot work and the field is flattened as without this flag.
>>>
>>> And then, I checked the relative code
>>> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$
>>> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
>>> the three necessary conditions (i.e.
>>> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or
>>> ?volatile? fields) firstly, which is the right behavior I think. But
>>> then the result is ?||? with the `final` access flag. Which means if
>>> the field is `final`, it will be flattened anyway regardless of the
>>> necessary three limitations.
>>>
>>> So is this the expected behavior? Does this mean the inline type field
>>> can always be flattened if it is declared with `final`? But I didn?t
>>> find any descriptions on the flattening decision related to the
>>> `final` flag.
>>>
>>> Many thanks if any help on this!
>>>
>>> Best Regards,
>>>
>>> Xiaohong
>>>


From fparain at openjdk.org  Mon Jul 10 15:20:25 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 10 Jul 2023 15:20:25 GMT
Subject: [lworld] RFR: 8309357: [lworld] CDS is broken with InlineKlasses
 after the merge
In-Reply-To: <D_T2mPuT3MhBFYwnKp5rlP7r575JlzrfVqVh4RTEq1A=.39a58f24-2617-4022-97f1-81c405b14620@github.com>
References: <yWKI5_AgeVg9fm8CePBIVnBEVC9JqnkECsdIIKuk34U=.e1e3a97f-e518-4503-a20a-ca7a8e06c0a0@github.com>
 <D_T2mPuT3MhBFYwnKp5rlP7r575JlzrfVqVh4RTEq1A=.39a58f24-2617-4022-97f1-81c405b14620@github.com>
Message-ID: <iX6p6XFcrxtHDQ9VHWu0nMYZsxrHF4rOmD6nJfqjTqo=.f55006ce-2c48-44b7-af33-82e51e88c264@github.com>

On Sat, 8 Jul 2023 07:03:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Fix the restoration of the internal pointer to the inlineklass_fixed_block when an InlineKlass is loaded from a CDS archive.
>> Fix the setting of the new calling convention flags when the constMethod object is shared through CDS.
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 3177:
> 
>> 3175:   if (ces.has_scalarized_args()) {
>> 3176:     if (!method->has_scalarized_args()) {
>> 3177:       assert(!method()->constMethod()->is_shared(), "Cannot update shared const object");
> 
> Is this assertion mandatory ? since shared archives are mapped with MAP_PRIVATE flag [ (on linux)](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/os/linux/os_linux.cpp#L3418) thus it  follow COW semantics, any update to shared mapped region will clone the physical frame before update.

Shared archives are split in two regions. The writable part is using the COW semantic, but all the "const*" metadata are in an unique read-only region.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/883#discussion_r1258424591


From fparain at openjdk.org  Mon Jul 10 15:20:25 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 10 Jul 2023 15:20:25 GMT
Subject: [lworld] Integrated: 8309357: [lworld] CDS is broken with
 InlineKlasses after the merge
In-Reply-To: <yWKI5_AgeVg9fm8CePBIVnBEVC9JqnkECsdIIKuk34U=.e1e3a97f-e518-4503-a20a-ca7a8e06c0a0@github.com>
References: <yWKI5_AgeVg9fm8CePBIVnBEVC9JqnkECsdIIKuk34U=.e1e3a97f-e518-4503-a20a-ca7a8e06c0a0@github.com>
Message-ID: <pQ3QERRUj4ufTNZQ6kliqTU2U7mfLBOK4rnK_-muOcQ=.e4c34e2c-75d9-4f3f-8484-8c7939ba160a@github.com>

On Fri, 7 Jul 2023 17:57:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix the restoration of the internal pointer to the inlineklass_fixed_block when an InlineKlass is loaded from a CDS archive.
> Fix the setting of the new calling convention flags when the constMethod object is shared through CDS.

This pull request has now been integrated.

Changeset: 7e09a28a
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7e09a28ad89d3f31dc3626b3667b4ae13bcbd326
Stats:     15 lines in 4 files changed: 9 ins; 3 del; 3 mod

8309357: [lworld] CDS is broken with InlineKlasses after the merge

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

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


From Xiaohong.Gong at arm.com  Tue Jul 11 07:16:17 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Tue, 11 Jul 2023 07:16:17 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
 <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>
Message-ID: <DB9PR08MB77470E010B9D116B8B2EE7FCF531A@DB9PR08MB7747.eurprd08.prod.outlook.com>

Hi Fred,

Thanks for the updating!

> Field flattening has two major side effects: atomicity and size.
> 
> Final fields are not subject to atomicity issues because they are immutable after their initialization.
> 
> Both final and non-final fields have an impact on the object size, and potentially on cache behavior.
> Bigger objects are less likely to fit in data caches, and bigger distances between fields would require more cache lines and more cache misses to read them. This issue is not significant when accessing fields of a single object, but it can become dominant when accessing fields of objects stored in a flat array.
> 
> So, in theory, the flattening test should be:
> 
>    if (!((!fieldinfo.access_flags().is_final() && (too_atomic_to_flatten 
> || too_volatile_to_flatten))
>          || too_big_to_flatten)) {
> 
> Atomicity constraints are considered only for non-final fields, and size constraints are considered for all fields.

This sounds reasonable to me. So final fields with larger size is not better to be flattened. Thanks a lot! I will fix it in few days.

Best Regards,
Xiaohong

-----Original Message-----
From: Frederic Parain <frederic.parain at oracle.com> 
Sent: Monday, July 10, 2023 11:09 PM
To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
Cc: nd <nd at arm.com>
Subject: Re: [External] : RE: Question on the inline type flattening decision

Hi Xiaohong,


Field flattening has two major side effects: atomicity and size.

Final fields are not subject to atomicity issues because they are immutable after their initialization.

Both final and non-final fields have an impact on the object size, and potentially on cache behavior.
Bigger objects are less likely to fit in data caches, and bigger distances between fields would require more cache lines and more cache misses to read them. This issue is not significant when accessing fields of a single object, but it can become dominant when accessing fields of objects stored in a flat array.

So, in theory, the flattening test should be:

 ? if (!((!fieldinfo.access_flags().is_final() && (too_atomic_to_flatten 
|| too_volatile_to_flatten))
 ??????? || too_big_to_flatten)) {

Atomicity constraints are considered only for non-final fields, and size constraints are considered for all fields.


That being said, we have always been more aggressive in the flattening 
of final fields because it was
beneficial to C2.

At this point, I don't think I have the data to say which flattening 
policy is better.

Best Regards,


Fred


On 7/6/23 9:53 PM, Xiaohong Gong wrote:
> Hi Fred,
>
>> I would recommend to modify the test driving the flattening decisions the following way:
>>
>> if (InlineFieldMaxFlatSize != 0
>>
>>        && (!(too_big_to_flatten | too_atomic_to_flatten |
>> too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
>>
>>
>> By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
>> obvious that this is the way to completely disable field flattening.
>>
>> The second term would remain the more specific tests on the field's
>> properties to decide to flatten or not when flattening is enabled.
>>
>>
>> What do you think of this proposal?
> Thanks for the proposal! But this looks more like a workaround for me. Actually this can
> disable the field flattening with "-XX:InlineFieldMaxFlatSize=0". But what if setting it to
> other small value like "2" ? That is, the field can be flattened if its holder class size is larger
> than the specified max flat size, isn't it?
>
> Thanks,
> Xiaohong
>
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com>
> Sent: Thursday, July 6, 2023 8:57 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
> Cc: nd <nd at arm.com>
> Subject: Re: [External] : RE: Question on the inline type flattening decision
>
> Hi Xiaohong,
>
>
> I would recommend to modify the test driving the flattening decisions the following way:
>
> if (InlineFieldMaxFlatSize != 0
>
>   ???? && (!(too_big_to_flatten | too_atomic_to_flatten |
> too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
>
>
> By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
> obvious that this is the way to completely disable field flattening.
>
> The second term would remain the more specific tests on the field's
> properties to decide to flatten or not when flattening is enabled.
>
>
> What do you think of this proposal?
>
>
> Best Regards,
>
>
> Fred
>
>
> On 7/2/23 9:23 PM, Xiaohong Gong wrote:
>> Hi Frederic,
>>
>> Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not sure how to handle the relationship with "final" fields.
>>
>> One is removing the followed "field" access check, which means the fields can be flattened no matter whether the field is "final" or not.
>>
>> Another is changing the followed "||" to "&&", so that only the "final" fields that match the preconditions can be flattened.
>>
>> So which one do you think is the defined behavior? The first one sounds reasonable to me. WDYT? Thanks a lot!
>>
>> BTW, I'v filed this issue to: https://bugs.openjdk.org/browse/JDK-8311219
>>
>> Best Regards,
>> Xiaohong
>>
>> -----Original Message-----
>> From: Frederic Parain <frederic.parain at oracle.com>
>> Sent: Friday, June 30, 2023 9:28 PM
>> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
>> Cc: nd <nd at arm.com>
>> Subject: Re: Question on the inline type flattening decision
>>
>> Hi Xiaohong,
>>
>>
>> Thank you for reporting this. It looks like a bug to me, specifying
>> -XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including final fields.
>>
>> Do you want to fill a bug report or do you want me to take care of it?
>>
>>
>> Best Regards,
>>
>>
>> Fred
>>
>>
>> On 6/30/23 3:04 AM, Xiaohong Gong wrote:
>>> Hi,
>>>
>>> I guess this is the right place to ask this question related to the
>>> flattening decision on inline type fields?
>>>
>>> I met an issue when I was running the tests under
>>> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with
>>> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing by
>>> forcing the inline type fields not be flattened. ?And I debugged some
>>> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`. ?But I
>>> found that the code path has no difference, which means this flag
>>> cannot work and the field is flattened as without this flag.
>>>
>>> And then, I checked the relative code
>>> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWckchOY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrHk3ys7z-iq8Q$
>>> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
>>> the three necessary conditions (i.e.
>>> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or
>>> ?volatile? fields) firstly, which is the right behavior I think. But
>>> then the result is ?||? with the `final` access flag. Which means if
>>> the field is `final`, it will be flattened anyway regardless of the
>>> necessary three limitations.
>>>
>>> So is this the expected behavior? Does this mean the inline type field
>>> can always be flattened if it is declared with `final`? But I didn?t
>>> find any descriptions on the flattening decision related to the
>>> `final` flag.
>>>
>>> Many thanks if any help on this!
>>>
>>> Best Regards,
>>>
>>> Xiaohong
>>>

From jatin.bhateja at intel.com  Tue Jul 11 10:00:09 2023
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Tue, 11 Jul 2023 10:00:09 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <DB9PR08MB77470E010B9D116B8B2EE7FCF531A@DB9PR08MB7747.eurprd08.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
 <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>
 <DB9PR08MB77470E010B9D116B8B2EE7FCF531A@DB9PR08MB7747.eurprd08.prod.outlook.com>
Message-ID: <PH8PR11MB796728D7D2B4C98A2BBBF926E831A@PH8PR11MB7967.namprd11.prod.outlook.com>



> -----Original Message-----
> From: valhalla-dev <valhalla-dev-retn at openjdk.org> On Behalf Of Xiaohong
> Gong
> Sent: Tuesday, July 11, 2023 12:46 PM
> To: Frederic Parain <frederic.parain at oracle.com>; valhalla-dev at openjdk.org
> Cc: nd <nd at arm.com>
> Subject: RE: [External] : RE: Question on the inline type flattening decision
> 
> Hi Fred,
> 
> Thanks for the updating!
> 
> > Field flattening has two major side effects: atomicity and size.
> >
> > Final fields are not subject to atomicity issues because they are immutable
> after their initialization.
> >
> > Both final and non-final fields have an impact on the object size, and
> potentially on cache behavior.
> > Bigger objects are less likely to fit in data caches, and bigger distances
> between fields would require more cache lines and more cache misses to
> read them. This issue is not significant when accessing fields of a single
> object, but it can become dominant when accessing fields of objects stored
> in a flat array.
> >
> > So, in theory, the flattening test should be:
> >
> >    if (!((!fieldinfo.access_flags().is_final() &&
> > (too_atomic_to_flatten
> > || too_volatile_to_flatten))
> >          || too_big_to_flatten)) {
> >
> > Atomicity constraints are considered only for non-final fields, and size
> constraints are considered for all fields.
> 
> This sounds reasonable to me. So final fields with larger size is not better to
> be flattened. Thanks a lot! I will fix it in few days.


Few more observations on this:-

   -  Flattening a value field of an identity object appears space efficient since we may be able to save on header bits (exact_size vs instance_size).

   - In the long run, aggressively in-lining value fields of an identity object may have caching penalties (as Fred also pointed out) and we may also miss out on interning opportunities given that values are immutable.
 
I also discovered that currently we are not folding the logic around truly constant field access, in the following case I expected most of the field access w.r.t to root to get folded by compiler.
However, if we make large_inline_fields_holder a value class then constant folding gets enforced, ideally from a usage standpoint a method taking all constant value argument should be closer to
c++11 constexpr semantics.

value class payload {
   long f1;
   long f2;
   public payload(long f1, long f2) {
      this.f1 = f1;
      this.f2 = f2;
   }
}

public class large_inline_fields_holder {
   public payload lf1;
   public payload lf2;
   public static final large_inline_fields_holder root = new large_inline_fields_holder(10);

   public large_inline_fields_holder(long val) {
      lf1 = new payload(val , val + 10);
      lf2 = new payload(val + 20 , val + 30);
   }

   public static long micro (int i) {
      return root.lf1.f1 + root.lf1.f2 + root.lf2.f1 + root.lf2.f2 + i;    
   }

   public static void main(String [] args) {
      long res = 0;
      for (int i = 0; i < 10000; i++) {
          res += micro(i);
      }
      System.out.println(res);
   }
}

> 
> Best Regards,
> Xiaohong
> 
> -----Original Message-----
> From: Frederic Parain <frederic.parain at oracle.com>
> Sent: Monday, July 10, 2023 11:09 PM
> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org
> Cc: nd <nd at arm.com>
> Subject: Re: [External] : RE: Question on the inline type flattening decision
> 
> Hi Xiaohong,
> 
> 
> Field flattening has two major side effects: atomicity and size.
> 
> Final fields are not subject to atomicity issues because they are immutable
> after their initialization.
> 
> Both final and non-final fields have an impact on the object size, and
> potentially on cache behavior.
> Bigger objects are less likely to fit in data caches, and bigger distances
> between fields would require more cache lines and more cache misses to
> read them. This issue is not significant when accessing fields of a single
> object, but it can become dominant when accessing fields of objects stored
> in a flat array.
> 
> So, in theory, the flattening test should be:
> 
>  ? if (!((!fieldinfo.access_flags().is_final() && (too_atomic_to_flatten
> || too_volatile_to_flatten))
>  ??????? || too_big_to_flatten)) {
> 
> Atomicity constraints are considered only for non-final fields, and size
> constraints are considered for all fields.
> 
> 
> That being said, we have always been more aggressive in the flattening of
> final fields because it was beneficial to C2.
> 
> At this point, I don't think I have the data to say which flattening policy is
> better.
> 
> Best Regards,
> 
> 
> Fred
> 
> 
> On 7/6/23 9:53 PM, Xiaohong Gong wrote:
> > Hi Fred,
> >
> >> I would recommend to modify the test driving the flattening decisions
> the following way:
> >>
> >> if (InlineFieldMaxFlatSize != 0
> >>
> >>        && (!(too_big_to_flatten | too_atomic_to_flatten |
> >> too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
> >>
> >>
> >> By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
> >> obvious that this is the way to completely disable field flattening.
> >>
> >> The second term would remain the more specific tests on the field's
> >> properties to decide to flatten or not when flattening is enabled.
> >>
> >>
> >> What do you think of this proposal?
> > Thanks for the proposal! But this looks more like a workaround for me.
> > Actually this can disable the field flattening with
> > "-XX:InlineFieldMaxFlatSize=0". But what if setting it to other small
> > value like "2" ? That is, the field can be flattened if its holder class size is
> larger than the specified max flat size, isn't it?
> >
> > Thanks,
> > Xiaohong
> >
> > -----Original Message-----
> > From: Frederic Parain <frederic.parain at oracle.com>
> > Sent: Thursday, July 6, 2023 8:57 PM
> > To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-
> dev at openjdk.org
> > Cc: nd <nd at arm.com>
> > Subject: Re: [External] : RE: Question on the inline type flattening
> > decision
> >
> > Hi Xiaohong,
> >
> >
> > I would recommend to modify the test driving the flattening decisions the
> following way:
> >
> > if (InlineFieldMaxFlatSize != 0
> >
> >   ???? && (!(too_big_to_flatten | too_atomic_to_flatten |
> > too_volatile_to_flatten) || fieldinfo.access_flags().is_final()) {
> >
> >
> > By adding the first term "InlineFieldMaxFlatSize != 0 ", it will be
> > obvious that this is the way to completely disable field flattening.
> >
> > The second term would remain the more specific tests on the field's
> > properties to decide to flatten or not when flattening is enabled.
> >
> >
> > What do you think of this proposal?
> >
> >
> > Best Regards,
> >
> >
> > Fred
> >
> >
> > On 7/2/23 9:23 PM, Xiaohong Gong wrote:
> >> Hi Frederic,
> >>
> >> Thanks for looking at this issue. Yes, I was planning to fix this. But I'm not
> sure how to handle the relationship with "final" fields.
> >>
> >> One is removing the followed "field" access check, which means the
> fields can be flattened no matter whether the field is "final" or not.
> >>
> >> Another is changing the followed "||" to "&&", so that only the "final"
> fields that match the preconditions can be flattened.
> >>
> >> So which one do you think is the defined behavior? The first one sounds
> reasonable to me. WDYT? Thanks a lot!
> >>
> >> BTW, I'v filed this issue to:
> >> https://bugs.openjdk.org/browse/JDK-8311219
> >>
> >> Best Regards,
> >> Xiaohong
> >>
> >> -----Original Message-----
> >> From: Frederic Parain <frederic.parain at oracle.com>
> >> Sent: Friday, June 30, 2023 9:28 PM
> >> To: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-
> dev at openjdk.org
> >> Cc: nd <nd at arm.com>
> >> Subject: Re: Question on the inline type flattening decision
> >>
> >> Hi Xiaohong,
> >>
> >>
> >> Thank you for reporting this. It looks like a bug to me, specifying
> >> -XX:InlineFieldMaxFlatSize=0 should disable all field flattening, including
> final fields.
> >>
> >> Do you want to fill a bug report or do you want me to take care of it?
> >>
> >>
> >> Best Regards,
> >>
> >>
> >> Fred
> >>
> >>
> >> On 6/30/23 3:04 AM, Xiaohong Gong wrote:
> >>> Hi,
> >>>
> >>> I guess this is the right place to ask this question related to the
> >>> flattening decision on inline type fields?
> >>>
> >>> I met an issue when I was running the tests under
> >>> ?hotspot/jtreg/compiler/valhalla/inlinetypes? with
> >>> ?-XX:InlineFieldMaxFlatSize=0?. The intention is doing some testing
> >>> by forcing the inline type fields not be flattened. ?And I debugged
> >>> some
> >>> C2 code in `inlinetypenode.cpp` like `InlineTypeNode::load()`. ?But
> >>> I found that the code path has no difference, which means this flag
> >>> cannot work and the field is flattened as without this flag.
> >>>
> >>> And then, I checked the relative code
> >>> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob
> >>>
> /lworld/src/hotspot/share/clas__;!!ACWV5N9M2RV99hQ!J7daZI_Hay5kWc
> kch
> >>>
> OY_VRTIwQvkJzF8AtUA0SEbDccLvtWEIcMKpkQY4IFKruqGd1K0_qzZXVvoPrH
> k3ys7z
> >>> -iq8Q$
> >>> sfile/fieldLayoutBuilder.cpp#L759 to find out the reason. It checks
> >>> the three necessary conditions (i.e.
> >>> ?the code size comparison with `InlineFieldMaxSize`?, ?atomic? or
> >>> ?volatile? fields) firstly, which is the right behavior I think. But
> >>> then the result is ?||? with the `final` access flag. Which means if
> >>> the field is `final`, it will be flattened anyway regardless of the
> >>> necessary three limitations.
> >>>
> >>> So is this the expected behavior? Does this mean the inline type
> >>> field can always be flattened if it is declared with `final`? But I
> >>> didn?t find any descriptions on the flattening decision related to
> >>> the `final` flag.
> >>>
> >>> Many thanks if any help on this!
> >>>
> >>> Best Regards,
> >>>
> >>> Xiaohong
> >>>

From xgong at openjdk.org  Tue Jul 11 10:07:45 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 11 Jul 2023 10:07:45 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v3]
In-Reply-To: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
Message-ID: <U6L1pQPnk4ZMQTTtVFlkpu4WoibwqZFeqtYRgfdUQIc=.2e2c45e8-0b8c-49a7-b063-caf5226a2d6d@github.com>

> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
> 
> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
> 
> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
> 
> [1] https://github.com/openjdk/valhalla/pull/866
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527

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

  Fix deoptimize issue for un-vectorized multifields

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/882/files
  - new: https://git.openjdk.org/valhalla/pull/882/files/df73fc82..bf95e906

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

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

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


From xgong at openjdk.org  Tue Jul 11 10:07:48 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 11 Jul 2023 10:07:48 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v2]
In-Reply-To: <rI-dtR9jKGr_r0Ow6n2DYJA7Pyt6tB3hICizyaYrG7w=.f6dbec73-7b84-4aac-ad23-4cd0dcab9af2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <rI-dtR9jKGr_r0Ow6n2DYJA7Pyt6tB3hICizyaYrG7w=.f6dbec73-7b84-4aac-ad23-4cd0dcab9af2@github.com>
Message-ID: <mz0VoxRARkaxRTI2fBuc5EiFWaWbhuTFHKjvmQDqN30=.7d47c700-d72f-46fb-8b58-c46d9301d18d@github.com>

On Fri, 7 Jul 2023 13:14:33 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
>> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
>> 
>> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
>> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
>> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
>> 
>> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
>> 
>> [1] https://github.com/openjdk/valhalla/pull/866
>> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
>> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
>> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set larval state for inline type objects

Hi, the latest change fixed the offset issue for multifields during deoptimization. With this fixing, all the tests (in Int256VectorTests) can pass on NEON.  And the crash I mentioned above can be fixed as well. Please help to take a look. Thanks a lot!

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1630535665


From jbhateja at openjdk.org  Tue Jul 11 11:02:28 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Jul 2023 11:02:28 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v3]
In-Reply-To: <U6L1pQPnk4ZMQTTtVFlkpu4WoibwqZFeqtYRgfdUQIc=.2e2c45e8-0b8c-49a7-b063-caf5226a2d6d@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <U6L1pQPnk4ZMQTTtVFlkpu4WoibwqZFeqtYRgfdUQIc=.2e2c45e8-0b8c-49a7-b063-caf5226a2d6d@github.com>
Message-ID: <7uwIivzC-qD3khAoN6fBsGqM6ojWDMvy-ofPawPNPhA=.1c592991-3845-4267-88a5-66916e6951d1@github.com>

On Tue, 11 Jul 2023 10:07:45 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
>> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
>> 
>> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
>> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
>> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
>> 
>> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
>> 
>> [1] https://github.com/openjdk/valhalla/pull/866
>> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
>> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
>> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix deoptimize issue for un-vectorized multifields

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

> 1615:       ScopeValue* scope_field = sv->field_at(svIndex);
> 1616:       StackValue* value = StackValue::create_stack_value(fr, reg_map, scope_field);
> 1617:       offset += j * type2aelembytes(type);

Nice catch!!, It went in along with merge patch. Will run this through jtreg tests to ensure status quo or better validation status.

Best Regards,
Jatin

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/882#discussion_r1259570939


From john.r.rose at oracle.com  Tue Jul 11 18:30:59 2023
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 11 Jul 2023 11:30:59 -0700
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
 <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>
Message-ID: <074612E1-5D17-4B3C-90BA-FD0A5B35D810@oracle.com>

On 10 Jul 2023, at 8:09, Frederic Parain wrote:

> Hi Xiaohong,
>
>
> Field flattening has two major side effects: atomicity and size.

Yes!  Well put.

Here?s some more fine print:

Atomicity of a value class will be something that its class
declaration can opt out of.  For a class that is non-atomic,
then (I think) both final and non-final instance fields of
its flattenable type (the null-excluding type, aka the ?val
type? or Q-type) can use the same policy.

For a value class which is atomic (and that is the default),
it will not be possible (until the day we have efficient HTM)
to flatten fields of that type, if they are mutable.

(There?s even more fine print for nullable reference types
from value classes, if the VM ever tries to inline nullable
types, but that?s way in the future and will not be user visible.)

>
> Final fields are not subject to atomicity issues because they are immutable after their initialization.

So the current policy treats non-final instance fields as flattenable,
which means it treats them as immutable.  This is 99.99% correct.

There is a technical debt here concerning what sorts of indeterminate
behavior are allowed in the 0.01% case, where (a) the constructor
for the object containing the flattenable field allows ?this? to
escape and another thread picks it up, and (b) the other thread
makes a racing read of the flattenable field at just the wrong
moment.  Here?s the debt:  Either we do not flatten the field
(at least when we know, statically, that this bad thing can happen)
or else we somehow delay the racing read until a safe moment (by
means of a mutex protocol of some sort), or (yet again) we somehow
detune the JVMS to allow atomic value classes to race, if their
containers are so rude as to allow concurrent reads through escaped
?this? pointers.  I think the most practical option is the first,
which means, sadly, the 99.99% correct policy for final fields
needs reconsideration.  But maybe I?ve missed some fortunate aspect
in the current policy, that allows it to avoid the 0.01% error.

(It?s corner cases like this that make JVM design exceedingly
difficult.  Most language specs. and runtimes don?t bother
to track all the details to this level, but Java does.)

>
> Both final and non-final fields have an impact on the object size, and potentially on cache behavior.

This is true for instance fields, because there are an indefinite
number of instances of them.  It is not really true for static fields,
and that?s a distinction that can have an effect on flattening policy.
The existing policy never flattens static fields; all the code quoted
in this thread is for non-static fields.

<digression topic=?flattening static fields?>

There would be zero benefit, and some harm, to flattening
static final fields.  The harm is to startup time, when that is
dominated by interpreter performance. The JIT doesn?t care either
way; it?s a compile-time constant.

Non-final statics are also very different from non-final instance
fields, so it is reasonable to use a different policy for them
as well.  Since statics are inherently shared across threads, maybe
the atomicity issue is more strongly felt; maybe.  Or maybe that?s
why we have ?volatile?, to mark fields where we really care about
that.  The current policy makes all static reads and writes fully
race-free, at the cost of heap-buffering each stored value.

In any case, it is good that the flattening policy code in the
Valhalla VM has separate branches for static and non-static fields.

But, I have sometimes wondered if it would be a good idea to have
the VM buffer flattened static non-finals secretly in length-one
arrays, and tell the getstatic and putstatic opcodes to go look
there for their payloads.  It would be a little wasteful, but
not much.  The array references would be rooted immutably in
the class mirror object, just as if the fields were plain
references.  Unlike other heap buffers, a length-one array
creates a mutable variable for a value.  But it would make
such non-final statics be much more racy.  Maybe its better
to tilt to the side of non-raciness, which is what the current
policy does.

None of these musing should be taken as a call to consider
flattening statics directly in the normal container for
static fields, which is the Class mirror object for the
class declaring the statics.  This is a wild and tricky
tactic, which would probably become unmanageable (for
several reasons) if we tried to wedge flattened fields
into the poor Class mirror.  Class mirrors are weird
enough already.

</digression>

> Bigger objects are less likely to fit in data caches, and bigger distances between fields would require
> more cache lines and more cache misses to read them. This issue is not significant when accessing fields
> of a single object, but it can become dominant when accessing fields of objects stored in a flat array.

It?s an interesting tradeoff:  Indirections almost certainly depart
to new cache lines, while if you pile up enough size in flattened
variables, then you start departing the cache line just to get to
the other side of a single object.  (HW prefetchers often favor
contiguous block accesses, which make it favorable longer.)

Also, and semi-independently, memory traffic correlates with cache
line traffic.  So if your workload is very flat and cache-line-local,
but it loads a bunch of useless bits in every flat object, those useless
bits will have a similar effect to (prefetchable) cache line departures.
This can happen even if all the objects fit in one cache line, if the
alternative was to have two objects fit in each cache line, in a different
organization of the data.  The enabling condition there is that an object
might have ?hot? and ?cold? fields, in which case flattening the ?cold?
fields will incur a tax (in data case traffic) on access to the ?hot?
fields.  Because loading a cold field you don?t need into a full data
cache will displace some other object?s hot field which you do need.

The way I like to think about this latter effect is to envision, on
the one hand, everything flattened as much as possible, with no pointers
or headers loaded into the cache, but maybe with some ?garbage? bits
mixed into the flat data.  (?Garbage? bits are, for example, bits which
are zero 99% of the time.)  And on the other hand, everything indirected
through pointers, which means every non-garbage data reference has to
thread through a pointer and jump past a header (loading those items
into the cache, AND making a non-prefetchable load), but also enjoying
the freedom from loading flattened garbage data.  You can flatten too
much, if what?s flattened into your containers has low entropy, and
eventually it can cause enough data cache traffic that you wish for
your pointers back, so you can refrain from loading cold garbage
at the other end of some of those pointers.

>
> So, in theory, the flattening test should be:
>
> ? if (!((!fieldinfo.access_flags().is_final() && (too_atomic_to_flatten || too_volatile_to_flatten))
> ??????? || too_big_to_flatten)) {
>
> Atomicity constraints are considered only for non-final fields, and size constraints are considered
> for all fields.
>
>
> That being said, we have always been more aggressive in the flattening of final fields because it was
> beneficial to C2.

Yes.  There?s a debt to pay here, though.  It might be that we end
up rethinking this policy, regarding non-static final fields, for
the two cases of declared-atomic (the default) and declared-non-atomic
(the racy power-user option).

? John


From jbhateja at openjdk.org  Tue Jul 11 18:34:31 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Jul 2023 18:34:31 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v3]
In-Reply-To: <7uwIivzC-qD3khAoN6fBsGqM6ojWDMvy-ofPawPNPhA=.1c592991-3845-4267-88a5-66916e6951d1@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <U6L1pQPnk4ZMQTTtVFlkpu4WoibwqZFeqtYRgfdUQIc=.2e2c45e8-0b8c-49a7-b063-caf5226a2d6d@github.com>
 <7uwIivzC-qD3khAoN6fBsGqM6ojWDMvy-ofPawPNPhA=.1c592991-3845-4267-88a5-66916e6951d1@github.com>
Message-ID: <Ie7Jxov0d4r4jdjvRl_pxX1vchAAdtOTuX3Ed2R0GJI=.46a3bed2-5e8b-422a-aae7-fbd98629e922@github.com>

On Tue, 11 Jul 2023 10:59:16 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 deoptimize issue for un-vectorized multifields
>
> src/hotspot/share/runtime/deoptimization.cpp line 1617:
> 
>> 1615:       ScopeValue* scope_field = sv->field_at(svIndex);
>> 1616:       StackValue* value = StackValue::create_stack_value(fr, reg_map, scope_field);
>> 1617:       offset += j * type2aelembytes(type);
> 
> Nice catch!!, It went in along with merge patch. Will run this through jtreg tests to ensure status quo or better validation status.
> 
> Best Regards,
> Jatin

Please also relax the condition on line # 1605 to just check for Location::vector

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/882#discussion_r1260126828


From xgong at openjdk.org  Wed Jul 12 01:38:19 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 12 Jul 2023 01:38:19 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v3]
In-Reply-To: <Ie7Jxov0d4r4jdjvRl_pxX1vchAAdtOTuX3Ed2R0GJI=.46a3bed2-5e8b-422a-aae7-fbd98629e922@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <U6L1pQPnk4ZMQTTtVFlkpu4WoibwqZFeqtYRgfdUQIc=.2e2c45e8-0b8c-49a7-b063-caf5226a2d6d@github.com>
 <7uwIivzC-qD3khAoN6fBsGqM6ojWDMvy-ofPawPNPhA=.1c592991-3845-4267-88a5-66916e6951d1@github.com>
 <Ie7Jxov0d4r4jdjvRl_pxX1vchAAdtOTuX3Ed2R0GJI=.46a3bed2-5e8b-422a-aae7-fbd98629e922@github.com>
Message-ID: <T6aIBBulNDr4B_tPiSxxVEB-B3ei1gJMqDouQxbvuDQ=.7bf895ce-979a-4fd9-9821-965093281592@github.com>

On Tue, 11 Jul 2023 18:31:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/runtime/deoptimization.cpp line 1617:
>> 
>>> 1615:       ScopeValue* scope_field = sv->field_at(svIndex);
>>> 1616:       StackValue* value = StackValue::create_stack_value(fr, reg_map, scope_field);
>>> 1617:       offset += j * type2aelembytes(type);
>> 
>> Nice catch!!, It went in along with merge patch. Will run this through jtreg tests to ensure status quo or better validation status.
>> 
>> Best Regards,
>> Jatin
>
> Please also relax the condition on line # 1605 to just check for Location::vector

Yes, relaxing the condition is fine. And we'd better to add the assertion that `secondary_fields_count > 1` ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/882#discussion_r1260458092


From xgong at openjdk.org  Wed Jul 12 02:53:20 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 12 Jul 2023 02:53:20 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v3]
In-Reply-To: <T6aIBBulNDr4B_tPiSxxVEB-B3ei1gJMqDouQxbvuDQ=.7bf895ce-979a-4fd9-9821-965093281592@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <U6L1pQPnk4ZMQTTtVFlkpu4WoibwqZFeqtYRgfdUQIc=.2e2c45e8-0b8c-49a7-b063-caf5226a2d6d@github.com>
 <7uwIivzC-qD3khAoN6fBsGqM6ojWDMvy-ofPawPNPhA=.1c592991-3845-4267-88a5-66916e6951d1@github.com>
 <Ie7Jxov0d4r4jdjvRl_pxX1vchAAdtOTuX3Ed2R0GJI=.46a3bed2-5e8b-422a-aae7-fbd98629e922@github.com>
 <T6aIBBulNDr4B_tPiSxxVEB-B3ei1gJMqDouQxbvuDQ=.7bf895ce-979a-4fd9-9821-965093281592@github.com>
Message-ID: <R5dIEoTgHgd4Eo4wF8iBDrTAHUrhMSewYa6zUIb4Vxw=.7bec7a0b-fff5-4974-b925-de8cd91af326@github.com>

On Wed, 12 Jul 2023 01:35:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Please also relax the condition on line # 1605 to just check for Location::vector
>
> Yes, relaxing the condition is fine. And we'd better to add the assertion that `secondary_fields_count > 1` ?

Or, is the vector supported for 1 lanecount (e.g. 64-bit shape for `long/double` type) on x86 systems?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/882#discussion_r1260503207


From xgong at openjdk.org  Wed Jul 12 04:06:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 12 Jul 2023 04:06:27 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v4]
In-Reply-To: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
Message-ID: <P3yUN9TzWpAsCgCzpZyHqNdN1JIvxa7PrnK9U2h335M=.9fe4b01d-f9e9-4e19-8d17-8ec408f5d6d1@github.com>

> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
> 
> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
> 
> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
> 
> [1] https://github.com/openjdk/valhalla/pull/866
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527

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

  Relax the condition for vectorized multi-fields reassigning

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/882/files
  - new: https://git.openjdk.org/valhalla/pull/882/files/bf95e906..ec567dd3

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

  Stats: 14 lines in 1 file changed: 3 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/882.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/882/head:pull/882

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


From Xiaohong.Gong at arm.com  Wed Jul 12 07:22:23 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Wed, 12 Jul 2023 07:22:23 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <074612E1-5D17-4B3C-90BA-FD0A5B35D810@oracle.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
 <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>
 <074612E1-5D17-4B3C-90BA-FD0A5B35D810@oracle.com>
Message-ID: <DB9PR08MB7747C489925A4FF82957B5D0F536A@DB9PR08MB7747.eurprd08.prod.outlook.com>

Hi John, Fred,

Thanks for the so detailed explanation for the flattening policy, which really makes sense!

As a summary, maybe we could change the condition like:

```
if (!too_big_to_flatten &&
     (!(too_atomic_to_flatten | too_volatile_to_flatten) || fieldinfo.access_flags().is_final())) {
...
}
```
That is:
1. For non-atomic klass instances (i.e. Q-type), either the final or non-final fields can be flattened if the size is matched.
2. For atomic klass instance (i.e. the default value klass) or volatile fields, only the final fields are flattened if the size is matched.

The main change is promoting the flat size check at the first stage. Other checks are applied under this condition is matched. 
Is this right?

Please correct me if anything is not right! Thanks!

Best Regards,
Xiaohong

-----Original Message-----
From: John Rose <john.r.rose at oracle.com> 
Sent: Wednesday, July 12, 2023 2:31 AM
To: Frederic Parain <frederic.parain at oracle.com>
Cc: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org; nd <nd at arm.com>
Subject: Re: [External] : RE: Question on the inline type flattening decision

On 10 Jul 2023, at 8:09, Frederic Parain wrote:

> Hi Xiaohong,
>
>
> Field flattening has two major side effects: atomicity and size.

Yes!  Well put.

Here?s some more fine print:

Atomicity of a value class will be something that its class declaration can opt out of.  For a class that is non-atomic, then (I think) both final and non-final instance fields of its flattenable type (the null-excluding type, aka the ?val type? or Q-type) can use the same policy.

For a value class which is atomic (and that is the default), it will not be possible (until the day we have efficient HTM) to flatten fields of that type, if they are mutable.

(There?s even more fine print for nullable reference types from value classes, if the VM ever tries to inline nullable types, but that?s way in the future and will not be user visible.)

>
> Final fields are not subject to atomicity issues because they are immutable after their initialization.

So the current policy treats non-final instance fields as flattenable, which means it treats them as immutable.  This is 99.99% correct.

There is a technical debt here concerning what sorts of indeterminate behavior are allowed in the 0.01% case, where (a) the constructor for the object containing the flattenable field allows ?this? to escape and another thread picks it up, and (b) the other thread makes a racing read of the flattenable field at just the wrong moment.  Here?s the debt:  Either we do not flatten the field (at least when we know, statically, that this bad thing can happen) or else we somehow delay the racing read until a safe moment (by means of a mutex protocol of some sort), or (yet again) we somehow detune the JVMS to allow atomic value classes to race, if their containers are so rude as to allow concurrent reads through escaped ?this? pointers.  I think the most practical option is the first, which means, sadly, the 99.99% correct policy for final fields needs reconsideration.  But maybe I?ve missed some fortunate aspect in the current policy, that allows it to avoid the 0.01% error.

(It?s corner cases like this that make JVM design exceedingly difficult.  Most language specs. and runtimes don?t bother to track all the details to this level, but Java does.)

>
> Both final and non-final fields have an impact on the object size, and potentially on cache behavior.

This is true for instance fields, because there are an indefinite number of instances of them.  It is not really true for static fields, and that?s a distinction that can have an effect on flattening policy.
The existing policy never flattens static fields; all the code quoted in this thread is for non-static fields.

<digression topic=?flattening static fields?>

There would be zero benefit, and some harm, to flattening static final fields.  The harm is to startup time, when that is dominated by interpreter performance. The JIT doesn?t care either way; it?s a compile-time constant.

Non-final statics are also very different from non-final instance fields, so it is reasonable to use a different policy for them as well.  Since statics are inherently shared across threads, maybe the atomicity issue is more strongly felt; maybe.  Or maybe that?s why we have ?volatile?, to mark fields where we really care about that.  The current policy makes all static reads and writes fully race-free, at the cost of heap-buffering each stored value.

In any case, it is good that the flattening policy code in the Valhalla VM has separate branches for static and non-static fields.

But, I have sometimes wondered if it would be a good idea to have the VM buffer flattened static non-finals secretly in length-one arrays, and tell the getstatic and putstatic opcodes to go look there for their payloads.  It would be a little wasteful, but not much.  The array references would be rooted immutably in the class mirror object, just as if the fields were plain references.  Unlike other heap buffers, a length-one array creates a mutable variable for a value.  But it would make such non-final statics be much more racy.  Maybe its better to tilt to the side of non-raciness, which is what the current policy does.

None of these musing should be taken as a call to consider flattening statics directly in the normal container for static fields, which is the Class mirror object for the class declaring the statics.  This is a wild and tricky tactic, which would probably become unmanageable (for several reasons) if we tried to wedge flattened fields into the poor Class mirror.  Class mirrors are weird enough already.

</digression>

> Bigger objects are less likely to fit in data caches, and bigger 
> distances between fields would require more cache lines and more cache 
> misses to read them. This issue is not significant when accessing fields of a single object, but it can become dominant when accessing fields of objects stored in a flat array.

It?s an interesting tradeoff:  Indirections almost certainly depart to new cache lines, while if you pile up enough size in flattened variables, then you start departing the cache line just to get to the other side of a single object.  (HW prefetchers often favor contiguous block accesses, which make it favorable longer.)

Also, and semi-independently, memory traffic correlates with cache line traffic.  So if your workload is very flat and cache-line-local, but it loads a bunch of useless bits in every flat object, those useless bits will have a similar effect to (prefetchable) cache line departures.
This can happen even if all the objects fit in one cache line, if the alternative was to have two objects fit in each cache line, in a different organization of the data.  The enabling condition there is that an object might have ?hot? and ?cold? fields, in which case flattening the ?cold?
fields will incur a tax (in data case traffic) on access to the ?hot?
fields.  Because loading a cold field you don?t need into a full data cache will displace some other object?s hot field which you do need.

The way I like to think about this latter effect is to envision, on the one hand, everything flattened as much as possible, with no pointers or headers loaded into the cache, but maybe with some ?garbage? bits mixed into the flat data.  (?Garbage? bits are, for example, bits which are zero 99% of the time.)  And on the other hand, everything indirected through pointers, which means every non-garbage data reference has to thread through a pointer and jump past a header (loading those items into the cache, AND making a non-prefetchable load), but also enjoying the freedom from loading flattened garbage data.  You can flatten too much, if what?s flattened into your containers has low entropy, and eventually it can cause enough data cache traffic that you wish for your pointers back, so you can refrain from loading cold garbage at the other end of some of those pointers.

>
> So, in theory, the flattening test should be:
>
> ? if (!((!fieldinfo.access_flags().is_final() && 
> (too_atomic_to_flatten || too_volatile_to_flatten))
> ??????? || too_big_to_flatten)) {
>
> Atomicity constraints are considered only for non-final fields, and 
> size constraints are considered for all fields.
>
>
> That being said, we have always been more aggressive in the flattening 
> of final fields because it was beneficial to C2.

Yes.  There?s a debt to pay here, though.  It might be that we end up rethinking this policy, regarding non-static final fields, for the two cases of declared-atomic (the default) and declared-non-atomic (the racy power-user option).

? John

From jbhateja at openjdk.org  Wed Jul 12 08:17:21 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 12 Jul 2023 08:17:21 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v4]
In-Reply-To: <R5dIEoTgHgd4Eo4wF8iBDrTAHUrhMSewYa6zUIb4Vxw=.7bec7a0b-fff5-4974-b925-de8cd91af326@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <U6L1pQPnk4ZMQTTtVFlkpu4WoibwqZFeqtYRgfdUQIc=.2e2c45e8-0b8c-49a7-b063-caf5226a2d6d@github.com>
 <7uwIivzC-qD3khAoN6fBsGqM6ojWDMvy-ofPawPNPhA=.1c592991-3845-4267-88a5-66916e6951d1@github.com>
 <Ie7Jxov0d4r4jdjvRl_pxX1vchAAdtOTuX3Ed2R0GJI=.46a3bed2-5e8b-422a-aae7-fbd98629e922@github.com>
 <T6aIBBulNDr4B_tPiSxxVEB-B3ei1gJMqDouQxbvuDQ=.7bf895ce-979a-4fd9-9821-965093281592@github.com>
 <R5dIEoTgHgd4Eo4wF8iBDrTAHUrhMSewYa6zUIb4Vxw=.7bec7a0b-fff5-4974-b925-de8cd91af326@github.com>
Message-ID: <_naRZ_a9biBrlEGvKhIROYoeUh1PqXcNPygYB1r_TLM=.50216131-bbdb-4b24-b351-8fe5dba8b709@github.com>

On Wed, 12 Jul 2023 02:50:37 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Or, is the vector supported for 1 lanecount (e.g. 64-bit shape for `long/double` type) on x86 systems?

Not yes, most of the vector intrinsic also fail for single lane vector operations.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/882#discussion_r1260782415


From xgong at openjdk.org  Wed Jul 12 08:25:23 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 12 Jul 2023 08:25:23 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v4]
In-Reply-To: <_naRZ_a9biBrlEGvKhIROYoeUh1PqXcNPygYB1r_TLM=.50216131-bbdb-4b24-b351-8fe5dba8b709@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <U6L1pQPnk4ZMQTTtVFlkpu4WoibwqZFeqtYRgfdUQIc=.2e2c45e8-0b8c-49a7-b063-caf5226a2d6d@github.com>
 <7uwIivzC-qD3khAoN6fBsGqM6ojWDMvy-ofPawPNPhA=.1c592991-3845-4267-88a5-66916e6951d1@github.com>
 <Ie7Jxov0d4r4jdjvRl_pxX1vchAAdtOTuX3Ed2R0GJI=.46a3bed2-5e8b-422a-aae7-fbd98629e922@github.com>
 <T6aIBBulNDr4B_tPiSxxVEB-B3ei1gJMqDouQxbvuDQ=.7bf895ce-979a-4fd9-9821-965093281592@github.com>
 <R5dIEoTgHgd4Eo4wF8iBDrTAHUrhMSewYa6zUIb4Vxw=.7bec7a0b-fff5-4974-b925-de8cd91af326@github.com>
 <_naRZ_a9biBrlEGvKhIROYoeUh1PqXcNPygYB1r_TLM=.50216131-bbdb-4b24-b351-8fe5dba8b709@github.com>
Message-ID: <SAQXgfwPUk21TP6OtbI-68OV8Gl9aUlkO2Zsm7HqsLs=.5304a6b9-526e-4362-a574-a5276fc0c216@github.com>

On Wed, 12 Jul 2023 08:14:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Or, is the vector supported for 1 lanecount (e.g. 64-bit shape for `long/double` type) on x86 systems?
>
>> Or, is the vector supported for 1 lanecount (e.g. 64-bit shape for `long/double` type) on x86 systems?
> 
> Not yes, most of the vector intrinsic also fail for single lane vector operations.

Yeah, I also met the bad ad file crashes due to single lane for double type on x86 system. And I tried to add the assertion that `secondary_fields_count > 1`, but it crashes when running `Double64VectorTests` on x86. Anyway, I have removed this condition and assertion in the deoptimization.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/882#discussion_r1260792352


From jbhateja at openjdk.org  Wed Jul 12 08:42:28 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 12 Jul 2023 08:42:28 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v4]
In-Reply-To: <P3yUN9TzWpAsCgCzpZyHqNdN1JIvxa7PrnK9U2h335M=.9fe4b01d-f9e9-4e19-8d17-8ec408f5d6d1@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <P3yUN9TzWpAsCgCzpZyHqNdN1JIvxa7PrnK9U2h335M=.9fe4b01d-f9e9-4e19-8d17-8ec408f5d6d1@github.com>
Message-ID: <LJu_9CBCOPx9frH000W3TDx1OgaiayVhJfSM2l31zYc=.6ee944ea-de5c-418f-b0bd-ccb3be379505@github.com>

On Wed, 12 Jul 2023 04:06:27 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
>> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
>> 
>> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
>> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
>> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
>> 
>> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
>> 
>> [1] https://github.com/openjdk/valhalla/pull/866
>> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
>> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
>> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Relax the condition for vectorized multi-fields reassigning

De-optimization cleanup looks good to me. There are still failures in LoadStore and Conversion tests which can be addressed in subsequent patches.

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

Marked as reviewed by jbhateja (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/882#pullrequestreview-1525816464


From xgong at openjdk.org  Wed Jul 12 08:42:28 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 12 Jul 2023 08:42:28 GMT
Subject: [lworld+vector] RFR: 8311610: [lworld+vector] Clean-up of vector
 allocation in class VectorSupport [v4]
In-Reply-To: <LJu_9CBCOPx9frH000W3TDx1OgaiayVhJfSM2l31zYc=.6ee944ea-de5c-418f-b0bd-ccb3be379505@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
 <P3yUN9TzWpAsCgCzpZyHqNdN1JIvxa7PrnK9U2h335M=.9fe4b01d-f9e9-4e19-8d17-8ec408f5d6d1@github.com>
 <LJu_9CBCOPx9frH000W3TDx1OgaiayVhJfSM2l31zYc=.6ee944ea-de5c-418f-b0bd-ccb3be379505@github.com>
Message-ID: <PgzjLJPeo4_sikeWYHoHVO7bgYZkTIedgIqucv9qFtA=.c1b87cb4-9ba3-473a-98f2-738d024931ea@github.com>

On Wed, 12 Jul 2023 08:37:26 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> De-optimization cleanup looks good to me. There are still failures in LoadStore and Conversion tests which can be addressed in subsequent patches.

Yes, we have to spend time looking at those issues next. Thanks for the review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/882#issuecomment-1632090953


From mcimadamore at openjdk.org  Wed Jul 12 09:30:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Jul 2023 09:30:21 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v4]
In-Reply-To: <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
Message-ID: <f16T0ODe9FR1En7J7grLVM0myT6_g_jKzy1QaDpMbYM=.cf67a643-f382-4121-843e-15d9df141240@github.com>

On Wed, 5 Jul 2023 21:20:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding more regression tests

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 786:

> 784:     }
> 785: 
> 786:     public boolean sameNullabilityAs(Type t) {

Should these methods be here or in Types, since they are general relation on types?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1260889493


From mcimadamore at openjdk.org  Wed Jul 12 09:52:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Jul 2023 09:52:21 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v4]
In-Reply-To: <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
Message-ID: <MK1OR1KTNzgnZ1AZZKxqohNL1t-UZ2KwSn0-MChiAzE=.c25768f8-2778-4b2c-9a25-ba522e2c0a92@github.com>

On Wed, 5 Jul 2023 21:20:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding more regression tests

Looks good - I left some suggestions for improvements and consolidation.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1284:

> 1282:             NullabilityComparator reset(BiFunction<Type, Type, Boolean> differentNullability) {
> 1283:                 this.differentNullability = differentNullability;
> 1284:                 if (this.warner == null || this.warner == noWarnings) {

I'm not sure I follow what's happening here. We have a warner stack in Types already. But this class seems to somehow override whatever warner is in the stack (if a client called setWarner on the nullability comparator). Shouldn't we try to reuse the warnStack as a way to set warners, and then tweak nullability comparator to use whatever warner is on the stack? E.g. I'm suspicious about the set/clearWarner methods, as they seem to duplicate functionality we already have in other forms.

test/langtools/tools/javac/bang/BangTypesCompilationTests.java line 150:

> 148:                                         Supplier<? extends T> factory = nullFactory();
> 149:                                     }
> 150:                                     Supplier<? extends T!> nullFactory() { return () -> null; }

Nice!

test/langtools/tools/javac/bang/BangTypesCompilationTests.java line 359:

> 357:                                 Result.Warning,
> 358:                                 "compiler.warn.unchecked.nullness.conversion",
> 359:                                 2),  // this needs to be reviewed, the warning is printed twice, should be once only

Does this have to do with the fact that the subtyping is executed twice (e.g. once in overload, once in the "check" phase) ?

test/langtools/tools/javac/bang/BangTypesCompilationTests.java line 489:

> 487:                                 class Box<T> {}
> 488:                                 class Test {
> 489:                                     void m(Box<Shape!> lp) {

This test reminds me of something: capture conversion should probably be tweaked to take nullability into account. Consider this:


class Foo<X extends Bar!> { 
    X x() { ... }
}

Foo<? extends Object> foo = ...
Object! restricted = foo.x(); // this should be ok  (e.g. no warnings)


I'm basing this on the fact that capture conversion already tries to establish some common facts between declaration-site and use-site. This test is similar to when use-site says `<? extends Object>` but the decl site says `<X extends List>`, in which case `List` is used as the bound for the captured variable. In this case, it seems like the null restriction that is present at the declaration site should be carried over to the captured variable as well.  Of course this is all outside the context of this review, but I thought I'd leave a comment to note the issue.

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

PR Review: https://git.openjdk.org/valhalla/pull/880#pullrequestreview-1525928001
PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1260908537
PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1260910636
PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1260912605
PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1260920045


From mcimadamore at openjdk.org  Wed Jul 12 09:52:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 12 Jul 2023 09:52:22 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v4]
In-Reply-To: <f16T0ODe9FR1En7J7grLVM0myT6_g_jKzy1QaDpMbYM=.cf67a643-f382-4121-843e-15d9df141240@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
 <f16T0ODe9FR1En7J7grLVM0myT6_g_jKzy1QaDpMbYM=.cf67a643-f382-4121-843e-15d9df141240@github.com>
Message-ID: <KigVnN-cqzu073YjnF68Fc-PsLPIGUTkF4Zp64DwEKk=.42464d8e-a533-495d-9fb1-d90ff2ae44d4@github.com>

On Wed, 12 Jul 2023 09:27:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding more regression tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 786:
> 
>> 784:     }
>> 785: 
>> 786:     public boolean sameNullabilityAs(Type t) {
> 
> Should these methods be here or in Types, since they are general relation on types?

Also, looking at all these tests I wonder it we shouldn't maybe expose the NullMarker enum directly with a single accessor, and then use that (e.g. in a switch) to do the various tests. But this is just minor code style comments, no need to block this PR (mostly thinking aloud).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1260892322


From xgong at openjdk.org  Wed Jul 12 09:53:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 12 Jul 2023 09:53:27 GMT
Subject: [lworld+vector] Integrated: 8311610: [lworld+vector] Clean-up of
 vector allocation in class VectorSupport
In-Reply-To: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
References: <4rmu0rjrCLsx_HVhysUmnavf3KWR9W442NtuQLl5C5w=.e6ee5dc3-5787-4fd3-807e-6ee4e79d17c2@github.com>
Message-ID: <Dmi3_-e3e5vthraii5Y8Os2CCKi-vIHkZPt5gAqrEkE=.c916642b-c398-4555-98db-24eabe4c8ce2@github.com>

On Fri, 7 Jul 2023 06:47:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> PR [1] has added the vector supports for field re-assigning after object re-allocation in `deoptimization.cpp`. The similar vector
> and vector payload re-allocation code in `vectorSupport.cpp` can be removed now.
> 
> Besides, there is an issue in current vector payload allocation code in `vectorSupport.cpp`, that the multi-fields are forgotten
> to be assigned after the payload object is allocated (see [2]). This method is called separately during deoptimization (see [3]).
> This makes several Vector API jtreg test results incorrect. And either assigning the fields by calling `Deoptimization::reassign_fields_by_klass()` after it or directly going to the normal re-allocation path in `deoptimization.cpp` can fix the issue. I prefer the latter one. Hence the similar code in `vectorSupport.cpp` is needless and can be removed.
> 
> This patch also fixes a crash when printing out the JVM state, which is caused by the additional multi-fields passed to a safepoint. Normally, the fields number passed to a safepoint is the same with the klass's non-static fields number. But it's different for multi-fields. Only the `multifield_base` is added to the klass's non-static field list. Hence if all the un-vectorized multi-fields are passed to a safepoint, the fields number is larger than the klass's non-static fields number. And the array access at [4] throws exception due to out of range index.
> 
> [1] https://github.com/openjdk/valhalla/pull/866
> [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/prims/vectorSupport.cpp#L281
> [3] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1282
> [4] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/callnode.cpp#L527

This pull request has now been integrated.

Changeset: 656a4bac
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/656a4bacf6dd22fa24ec13238bcc8aee710cdd44
Stats:     364 lines in 5 files changed: 35 ins; 303 del; 26 mod

8311610: [lworld+vector] Clean-up of vector allocation in class VectorSupport

Reviewed-by: jbhateja

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

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


From vromero at openjdk.org  Wed Jul 12 19:10:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 12 Jul 2023 19:10:21 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v4]
In-Reply-To: <MK1OR1KTNzgnZ1AZZKxqohNL1t-UZ2KwSn0-MChiAzE=.c25768f8-2778-4b2c-9a25-ba522e2c0a92@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
 <MK1OR1KTNzgnZ1AZZKxqohNL1t-UZ2KwSn0-MChiAzE=.c25768f8-2778-4b2c-9a25-ba522e2c0a92@github.com>
Message-ID: <FSPlZ9iOKQgFdxZkUc2GMLNZoFY3Vok6E9JNlmy5ncs=.29d453a7-1ce9-4de8-b9ba-b2840ed79634@github.com>

On Wed, 12 Jul 2023 09:40:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding more regression tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1284:
> 
>> 1282:             NullabilityComparator reset(BiFunction<Type, Type, Boolean> differentNullability) {
>> 1283:                 this.differentNullability = differentNullability;
>> 1284:                 if (this.warner == null || this.warner == noWarnings) {
> 
> I'm not sure I follow what's happening here. We have a warner stack in Types already. But this class seems to somehow override whatever warner is in the stack (if a client called setWarner on the nullability comparator). Shouldn't we try to reuse the warnStack as a way to set warners, and then tweak nullability comparator to use whatever warner is on the stack? E.g. I'm suspicious about the set/clearWarner methods, as they seem to duplicate functionality we already have in other forms.

I did this because `Check::checkExtends` invokes `Types::isSubtype`, in a previous iteration I think you suggested not to add a Warner argument to `Types::isSubtype`, so this is an effort to circumvent that. I will give it another try

> test/langtools/tools/javac/bang/BangTypesCompilationTests.java line 359:
> 
>> 357:                                 Result.Warning,
>> 358:                                 "compiler.warn.unchecked.nullness.conversion",
>> 359:                                 2),  // this needs to be reviewed, the warning is printed twice, should be once only
> 
> Does this have to do with the fact that the subtyping is executed twice (e.g. once in overload, once in the "check" phase) ?

yep I think so

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1261614450
PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1261615802


From vromero at openjdk.org  Wed Jul 12 19:17:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 12 Jul 2023 19:17:17 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v4]
In-Reply-To: <MK1OR1KTNzgnZ1AZZKxqohNL1t-UZ2KwSn0-MChiAzE=.c25768f8-2778-4b2c-9a25-ba522e2c0a92@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
 <MK1OR1KTNzgnZ1AZZKxqohNL1t-UZ2KwSn0-MChiAzE=.c25768f8-2778-4b2c-9a25-ba522e2c0a92@github.com>
Message-ID: <_ggZIE6rBp9sooovHoB-oM1NaFF5crOkayMw0kaYg0s=.b44d53c4-b726-4616-ae8d-49576715fa9e@github.com>

On Wed, 12 Jul 2023 09:49:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding more regression tests
>
> test/langtools/tools/javac/bang/BangTypesCompilationTests.java line 489:
> 
>> 487:                                 class Box<T> {}
>> 488:                                 class Test {
>> 489:                                     void m(Box<Shape!> lp) {
> 
> This test reminds me of something: capture conversion should probably be tweaked to take nullability into account. Consider this:
> 
> 
> class Foo<X extends Bar!> { 
>     X x() { ... }
> }
> 
> Foo<? extends Object> foo = ...
> Object! restricted = foo.x(); // this should be ok  (e.g. no warnings)
> 
> 
> I'm basing this on the fact that capture conversion already tries to establish some common facts between declaration-site and use-site. This test is similar to when use-site says `<? extends Object>` but the decl site says `<X extends List>`, in which case `List` is used as the bound for the captured variable. In this case, it seems like the null restriction that is present at the declaration site should be carried over to the captured variable as well.  Of course this is all outside the context of this review, but I thought I'd leave a comment to note the issue.

yes, interesting

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1261621626


From vromero at openjdk.org  Wed Jul 12 21:40:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 12 Jul 2023 21:40:17 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v4]
In-Reply-To: <MK1OR1KTNzgnZ1AZZKxqohNL1t-UZ2KwSn0-MChiAzE=.c25768f8-2778-4b2c-9a25-ba522e2c0a92@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
 <MK1OR1KTNzgnZ1AZZKxqohNL1t-UZ2KwSn0-MChiAzE=.c25768f8-2778-4b2c-9a25-ba522e2c0a92@github.com>
Message-ID: <H35X333rcqFXsJjzNkYTT5pZycGXyLj9-AwLTHTok2U=.d18c2a77-2dc1-49f2-97a6-abd3cb994c04@github.com>

On Wed, 12 Jul 2023 09:43:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding more regression tests
>
> test/langtools/tools/javac/bang/BangTypesCompilationTests.java line 359:
> 
>> 357:                                 Result.Warning,
>> 358:                                 "compiler.warn.unchecked.nullness.conversion",
>> 359:                                 2),  // this needs to be reviewed, the warning is printed twice, should be once only
> 
> Does this have to do with the fact that the subtyping is executed twice (e.g. once in overload, once in the "check" phase) ?

for some cases like:

import java.util.function.*;
class Test {
    void plot(Function<String!, String> f) {}
    void m(Function<String, String> gradient) {
        plot(gradient);
    }
}

it was warning twice, there is a double visit by NullabilityComparator to the type. In method IsSubtype::visitClassType, there was a warning being issued when the arguments were compared and then at the end of the method this invocation:


    if (result) {
        nullabilityComparator.reset((t1, t2) -> hasNarrowerNullability(t1, t2)).visit(s, t);
    }

was provoking the same warning being issued in the same position. We need this invocation to compare the types but it also compares the arguments thus the double warning. I'm using now a field to mark if we have already warned or not.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1261749138


From mchung at openjdk.org  Wed Jul 12 21:54:37 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 12 Jul 2023 21:54:37 GMT
Subject: [lworld] RFR: 8310651: [lworld] ValueConstantDesc fails after merge
 with jdk-21+25
Message-ID: <CxeuFeeK9hJHB1o3rta4kFbP9j8RXl1_eBXLTXgwNsI=.321c9222-beac-4f01-80fe-554e9caa4a9d@github.com>

The test fails because of an incorrect merge with [JDK-8304928](https://bugs.openjdk.org/browse/JDK-8304928).   JDK-8304928 special cases the array type and the merge moves the logic to determine Q-descriptor just for the array type case but misses the normal class case.

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

Commit messages:
 - 8310651: [lworld] ValueConstantDesc fails after merge with jdk-21+25

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

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


From vromero at openjdk.org  Wed Jul 12 21:57:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 12 Jul 2023 21:57:46 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v5]
In-Reply-To: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
Message-ID: <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>

> addressing some review comments related to PR [1]
> 
> [1] https://github.com/openjdk/valhalla/pull/872

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing another round of review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/880/files
  - new: https://git.openjdk.org/valhalla/pull/880/files/c6f88ac7..054b5483

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

  Stats: 116 lines in 4 files changed: 55 ins; 50 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/880.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/880/head:pull/880

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


From vromero at openjdk.org  Wed Jul 12 21:57:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 12 Jul 2023 21:57:49 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v4]
In-Reply-To: <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <DWW7p1EYCbB7r__NDtT-alU3Lt-nx4ONklW8Mzaj8Y8=.a16b2f8c-c311-47ba-8b86-0d9191d555cc@github.com>
Message-ID: <ELLtAhw5Ez-jU-eYKKDp3DpaK2uFBkiBtnRk90I34m8=.8f4a6687-c4bc-473f-a9eb-b31e65087bb9@github.com>

On Wed, 5 Jul 2023 21:20:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding more regression tests

thanks for the review comments, I have uploaded another iteration

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

PR Comment: https://git.openjdk.org/valhalla/pull/880#issuecomment-1633258030


From Xiaohong.Gong at arm.com  Thu Jul 13 07:32:25 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Thu, 13 Jul 2023 07:32:25 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <DB9PR08MB7747C489925A4FF82957B5D0F536A@DB9PR08MB7747.eurprd08.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
 <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>
 <074612E1-5D17-4B3C-90BA-FD0A5B35D810@oracle.com>
 <DB9PR08MB7747C489925A4FF82957B5D0F536A@DB9PR08MB7747.eurprd08.prod.outlook.com>
Message-ID: <DB9PR08MB7747F57DCAF2CA674EFE9CF6F537A@DB9PR08MB7747.eurprd08.prod.outlook.com>

Hi Fred,

When I was trying to make the flag "InlineFieldMaxFlatSize" work by changing the code
as we discussed, I found the issue is more than I expected. Fixing the option would make
about 11 tests under "hotspot/jtreg/compiler/valhalla/inlinetypes" crash with following
log:

```
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (valhalla/src/hotspot/share/opto/compile.cpp:2046), pid=3207713, tid=3207728
#  assert(false) failed: Should have been buffered
#
# JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-7e09a28ad)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-7e09a28ad, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x970e0c]  Compile::process_inline_types(PhaseIterGVN&, bool)+0x3e8
```

All these tests set "-XX:InlineFieldMaxFlatSize=0" when running. From the log, it seems the
expected buffer is not allocated or the oop maybe null for an inline type value that is not
expected to be flattened due to its size. 

Since I'm not so familiar with the relative details, could you please help to take a look?

And you may fix the issue if you like. 
The filed JBS is: https://bugs.openjdk.org/browse/JDK-8311219.

Thanks,
Xiaohong


-----Original Message-----
From: Xiaohong Gong 
Sent: Wednesday, July 12, 2023 3:22 PM
To: John Rose <john.r.rose at oracle.com>; Frederic Parain <frederic.parain at oracle.com>
Cc: valhalla-dev at openjdk.org; nd <nd at arm.com>
Subject: RE: [External] : RE: Question on the inline type flattening decision

Hi John, Fred,

Thanks for the so detailed explanation for the flattening policy, which really makes sense!

As a summary, maybe we could change the condition like:

```
if (!too_big_to_flatten &&
     (!(too_atomic_to_flatten | too_volatile_to_flatten) || fieldinfo.access_flags().is_final())) { ...
}
```
That is:
1. For non-atomic klass instances (i.e. Q-type), either the final or non-final fields can be flattened if the size is matched.
2. For atomic klass instance (i.e. the default value klass) or volatile fields, only the final fields are flattened if the size is matched.

The main change is promoting the flat size check at the first stage. Other checks are applied under this condition is matched. 
Is this right?

Please correct me if anything is not right! Thanks!

Best Regards,
Xiaohong

-----Original Message-----
From: John Rose <john.r.rose at oracle.com>
Sent: Wednesday, July 12, 2023 2:31 AM
To: Frederic Parain <frederic.parain at oracle.com>
Cc: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org; nd <nd at arm.com>
Subject: Re: [External] : RE: Question on the inline type flattening decision

On 10 Jul 2023, at 8:09, Frederic Parain wrote:

> Hi Xiaohong,
>
>
> Field flattening has two major side effects: atomicity and size.

Yes!  Well put.

Here?s some more fine print:

Atomicity of a value class will be something that its class declaration can opt out of.  For a class that is non-atomic, then (I think) both final and non-final instance fields of its flattenable type (the null-excluding type, aka the ?val type? or Q-type) can use the same policy.

For a value class which is atomic (and that is the default), it will not be possible (until the day we have efficient HTM) to flatten fields of that type, if they are mutable.

(There?s even more fine print for nullable reference types from value classes, if the VM ever tries to inline nullable types, but that?s way in the future and will not be user visible.)

>
> Final fields are not subject to atomicity issues because they are immutable after their initialization.

So the current policy treats non-final instance fields as flattenable, which means it treats them as immutable.  This is 99.99% correct.

There is a technical debt here concerning what sorts of indeterminate behavior are allowed in the 0.01% case, where (a) the constructor for the object containing the flattenable field allows ?this? to escape and another thread picks it up, and (b) the other thread makes a racing read of the flattenable field at just the wrong moment.  Here?s the debt:  Either we do not flatten the field (at least when we know, statically, that this bad thing can happen) or else we somehow delay the racing read until a safe moment (by means of a mutex protocol of some sort), or (yet again) we somehow detune the JVMS to allow atomic value classes to race, if their containers are so rude as to allow concurrent reads through escaped ?this? pointers.  I think the most practical option is the first, which means, sadly, the 99.99% correct policy for final fields needs reconsideration.  But maybe I?ve missed some fortunate aspect in the current policy, that allows it to avoid the 0.01% error.

(It?s corner cases like this that make JVM design exceedingly difficult.  Most language specs. and runtimes don?t bother to track all the details to this level, but Java does.)

>
> Both final and non-final fields have an impact on the object size, and potentially on cache behavior.

This is true for instance fields, because there are an indefinite number of instances of them.  It is not really true for static fields, and that?s a distinction that can have an effect on flattening policy.
The existing policy never flattens static fields; all the code quoted in this thread is for non-static fields.

<digression topic=?flattening static fields?>

There would be zero benefit, and some harm, to flattening static final fields.  The harm is to startup time, when that is dominated by interpreter performance. The JIT doesn?t care either way; it?s a compile-time constant.

Non-final statics are also very different from non-final instance fields, so it is reasonable to use a different policy for them as well.  Since statics are inherently shared across threads, maybe the atomicity issue is more strongly felt; maybe.  Or maybe that?s why we have ?volatile?, to mark fields where we really care about that.  The current policy makes all static reads and writes fully race-free, at the cost of heap-buffering each stored value.

In any case, it is good that the flattening policy code in the Valhalla VM has separate branches for static and non-static fields.

But, I have sometimes wondered if it would be a good idea to have the VM buffer flattened static non-finals secretly in length-one arrays, and tell the getstatic and putstatic opcodes to go look there for their payloads.  It would be a little wasteful, but not much.  The array references would be rooted immutably in the class mirror object, just as if the fields were plain references.  Unlike other heap buffers, a length-one array creates a mutable variable for a value.  But it would make such non-final statics be much more racy.  Maybe its better to tilt to the side of non-raciness, which is what the current policy does.

None of these musing should be taken as a call to consider flattening statics directly in the normal container for static fields, which is the Class mirror object for the class declaring the statics.  This is a wild and tricky tactic, which would probably become unmanageable (for several reasons) if we tried to wedge flattened fields into the poor Class mirror.  Class mirrors are weird enough already.

</digression>

> Bigger objects are less likely to fit in data caches, and bigger 
> distances between fields would require more cache lines and more cache 
> misses to read them. This issue is not significant when accessing fields of a single object, but it can become dominant when accessing fields of objects stored in a flat array.

It?s an interesting tradeoff:  Indirections almost certainly depart to new cache lines, while if you pile up enough size in flattened variables, then you start departing the cache line just to get to the other side of a single object.  (HW prefetchers often favor contiguous block accesses, which make it favorable longer.)

Also, and semi-independently, memory traffic correlates with cache line traffic.  So if your workload is very flat and cache-line-local, but it loads a bunch of useless bits in every flat object, those useless bits will have a similar effect to (prefetchable) cache line departures.
This can happen even if all the objects fit in one cache line, if the alternative was to have two objects fit in each cache line, in a different organization of the data.  The enabling condition there is that an object might have ?hot? and ?cold? fields, in which case flattening the ?cold?
fields will incur a tax (in data case traffic) on access to the ?hot?
fields.  Because loading a cold field you don?t need into a full data cache will displace some other object?s hot field which you do need.

The way I like to think about this latter effect is to envision, on the one hand, everything flattened as much as possible, with no pointers or headers loaded into the cache, but maybe with some ?garbage? bits mixed into the flat data.  (?Garbage? bits are, for example, bits which are zero 99% of the time.)  And on the other hand, everything indirected through pointers, which means every non-garbage data reference has to thread through a pointer and jump past a header (loading those items into the cache, AND making a non-prefetchable load), but also enjoying the freedom from loading flattened garbage data.  You can flatten too much, if what?s flattened into your containers has low entropy, and eventually it can cause enough data cache traffic that you wish for your pointers back, so you can refrain from loading cold garbage at the other end of some of those pointers.

>
> So, in theory, the flattening test should be:
>
> ? if (!((!fieldinfo.access_flags().is_final() && 
> (too_atomic_to_flatten || too_volatile_to_flatten))
> ??????? || too_big_to_flatten)) {
>
> Atomicity constraints are considered only for non-final fields, and 
> size constraints are considered for all fields.
>
>
> That being said, we have always been more aggressive in the flattening 
> of final fields because it was beneficial to C2.

Yes.  There?s a debt to pay here, though.  It might be that we end up rethinking this policy, regarding non-static final fields, for the two cases of declared-atomic (the default) and declared-non-atomic (the racy power-user option).

? John

From Xiaohong.Gong at arm.com  Thu Jul 13 09:46:44 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Thu, 13 Jul 2023 09:46:44 +0000
Subject: [External] : RE: Question on the inline type flattening decision
In-Reply-To: <DB9PR08MB7747F57DCAF2CA674EFE9CF6F537A@DB9PR08MB7747.eurprd08.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>
 <GVXPR08MB7750633CE17CC4FAF7C6067AF529A@GVXPR08MB7750.eurprd08.prod.outlook.com>
 <48676a2a-efee-a741-bf48-69441b812e77@oracle.com>
 <AS8PR08MB77664DF15BF8CCEB60164E4CF52DA@AS8PR08MB7766.eurprd08.prod.outlook.com>
 <7d32a39a-78be-d46a-09b2-c9b04352351b@oracle.com>
 <074612E1-5D17-4B3C-90BA-FD0A5B35D810@oracle.com>
 <DB9PR08MB7747C489925A4FF82957B5D0F536A@DB9PR08MB7747.eurprd08.prod.outlook.com>
 <DB9PR08MB7747F57DCAF2CA674EFE9CF6F537A@DB9PR08MB7747.eurprd08.prod.outlook.com>
Message-ID: <DB9PR08MB774707643762894D040B406CF537A@DB9PR08MB7747.eurprd08.prod.outlook.com>

Hi Fred,

Sorry for the noise! Applying such patch can fix most of the crashes:

```
diff --git a/src/hotspot/share/opto/parseHelper.cpp b/src/hotspot/share/opto/parseHelper.cpp
index 6aefd3686..848a13a64 100644
--- a/src/hotspot/share/opto/parseHelper.cpp
+++ b/src/hotspot/share/opto/parseHelper.cpp
@@ -351,14 +351,17 @@ void Parse::do_withfield() {
     // Scalarize inline type field value
     assert(!field->is_null_free() || !gvn().type(val)->maybe_null(), "Null store to null-free field");
     val = InlineTypeNode::make_from_oop(this, val, field->type()->as_inline_klass(), field->is_null_free());
-  } else if (val->is_InlineType() && !field->is_null_free()) {
-    // Field value needs to be allocated because it can be merged with an oop.
-    // Re-execute withfield if buffering triggers deoptimization.
-    PreserveReexecuteState preexecs(this);
-    jvms()->set_should_reexecute(true);
-    int nargs = 1 + field->type()->size();
-    inc_sp(nargs);
-    val = val->as_InlineType()->buffer(this);
+  } else if (val->is_InlineType()) {
+    int index = holder->as_InlineType()->field_index(field->offset_in_bytes());
+    if (!holder->as_InlineType()->field_is_flattened(index)) {
+      // Field value needs to be allocated because it can be merged with an oop.
+      // Re-execute withfield if buffering triggers deoptimization.
+      PreserveReexecuteState preexecs(this);
+      jvms()->set_should_reexecute(true);
+      int nargs = 1 + field->type()->size();
+      inc_sp(nargs);
+      val = val->as_InlineType()->buffer(this);
+    }
   }

   // Clone the inline type node and set the new field value
```

The main issue behind is it checks the "null_free" instead of the flatten status when
decide whether to allocate the buffer for an InlineType field. 

Thanks,
Xiaohong

-----Original Message-----
From: Xiaohong Gong 
Sent: Thursday, July 13, 2023 3:32 PM
To: Frederic Parain <frederic.parain at oracle.com>
Cc: valhalla-dev at openjdk.org; nd <nd at arm.com>
Subject: RE: [External] : RE: Question on the inline type flattening decision

Hi Fred,

When I was trying to make the flag "InlineFieldMaxFlatSize" work by changing the code as we discussed, I found the issue is more than I expected. Fixing the option would make about 11 tests under "hotspot/jtreg/compiler/valhalla/inlinetypes" crash with following
log:

```
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (valhalla/src/hotspot/share/opto/compile.cpp:2046), pid=3207713, tid=3207728 #  assert(false) failed: Should have been buffered # # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-7e09a28ad) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-7e09a28ad, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame:
# V  [libjvm.so+0x970e0c]  Compile::process_inline_types(PhaseIterGVN&, bool)+0x3e8 ```

All these tests set "-XX:InlineFieldMaxFlatSize=0" when running. From the log, it seems the expected buffer is not allocated or the oop maybe null for an inline type value that is not expected to be flattened due to its size. 

Since I'm not so familiar with the relative details, could you please help to take a look?

And you may fix the issue if you like. 
The filed JBS is: https://bugs.openjdk.org/browse/JDK-8311219.

Thanks,
Xiaohong


-----Original Message-----
From: Xiaohong Gong
Sent: Wednesday, July 12, 2023 3:22 PM
To: John Rose <john.r.rose at oracle.com>; Frederic Parain <frederic.parain at oracle.com>
Cc: valhalla-dev at openjdk.org; nd <nd at arm.com>
Subject: RE: [External] : RE: Question on the inline type flattening decision

Hi John, Fred,

Thanks for the so detailed explanation for the flattening policy, which really makes sense!

As a summary, maybe we could change the condition like:

```
if (!too_big_to_flatten &&
     (!(too_atomic_to_flatten | too_volatile_to_flatten) || fieldinfo.access_flags().is_final())) { ...
}
```
That is:
1. For non-atomic klass instances (i.e. Q-type), either the final or non-final fields can be flattened if the size is matched.
2. For atomic klass instance (i.e. the default value klass) or volatile fields, only the final fields are flattened if the size is matched.

The main change is promoting the flat size check at the first stage. Other checks are applied under this condition is matched. 
Is this right?

Please correct me if anything is not right! Thanks!

Best Regards,
Xiaohong

-----Original Message-----
From: John Rose <john.r.rose at oracle.com>
Sent: Wednesday, July 12, 2023 2:31 AM
To: Frederic Parain <frederic.parain at oracle.com>
Cc: Xiaohong Gong <Xiaohong.Gong at arm.com>; valhalla-dev at openjdk.org; nd <nd at arm.com>
Subject: Re: [External] : RE: Question on the inline type flattening decision

On 10 Jul 2023, at 8:09, Frederic Parain wrote:

> Hi Xiaohong,
>
>
> Field flattening has two major side effects: atomicity and size.

Yes!  Well put.

Here?s some more fine print:

Atomicity of a value class will be something that its class declaration can opt out of.  For a class that is non-atomic, then (I think) both final and non-final instance fields of its flattenable type (the null-excluding type, aka the ?val type? or Q-type) can use the same policy.

For a value class which is atomic (and that is the default), it will not be possible (until the day we have efficient HTM) to flatten fields of that type, if they are mutable.

(There?s even more fine print for nullable reference types from value classes, if the VM ever tries to inline nullable types, but that?s way in the future and will not be user visible.)

>
> Final fields are not subject to atomicity issues because they are immutable after their initialization.

So the current policy treats non-final instance fields as flattenable, which means it treats them as immutable.  This is 99.99% correct.

There is a technical debt here concerning what sorts of indeterminate behavior are allowed in the 0.01% case, where (a) the constructor for the object containing the flattenable field allows ?this? to escape and another thread picks it up, and (b) the other thread makes a racing read of the flattenable field at just the wrong moment.  Here?s the debt:  Either we do not flatten the field (at least when we know, statically, that this bad thing can happen) or else we somehow delay the racing read until a safe moment (by means of a mutex protocol of some sort), or (yet again) we somehow detune the JVMS to allow atomic value classes to race, if their containers are so rude as to allow concurrent reads through escaped ?this? pointers.  I think the most practical option is the first, which means, sadly, the 99.99% correct policy for final fields needs reconsideration.  But maybe I?ve missed some fortunate aspect in the current policy, that allows it to avoid the 0.01% error.

(It?s corner cases like this that make JVM design exceedingly difficult.  Most language specs. and runtimes don?t bother to track all the details to this level, but Java does.)

>
> Both final and non-final fields have an impact on the object size, and potentially on cache behavior.

This is true for instance fields, because there are an indefinite number of instances of them.  It is not really true for static fields, and that?s a distinction that can have an effect on flattening policy.
The existing policy never flattens static fields; all the code quoted in this thread is for non-static fields.

<digression topic=?flattening static fields?>

There would be zero benefit, and some harm, to flattening static final fields.  The harm is to startup time, when that is dominated by interpreter performance. The JIT doesn?t care either way; it?s a compile-time constant.

Non-final statics are also very different from non-final instance fields, so it is reasonable to use a different policy for them as well.  Since statics are inherently shared across threads, maybe the atomicity issue is more strongly felt; maybe.  Or maybe that?s why we have ?volatile?, to mark fields where we really care about that.  The current policy makes all static reads and writes fully race-free, at the cost of heap-buffering each stored value.

In any case, it is good that the flattening policy code in the Valhalla VM has separate branches for static and non-static fields.

But, I have sometimes wondered if it would be a good idea to have the VM buffer flattened static non-finals secretly in length-one arrays, and tell the getstatic and putstatic opcodes to go look there for their payloads.  It would be a little wasteful, but not much.  The array references would be rooted immutably in the class mirror object, just as if the fields were plain references.  Unlike other heap buffers, a length-one array creates a mutable variable for a value.  But it would make such non-final statics be much more racy.  Maybe its better to tilt to the side of non-raciness, which is what the current policy does.

None of these musing should be taken as a call to consider flattening statics directly in the normal container for static fields, which is the Class mirror object for the class declaring the statics.  This is a wild and tricky tactic, which would probably become unmanageable (for several reasons) if we tried to wedge flattened fields into the poor Class mirror.  Class mirrors are weird enough already.

</digression>

> Bigger objects are less likely to fit in data caches, and bigger 
> distances between fields would require more cache lines and more cache 
> misses to read them. This issue is not significant when accessing fields of a single object, but it can become dominant when accessing fields of objects stored in a flat array.

It?s an interesting tradeoff:  Indirections almost certainly depart to new cache lines, while if you pile up enough size in flattened variables, then you start departing the cache line just to get to the other side of a single object.  (HW prefetchers often favor contiguous block accesses, which make it favorable longer.)

Also, and semi-independently, memory traffic correlates with cache line traffic.  So if your workload is very flat and cache-line-local, but it loads a bunch of useless bits in every flat object, those useless bits will have a similar effect to (prefetchable) cache line departures.
This can happen even if all the objects fit in one cache line, if the alternative was to have two objects fit in each cache line, in a different organization of the data.  The enabling condition there is that an object might have ?hot? and ?cold? fields, in which case flattening the ?cold?
fields will incur a tax (in data case traffic) on access to the ?hot?
fields.  Because loading a cold field you don?t need into a full data cache will displace some other object?s hot field which you do need.

The way I like to think about this latter effect is to envision, on the one hand, everything flattened as much as possible, with no pointers or headers loaded into the cache, but maybe with some ?garbage? bits mixed into the flat data.  (?Garbage? bits are, for example, bits which are zero 99% of the time.)  And on the other hand, everything indirected through pointers, which means every non-garbage data reference has to thread through a pointer and jump past a header (loading those items into the cache, AND making a non-prefetchable load), but also enjoying the freedom from loading flattened garbage data.  You can flatten too much, if what?s flattened into your containers has low entropy, and eventually it can cause enough data cache traffic that you wish for your pointers back, so you can refrain from loading cold garbage at the other end of some of those pointers.

>
> So, in theory, the flattening test should be:
>
> ? if (!((!fieldinfo.access_flags().is_final() && 
> (too_atomic_to_flatten || too_volatile_to_flatten))
> ??????? || too_big_to_flatten)) {
>
> Atomicity constraints are considered only for non-final fields, and 
> size constraints are considered for all fields.
>
>
> That being said, we have always been more aggressive in the flattening 
> of final fields because it was beneficial to C2.

Yes.  There?s a debt to pay here, though.  It might be that we end up rethinking this policy, regarding non-static final fields, for the two cases of declared-atomic (the default) and declared-non-atomic (the racy power-user option).

? John

From thartmann at openjdk.org  Thu Jul 13 12:07:17 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 13 Jul 2023 12:07:17 GMT
Subject: [lworld] RFR: 8311383: [lworld] Restoring inline class mirrors
 with CDS.
In-Reply-To: <OZPs14xUHUlTBjIA01K7YgQQpwudfQJy45DXb8HSCes=.fd7a9d40-77f3-473d-bc30-f4bd76bcd848@github.com>
References: <OZPs14xUHUlTBjIA01K7YgQQpwudfQJy45DXb8HSCes=.fd7a9d40-77f3-473d-bc30-f4bd76bcd848@github.com>
Message-ID: <TgijfaAYePwadtja04WvLdCGndKhlZlPlVzc2Ugpo3E=.f4adc534-66fa-4591-818a-3377720d2a59@github.com>

On Mon, 10 Jul 2023 01:32:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Inline class encapsulate following two mirror objects
>   - Value mirror : primitive value class instance
>   - Reference mirror  : primitive reference class instance ( .ref)
>  
> Currently, runtime allocates and updates java mirror corresponding to a klass in a scratch memory and dumps [1] these into shared archive.  Skipping over allocating inline mirrors into scratch memory for the time being since they can be re-created while restoring unshared fields of inline class[2] during share archive read. 
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/cds/heapShared.cpp#L392
> [2] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/oops/klass.cpp#L624

Looks reasonable to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/884#pullrequestreview-1528282425


From fparain at openjdk.org  Thu Jul 13 13:16:24 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 13 Jul 2023 13:16:24 GMT
Subject: [lworld] RFR: 8310651: [lworld] ValueConstantDesc fails after
 merge with jdk-21+25
In-Reply-To: <CxeuFeeK9hJHB1o3rta4kFbP9j8RXl1_eBXLTXgwNsI=.321c9222-beac-4f01-80fe-554e9caa4a9d@github.com>
References: <CxeuFeeK9hJHB1o3rta4kFbP9j8RXl1_eBXLTXgwNsI=.321c9222-beac-4f01-80fe-554e9caa4a9d@github.com>
Message-ID: <hRLTpMIwE1X-S-Zq2VAlAyxzyTMfX84JVKL9BlVUqbE=.902cf1a7-c3ba-4e56-91f2-850e78392e59@github.com>

On Wed, 12 Jul 2023 21:48:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The test fails because of an incorrect merge with [JDK-8304928](https://bugs.openjdk.org/browse/JDK-8304928).   JDK-8304928 special cases the array type and the merge moves the logic to determine Q-descriptor just for the array type case but misses the normal class case.

Looks good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/885#pullrequestreview-1528415003


From mchung at openjdk.org  Thu Jul 13 16:00:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 13 Jul 2023 16:00:27 GMT
Subject: [lworld] Integrated: 8310651: [lworld] ValueConstantDesc fails after
 merge with jdk-21+25
In-Reply-To: <CxeuFeeK9hJHB1o3rta4kFbP9j8RXl1_eBXLTXgwNsI=.321c9222-beac-4f01-80fe-554e9caa4a9d@github.com>
References: <CxeuFeeK9hJHB1o3rta4kFbP9j8RXl1_eBXLTXgwNsI=.321c9222-beac-4f01-80fe-554e9caa4a9d@github.com>
Message-ID: <GKNGqP16NFRxmhM5tGyyn_sz6Yr3eeEvxsNbaj8im3g=.c4f74f8e-6b5e-4f2f-adb6-ed011201eba5@github.com>

On Wed, 12 Jul 2023 21:48:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The test fails because of an incorrect merge with [JDK-8304928](https://bugs.openjdk.org/browse/JDK-8304928).   JDK-8304928 special cases the array type and the merge moves the logic to determine Q-descriptor just for the array type case but misses the normal class case.

This pull request has now been integrated.

Changeset: ab7f741d
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ab7f741d287e933d6de82be5f5ad5eab20f965e8
Stats:     20 lines in 2 files changed: 11 ins; 7 del; 2 mod

8310651: [lworld] ValueConstantDesc fails after merge with jdk-21+25

Reviewed-by: fparain

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

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


From mcimadamore at openjdk.org  Thu Jul 13 16:27:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 13 Jul 2023 16:27:28 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v5]
In-Reply-To: <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>
Message-ID: <q095AJiIXYYQRNJoxMEJ__L082znNd3A5NSzynEYQl0=.93bbfbc7-103f-48d7-b093-abdb031dad92@github.com>

On Wed, 12 Jul 2023 21:57:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing another round of review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1288:

> 1286:             @Override
> 1287:             public Boolean visitType(Type t, Type s) {
> 1288:                 Warner warner = !warnStack.isEmpty() ? warnStack.head : noWarnings;

Good cleanup. I assume that now nullability comparator really has no state, so you could in principle create two instances (with the two comparator functions), and just use those instances, right?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4490:

> 4488:                 case UNCHECKED:
> 4489:                     Check.this.warnUnchecked(pos(), Warnings.ProbFoundReq(diags.fragment(uncheckedKey), found, expected));
> 4490:                     this.warned = true;

Odd - this field is clearly meant to be set in this method, but it is not in mainline. Maybe better to set the field only once, after the switch?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1262786970
PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1262792902


From vromero at openjdk.org  Thu Jul 13 20:08:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 13 Jul 2023 20:08:24 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v5]
In-Reply-To: <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>
Message-ID: <A0KS1X8yX7N9wDhb6eopVSMS7_MuAwVZoM_SdN1h2-k=.402ace09-955a-455b-b87a-a2d1d827e0db@github.com>

On Wed, 12 Jul 2023 21:57:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing another round of review comments

offline comments by Dan:

A constructor call, and all literals, can be considered to have a null-restricted type.
We shouldn't report warnings about things like:
Foo! f = new Foo(...); or String! s = "abc";

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

PR Comment: https://git.openjdk.org/valhalla/pull/880#issuecomment-1634834072


From vromero at openjdk.org  Thu Jul 13 22:03:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 13 Jul 2023 22:03:17 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v5]
In-Reply-To: <q095AJiIXYYQRNJoxMEJ__L082znNd3A5NSzynEYQl0=.93bbfbc7-103f-48d7-b093-abdb031dad92@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>
 <q095AJiIXYYQRNJoxMEJ__L082znNd3A5NSzynEYQl0=.93bbfbc7-103f-48d7-b093-abdb031dad92@github.com>
Message-ID: <JpLpNHatS_ioOa8QQY1uh45h7KCl9UxyShbWZdHOmfc=.639bcccf-365a-4a44-83e4-b4fdc72b03e4@github.com>

On Thu, 13 Jul 2023 16:18:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing another round of review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1288:
> 
>> 1286:             @Override
>> 1287:             public Boolean visitType(Type t, Type s) {
>> 1288:                 Warner warner = !warnStack.isEmpty() ? warnStack.head : noWarnings;
> 
> Good cleanup. I assume that now nullability comparator really has no state, so you could in principle create two instances (with the two comparator functions), and just use those instances, right?

not really, in one case we are using this comparator: `(t1, t2) -> !hasSameNullability(t1, t2)`, see the `!` operator, so we would need three different instances

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1263090489


From vromero at openjdk.org  Thu Jul 13 22:35:41 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 13 Jul 2023 22:35:41 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v6]
In-Reply-To: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
Message-ID: <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>

> addressing some review comments related to PR [1]
> 
> [1] https://github.com/openjdk/valhalla/pull/872

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - addressing additional review comments
 - dont generate warnings for literals or constructor invocations

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/880/files
  - new: https://git.openjdk.org/valhalla/pull/880/files/054b5483..0c168ed2

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

  Stats: 84 lines in 7 files changed: 58 ins; 15 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/880.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/880/head:pull/880

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


From vromero at openjdk.org  Thu Jul 13 22:35:45 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 13 Jul 2023 22:35:45 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v5]
In-Reply-To: <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>
Message-ID: <hE68rumhwDdDKyxM-MiOOFgV9VI41mFtg-QlIaVg6ZA=.ba982a0e-5808-46d8-99e4-5518d9c785c7@github.com>

On Wed, 12 Jul 2023 21:57:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing another round of review comments

I have pushed two commits, one addressing your last comments and another that addresses Dan's offline comments above, the one related to constructor invocations and literals. If preferred I can push this commit as part of another PR

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

PR Comment: https://git.openjdk.org/valhalla/pull/880#issuecomment-1634998124


From mcimadamore at openjdk.org  Fri Jul 14 00:40:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Jul 2023 00:40:22 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v5]
In-Reply-To: <JpLpNHatS_ioOa8QQY1uh45h7KCl9UxyShbWZdHOmfc=.639bcccf-365a-4a44-83e4-b4fdc72b03e4@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <FyK-3fTuwqzB8VzKAjCh-915p41QTb9F8P1rCTaldco=.489b98c6-9d29-45d4-a6dd-5ba758e38cab@github.com>
 <q095AJiIXYYQRNJoxMEJ__L082znNd3A5NSzynEYQl0=.93bbfbc7-103f-48d7-b093-abdb031dad92@github.com>
 <JpLpNHatS_ioOa8QQY1uh45h7KCl9UxyShbWZdHOmfc=.639bcccf-365a-4a44-83e4-b4fdc72b03e4@github.com>
Message-ID: <a0hVn4D8yqmcffbhMdESK_53g9MMNbXf6pdmjjSSrww=.d69b757b-375e-44a3-92ca-120931ae9a65@github.com>

On Thu, 13 Jul 2023 22:00:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1288:
>> 
>>> 1286:             @Override
>>> 1287:             public Boolean visitType(Type t, Type s) {
>>> 1288:                 Warner warner = !warnStack.isEmpty() ? warnStack.head : noWarnings;
>> 
>> Good cleanup. I assume that now nullability comparator really has no state, so you could in principle create two instances (with the two comparator functions), and just use those instances, right?
>
> not really, in one case we are using this comparator: `(t1, t2) -> !hasSameNullability(t1, t2)`, see the `!` operator, so we would need three different instances

I see - but still - there is no state in the comparator - right? E.g. in principle clients can allocate a new one and take it from there each time. So perhaps that would be more honest, rather than having a shared instance but then having to call a `reset` method?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1263164205


From mcimadamore at openjdk.org  Fri Jul 14 00:44:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Jul 2023 00:44:19 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v6]
In-Reply-To: <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>
Message-ID: <KyNjV3ioC_sTvA4AYEEMU5Egr9vCfIjzfer5BofBpSs=.8cb2c88c-ad65-4d6f-b30d-de929b0b0cc2@github.com>

On Thu, 13 Jul 2023 22:35:41 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addressing additional review comments
>  - dont generate warnings for literals or constructor invocations

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 399:

> 397:     public <M extends TypeMetadata, Z> Z getMetadata(Class<M> metadataClass, Function<M, Z> metadataFunc, Z defaultValue) {
> 398:         for (TypeMetadata m : metadata) {
> 399:             if (m.getClass().isAssignableFrom(metadataClass)) {

isn't TypeMetadata `sealed` ? I suppose the code you wrote is correct (and better than `==`), but I don't think we should have inherited metadata? E.g. an `equals` should be good?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1263165764


From mcimadamore at openjdk.org  Fri Jul 14 00:47:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Jul 2023 00:47:22 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v6]
In-Reply-To: <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>
Message-ID: <flKQz6J2WcQngv7ROcnS88xnHfug7Oe8FCrzBT0ZBgU=.38c0eedb-fe4c-4f95-b420-cab606c3ceef@github.com>

On Thu, 13 Jul 2023 22:35:41 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addressing additional review comments
>  - dont generate warnings for literals or constructor invocations

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5407:

> 5405:     public boolean hasSameNullability(Type t, Type s) {
> 5406:         // special case for literals, a literal is always != null
> 5407:         boolean isLiteral = s != null && s.getMetadata(TypeMetadata.ConstantValue.class) != null;

I believe this should be addressed at the level of the `isNullUnspecified` predicates. E.g. if something is a constant type, then you know it's null-restricted (e.g. because we infer it so). Once that's dealt with, I believe these higher-level methods here can stay unchanged?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1263167309


From mcimadamore at openjdk.org  Fri Jul 14 00:52:17 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 14 Jul 2023 00:52:17 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v6]
In-Reply-To: <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>
Message-ID: <SeM86LXs3LBUdIgGHRsKKmjE30fDhNsRicTxwM-ZGbA=.a768fbcd-2a5a-4820-a2f1-972c932500a3@github.com>

On Thu, 13 Jul 2023 22:35:41 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - addressing additional review comments
>  - dont generate warnings for literals or constructor invocations

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 2899:

> 2897:                 owntype = clazztype;
> 2898:                 if (owntype.getMetadata(TypeMetadata.NullMarker.class) == null) {
> 2899:                     owntype = owntype.addMetadata(new TypeMetadata.NullMarker(NullMarker.NOT_NULL)); // constructor invocations are always null restricted

I note an asymmetry here: for constructor calls, we annotate the type to say it's non-null. But for constant types we don't, and we instead look as to whether there's constant metadata. Perhaps an alternative to the suggestion I gave above is to simply set the null-restricted metadata in the visitLiteral method, so that everything is explicit.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 915:

> 913:         for (List<JCExpression> l = trees; l.nonEmpty(); l = l.tail) {
> 914:             genExpr(l.head, pts.head).load();
> 915:             if (pts.head.isNonNullable() && l.head.type.constValue() == null) {

These changes should become unnecessary if `isNonNullable` does the right thing.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1263168555
PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1263168856


From jbhateja at openjdk.org  Fri Jul 14 05:25:15 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 14 Jul 2023 05:25:15 GMT
Subject: [lworld] Integrated: 8311383: [lworld] Restoring inline class mirrors
 with CDS.
In-Reply-To: <OZPs14xUHUlTBjIA01K7YgQQpwudfQJy45DXb8HSCes=.fd7a9d40-77f3-473d-bc30-f4bd76bcd848@github.com>
References: <OZPs14xUHUlTBjIA01K7YgQQpwudfQJy45DXb8HSCes=.fd7a9d40-77f3-473d-bc30-f4bd76bcd848@github.com>
Message-ID: <M-zXtw8lVqJpxu4oaTx5VwSRwU36XgJKRCiCa-vzSOU=.e03b55f5-67f4-4b00-ae85-ec82eada2c13@github.com>

On Mon, 10 Jul 2023 01:32:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Inline class encapsulate following two mirror objects
>   - Value mirror : primitive value class instance
>   - Reference mirror  : primitive reference class instance ( .ref)
>  
> Currently, runtime allocates and updates java mirror corresponding to a klass in a scratch memory and dumps [1] these into shared archive.  Skipping over allocating inline mirrors into scratch memory for the time being since they can be re-created while restoring unshared fields of inline class[2] during share archive read. 
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/cds/heapShared.cpp#L392
> [2] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/oops/klass.cpp#L624

This pull request has now been integrated.

Changeset: 2d65027f
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2d65027f17871acf4f641db74e71bd81fdb7fa5b
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8311383: [lworld] Restoring inline class mirrors with CDS.

Reviewed-by: thartmann

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

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


From vromero at openjdk.org  Fri Jul 14 11:41:20 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jul 2023 11:41:20 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v6]
In-Reply-To: <flKQz6J2WcQngv7ROcnS88xnHfug7Oe8FCrzBT0ZBgU=.38c0eedb-fe4c-4f95-b420-cab606c3ceef@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>
 <flKQz6J2WcQngv7ROcnS88xnHfug7Oe8FCrzBT0ZBgU=.38c0eedb-fe4c-4f95-b420-cab606c3ceef@github.com>
Message-ID: <-ukJhAVMnFY25xJEzFOSF1IcLhuU0DMSKHCMw8MOYS0=.65aed218-e2d4-4032-8b24-621b8e0f69b3@github.com>

On Fri, 14 Jul 2023 00:44:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressing additional review comments
>>  - dont generate warnings for literals or constructor invocations
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5407:
> 
>> 5405:     public boolean hasSameNullability(Type t, Type s) {
>> 5406:         // special case for literals, a literal is always != null
>> 5407:         boolean isLiteral = s != null && s.getMetadata(TypeMetadata.ConstantValue.class) != null;
> 
> I believe this should be addressed at the level of the `isNullUnspecified` predicates. E.g. if something is a constant type, then you know it's null-restricted (e.g. because we infer it so). Once that's dealt with, I believe these higher-level methods here can stay unchanged?

yes I did that experiment first but then I got to some unexpected issues. For example: `1L` now would be consider to have type `long!` which doesn't make too much sense, we could exclude primitives from the predicates I guess but there are still some other places where we can have surprises. I found this example:


import java.lang.invoke.*;
class Cell {
    final void reset() {
        /* we are testing that the compiler won't infer the arguments of
         * VarHandle::setVolatile as (Cell, String!)
         */
        VALUE.setVolatile(this, "");
    }
    final void reset(String identity) {
        /* if that were the case, see comment above, then this invocation would generate
         * a warning, VarHandle::setVolatile is a polymorphic signature method
         */
        VALUE.setVolatile(this, identity);
    }
                                                                
    private static final VarHandle VALUE;
    static {
        try {
            MethodHandles.Lookup l = MethodHandles.lookup();
            VALUE = l.findVarHandle(Cell.class, "value", long.class);
        } catch (ReflectiveOperationException e) {
            throw new ExceptionInInitializerError(e);
        }
    }
}

VarHandle::setVolatile is a polymorphic signature method. So from the first invocation the compiler would infer argument types: `(Cell, String!)` is this what we want? For the second invocation we find that we already have a method that matches but the invocation will generate a warning if compiled with `Xlint:null`, not sure we want this. This is why I preferred to stay with the declared type for literals and tread them as a special case. We can still do what you suggest and do something different when we infer the signature of polymorphic sig methods, like remove null restrictions from the inferred type.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1263633512


From vromero at openjdk.org  Fri Jul 14 15:47:16 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jul 2023 15:47:16 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v6]
In-Reply-To: <KyNjV3ioC_sTvA4AYEEMU5Egr9vCfIjzfer5BofBpSs=.8cb2c88c-ad65-4d6f-b30d-de929b0b0cc2@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <hEiVW2nRItl7l0JSBQu4uYN77raaPkyOFx1tsEzqnfM=.622751aa-59a7-4088-9757-f89984585298@github.com>
 <KyNjV3ioC_sTvA4AYEEMU5Egr9vCfIjzfer5BofBpSs=.8cb2c88c-ad65-4d6f-b30d-de929b0b0cc2@github.com>
Message-ID: <pmISIxTgdcGr32W_58l01uLeZ6hYhFxY77RUFFZPj78=.7961c790-0b41-42ae-a049-85f4f23759a1@github.com>

On Fri, 14 Jul 2023 00:41:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - addressing additional review comments
>>  - dont generate warnings for literals or constructor invocations
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 399:
> 
>> 397:     public <M extends TypeMetadata, Z> Z getMetadata(Class<M> metadataClass, Function<M, Z> metadataFunc, Z defaultValue) {
>> 398:         for (TypeMetadata m : metadata) {
>> 399:             if (m.getClass().isAssignableFrom(metadataClass)) {
> 
> isn't TypeMetadata `sealed` ? I suppose the code you wrote is correct (and better than `==`), but I don't think we should have inherited metadata? E.g. an `equals` should be good?

yes I guess it should be good, I will replace it in the next iteration

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1263880583


From fparain at openjdk.org  Tue Jul 18 14:54:33 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 18 Jul 2023 14:54:33 GMT
Subject: [lworld] RFR: 8312231: Replacing NULL with nullptr in shared code
Message-ID: <nglFEOh7Ys_sHk_ZE4ZtAiZFU_c7pHkXeeb98tNLgW8=.b361c8a4-24d2-49dc-a088-00ced6d2f8d3@github.com>

This patch applies the NULL -> nullptr transition to shared code.

Builds tested with Mach5 (tier1).

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

Commit messages:
 - Replacing NULL with nullptr

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

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


From vromero at openjdk.org  Tue Jul 18 18:31:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 18 Jul 2023 18:31:17 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v7]
In-Reply-To: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
Message-ID: <byQsTOEKCb9ejPFhqq377AP4BHdr4V3N31U-saUYOZg=.cbc60a49-f0eb-4e34-a902-550133e2fecf@github.com>

> addressing some review comments related to PR [1]
> 
> [1] https://github.com/openjdk/valhalla/pull/872

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing another round of review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/880/files
  - new: https://git.openjdk.org/valhalla/pull/880/files/0c168ed2..da16b3ba

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

  Stats: 47 lines in 5 files changed: 26 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/880.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/880/head:pull/880

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


From vromero at openjdk.org  Tue Jul 18 18:39:04 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 18 Jul 2023 18:39:04 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v7]
In-Reply-To: <byQsTOEKCb9ejPFhqq377AP4BHdr4V3N31U-saUYOZg=.cbc60a49-f0eb-4e34-a902-550133e2fecf@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <byQsTOEKCb9ejPFhqq377AP4BHdr4V3N31U-saUYOZg=.cbc60a49-f0eb-4e34-a902-550133e2fecf@github.com>
Message-ID: <2I1xAP7hYDPFEMH6GWqeqAGnDBkJGbbBBt6hCsWKeuU=.3e4580ac-c2ac-4055-9b91-63ea2b0dec11@github.com>

On Tue, 18 Jul 2023 18:31:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing another round of review comments

I have uploaded another iteration following our discussion.  Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/880#issuecomment-1640748462


From fparain at openjdk.org  Wed Jul 19 15:20:07 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 19 Jul 2023 15:20:07 GMT
Subject: [lworld] Integrated: 8312231: Replacing NULL with nullptr in shared
 code
In-Reply-To: <nglFEOh7Ys_sHk_ZE4ZtAiZFU_c7pHkXeeb98tNLgW8=.b361c8a4-24d2-49dc-a088-00ced6d2f8d3@github.com>
References: <nglFEOh7Ys_sHk_ZE4ZtAiZFU_c7pHkXeeb98tNLgW8=.b361c8a4-24d2-49dc-a088-00ced6d2f8d3@github.com>
Message-ID: <tO-RUtiBm1xbyq3h0SQ749rOG8gRljMKW3TjHWKVbHM=.87c5a703-a9cf-455a-af54-c5a5c8cc9f6d@github.com>

On Tue, 18 Jul 2023 14:47:49 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> This patch applies the NULL -> nullptr transition to shared code.
> 
> Builds tested with Mach5 (tier1).

This pull request has now been integrated.

Changeset: 9bbdc52c
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9bbdc52c6d7ab8f8c5ff8cf1f25f50490634206a
Stats:     309 lines in 63 files changed: 0 ins; 0 del; 309 mod

8312231: Replacing NULL with nullptr in shared code

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

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


From fparain at openjdk.org  Wed Jul 19 20:30:12 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 19 Jul 2023 20:30:12 GMT
Subject: [lworld] RFR: 8312417: [lworld] Replacing NULL with nullptr in x86
 code
Message-ID: <6yN1Vfn0SKaZS12Lxm3VgXoIBQVX8z6z8BFaoKMseIg=.3157d4f1-5359-48f1-9bbe-f38ce0c790ad@github.com>

Replacing NULL with nullptr in x86 code.
Builds tested with Mach5 (tier1).

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

Commit messages:
 - Replace NULL with nullptr in x86 code

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

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


From mcimadamore at openjdk.org  Wed Jul 19 23:47:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jul 2023 23:47:05 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v7]
In-Reply-To: <byQsTOEKCb9ejPFhqq377AP4BHdr4V3N31U-saUYOZg=.cbc60a49-f0eb-4e34-a902-550133e2fecf@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <byQsTOEKCb9ejPFhqq377AP4BHdr4V3N31U-saUYOZg=.cbc60a49-f0eb-4e34-a902-550133e2fecf@github.com>
Message-ID: <DZibdue2PCGBK1JLDKxuLMExGzwHF9QJa3JnUQnjX2Y=.b57512ab-e31e-4683-82bd-4e4a4a4a3835@github.com>

On Tue, 18 Jul 2023 18:31:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing another round of review comments

Looks good

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

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/880#pullrequestreview-1538201730


From mcimadamore at openjdk.org  Wed Jul 19 23:51:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 19 Jul 2023 23:51:08 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v7]
In-Reply-To: <byQsTOEKCb9ejPFhqq377AP4BHdr4V3N31U-saUYOZg=.cbc60a49-f0eb-4e34-a902-550133e2fecf@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <byQsTOEKCb9ejPFhqq377AP4BHdr4V3N31U-saUYOZg=.cbc60a49-f0eb-4e34-a902-550133e2fecf@github.com>
Message-ID: <jQzkTZVavBV5UqFmX-pnIlZaSnMSvEHKPu50NHCdrvM=.b2bb4c81-e8d9-4dce-8b15-ccb1269bf45e@github.com>

On Tue, 18 Jul 2023 18:31:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> addressing some review comments related to PR [1]
>> 
>> [1] https://github.com/openjdk/valhalla/pull/872
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing another round of review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1120:

> 1118:             return isPrimitive() ?
> 1119:                     addMetadata(new ConstantValue(constValue)) :
> 1120:                     addMetadata(new ConstantValue(constValue)).addMetadata(new TypeMetadata.NullMarker(NullMarker.NOT_NULL));

One nitpick: I can see why having the call here is handy. On the other hand, in terms of code maintenance it would probably be better if `constType` added just one kind of metadata (and we added the NOT_NULL explicitly where we need it). That said, I understand that, pragmatically, Attr is probably not the only place where we call this method, and chasing all the usages might be a bit hard. So let's just keep a mental note of this, going forward. (especially, should we get stuck in situations where, for whatever reason we'd like to have constant-ness w/o having null-restrictedness).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1268787755


From vromero at openjdk.org  Thu Jul 20 03:16:12 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Jul 2023 03:16:12 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v7]
In-Reply-To: <jQzkTZVavBV5UqFmX-pnIlZaSnMSvEHKPu50NHCdrvM=.b2bb4c81-e8d9-4dce-8b15-ccb1269bf45e@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <byQsTOEKCb9ejPFhqq377AP4BHdr4V3N31U-saUYOZg=.cbc60a49-f0eb-4e34-a902-550133e2fecf@github.com>
 <jQzkTZVavBV5UqFmX-pnIlZaSnMSvEHKPu50NHCdrvM=.b2bb4c81-e8d9-4dce-8b15-ccb1269bf45e@github.com>
Message-ID: <CQEaidO8X4O8lootDe65cY6m371MtYeYQ9nBSsetYQ0=.6db10345-b10d-4bea-82da-8d0e35a1198f@github.com>

On Wed, 19 Jul 2023 23:48:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing another round of review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1120:
> 
>> 1118:             return isPrimitive() ?
>> 1119:                     addMetadata(new ConstantValue(constValue)) :
>> 1120:                     addMetadata(new ConstantValue(constValue)).addMetadata(new TypeMetadata.NullMarker(NullMarker.NOT_NULL));
> 
> One nitpick: I can see why having the call here is handy. On the other hand, in terms of code maintenance it would probably be better if `constType` added just one kind of metadata (and we added the NOT_NULL explicitly where we need it). That said, I understand that, pragmatically, Attr is probably not the only place where we call this method, and chasing all the usages might be a bit hard. So let's just keep a mental note of this, going forward. (especially, should we get stuck in situations where, for whatever reason we'd like to have constant-ness w/o having null-restrictedness).

I see your point but yes I agree that for now it is more practical to have the call here. Thanks for all the comments!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/880#discussion_r1268882044


From vromero at openjdk.org  Thu Jul 20 03:16:12 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Jul 2023 03:16:12 GMT
Subject: Integrated: 8310905: [lw5] addressing review comments on null
 restricted types
In-Reply-To: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
Message-ID: <DoFgRoY5SaRRVl9z5cojlyUxVtLD71CJr1HGzBBxu_I=.72b9cde8-5475-43cd-b14e-d7125dbbff33@github.com>

On Wed, 28 Jun 2023 04:11:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> addressing some review comments related to PR [1]
> 
> [1] https://github.com/openjdk/valhalla/pull/872

This pull request has now been integrated.

Changeset: a716bc85
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a716bc8584988d9d91aff1d3c4a4d6f2b930c7d6
Stats:     558 lines in 8 files changed: 455 ins; 65 del; 38 mod

8310905: [lw5] addressing review comments on null restricted types

Reviewed-by: mcimadamore

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

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


From xgong at openjdk.org  Thu Jul 20 09:38:39 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 20 Jul 2023 09:38:39 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
Message-ID: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>

Currently all the non-static final fields with inline type can be flattened, even if the layout size of the inline type is beyond
the max flat size specified by `InlineFieldMaxFlatSize`. Please refer to the condition check [1] which decides whether a field
can be flattened or not.

Field flattening has two major side effects: atomicity and size. Fields with atomic access limitation or large size that exceeds
the specified threshold value cannot be flattened. And final fields are special that they are immutable after initialized. So the atomic check for them can be ignored. Hence, 1) for the atomicity free type like the primitive class, the final and non-final fields with such type can be flattened. And 2) for the normal value class that has atomic feature, only the final fields with such type can be flattened. And all kinds of the flattened fields should not exceed the specified max flat size. Please see more details from [1] [2].

The original condition [1] matches the atomicity check but not the flat size limitation. Promoting the flat size check before all other checks matches the flattening policy and can make the VM option `InlineFieldMaxFlatSize` work for final fields as well.

This patch also fixed the jtreg crashes involved after the field flattening condition is changed. Those tests fail with setting
`-XX:+InlineFieldMaxFlatSize=0` by default. The main issue is the non-flattened inline type field is not buffered which is expected to be. The root cause is when parsing `withfield`, the compiler checks whether the field is primitive class type while not its flattening status. Changing to check the flattening status instead can fix the crash.

[1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L759
[2] https://mail.openjdk.org/pipermail/valhalla-dev/2023-June/011262.html
[3] https://mail.openjdk.org/pipermail/valhalla-dev/2023-July/011265.html

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

Commit messages:
 - 8311219: [lworld] VM option "InlineFieldMaxFlatSize" cannot work well

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

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


From jbhateja at openjdk.org  Fri Jul 21 02:43:07 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 21 Jul 2023 02:43:07 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
Message-ID: <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>

On Thu, 20 Jul 2023 09:29:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently all the non-static final fields with inline type can be flattened, even if the layout size of the inline type is beyond
> the max flat size specified by `InlineFieldMaxFlatSize`. Please refer to the condition check [1] which decides whether a field
> can be flattened or not.
> 
> Field flattening has two major side effects: atomicity and size. Fields with atomic access limitation or large size that exceeds
> the specified threshold value cannot be flattened. And final fields are special that they are immutable after initialized. So the atomic check for them can be ignored. Hence, 1) for the atomicity free type like the primitive class, the final and non-final fields with such type can be flattened. And 2) for the normal value class that has atomic feature, only the final fields with such type can be flattened. And all kinds of the flattened fields should not exceed the specified max flat size. Please see more details from [1] [2].
> 
> The original condition [1] matches the atomicity check but not the flat size limitation. Promoting the flat size check before all other checks matches the flattening policy and can make the VM option `InlineFieldMaxFlatSize` work for final fields as well.
> 
> This patch also fixed the jtreg crashes involved after the field flattening condition is changed. Those tests fail with setting
> `-XX:+InlineFieldMaxFlatSize=0` by default. The main issue is the non-flattened inline type field is not buffered which is expected to be. The root cause is when parsing `withfield`, the compiler checks whether the field is primitive class type while not its flattening status. Changing to check the flattening status instead can fix the crash.
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L759
> [2] https://mail.openjdk.org/pipermail/valhalla-dev/2023-June/011262.html
> [3] https://mail.openjdk.org/pipermail/valhalla-dev/2023-July/011265.html

src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 661:

> 659:         }
> 660:         if (!too_big_to_flatten &&
> 661:             (!(too_atomic_to_flatten | too_volatile_to_flatten) || fieldinfo.access_flags().is_final())) {

Hi @XiaohongGong , specifications (https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/03-vm-model#flattenable-contexts) also talks about flattening final L descriptor fields of value objects.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1270172225


From xgong at openjdk.org  Fri Jul 21 02:54:58 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 21 Jul 2023 02:54:58 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>
Message-ID: <10Z4f8S3in1e7t--VyvFkDisLgiH2H4HBoeyCPAdp9c=.a759a9ac-06ed-4a54-b662-22cabbf9f96a@github.com>

On Fri, 21 Jul 2023 02:39:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Currently all the non-static final fields with inline type can be flattened, even if the layout size of the inline type is beyond
>> the max flat size specified by `InlineFieldMaxFlatSize`. Please refer to the condition check [1] which decides whether a field
>> can be flattened or not.
>> 
>> Field flattening has two major side effects: atomicity and size. Fields with atomic access limitation or large size that exceeds
>> the specified threshold value cannot be flattened. And final fields are special that they are immutable after initialized. So the atomic check for them can be ignored. Hence, 1) for the atomicity free type like the primitive class, the final and non-final fields with such type can be flattened. And 2) for the normal value class that has atomic feature, only the final fields with such type can be flattened. And all kinds of the flattened fields should not exceed the specified max flat size. Please see more details from [1] [2].
>> 
>> The original condition [1] matches the atomicity check but not the flat size limitation. Promoting the flat size check before all other checks matches the flattening policy and can make the VM option `InlineFieldMaxFlatSize` work for final fields as well.
>> 
>> This patch also fixed the jtreg crashes involved after the field flattening condition is changed. Those tests fail with setting
>> `-XX:+InlineFieldMaxFlatSize=0` by default. The main issue is the non-flattened inline type field is not buffered which is expected to be. The root cause is when parsing `withfield`, the compiler checks whether the field is primitive class type while not its flattening status. Changing to check the flattening status instead can fix the crash.
>> 
>> [1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L759
>> [2] https://mail.openjdk.org/pipermail/valhalla-dev/2023-June/011262.html
>> [3] https://mail.openjdk.org/pipermail/valhalla-dev/2023-July/011265.html
>
> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 661:
> 
>> 659:         }
>> 660:         if (!too_big_to_flatten &&
>> 661:             (!(too_atomic_to_flatten | too_volatile_to_flatten) || fieldinfo.access_flags().is_final())) {
> 
> Hi @XiaohongGong , specifications (https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/03-vm-model#flattenable-contexts) also talks about flattening final L descriptor fields of value classes.

Thanks for pointing out this! I got through of the specifications just now.

Final fields containing value objects, under both L and Q descriptors, can be routinely flattened. Mutable fields containing value objects under Q descriptors can be routinely flattened; mutable fields containing value objects under L descriptors must provide atomic loads and stores, which requires either atomic instructions or an indirection.

Per my understanding, this means:
1. The final fields can be flattened for all L/Q descriptors
2. The non-final fields can be flattened for Q descriptors
3. The non-final fields cannot be flattened for L descriptor value objects due to the atomic feature.


For value objects with many fields, the JVM may decide to fall back to buffering its value in the heap, which is the traditional indirected representation.

And the above means size of the flattened fields should not exceed some value. Right? 

Please correct me if any misunderstanding! Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1270177471


From jbhateja at openjdk.org  Fri Jul 21 03:01:02 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 21 Jul 2023 03:01:02 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <10Z4f8S3in1e7t--VyvFkDisLgiH2H4HBoeyCPAdp9c=.a759a9ac-06ed-4a54-b662-22cabbf9f96a@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>
 <10Z4f8S3in1e7t--VyvFkDisLgiH2H4HBoeyCPAdp9c=.a759a9ac-06ed-4a54-b662-22cabbf9f96a@github.com>
Message-ID: <lPx9vUZMf93A3LJixyPcl-_1qHHwFQ5lYpxJq5J7NEQ=.e68d3bd7-70a1-4c79-96a2-7300f293f9bc@github.com>

On Fri, 21 Jul 2023 02:52:34 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 661:
>> 
>>> 659:         }
>>> 660:         if (!too_big_to_flatten &&
>>> 661:             (!(too_atomic_to_flatten | too_volatile_to_flatten) || fieldinfo.access_flags().is_final())) {
>> 
>> Hi @XiaohongGong , specifications (https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/03-vm-model#flattenable-contexts) also talks about flattening final L descriptor fields of value classes.
>
> Thanks for pointing out this! I got through of the specifications just now.
> 
> Final fields containing value objects, under both L and Q descriptors, can be routinely flattened. Mutable fields containing value objects under Q descriptors can be routinely flattened; mutable fields containing value objects under L descriptors must provide atomic loads and stores, which requires either atomic instructions or an indirection.
> 
> Per my understanding, this means:
> 1. The final fields can be flattened for all L/Q descriptors
> 2. The non-final fields can be flattened for Q descriptors
> 3. The non-final fields cannot be flattened for L descriptor value objects due to the atomic feature.
> 
> 
> For value objects with many fields, the JVM may decide to fall back to buffering its value in the heap, which is the traditional indirected representation.
> 
> And the above means size of the flattened fields should not exceed some value. Right? 
> 
> Please correct me if any misunderstanding! Thanks!

Yes, this is correct, but final fields can be flattened irrespective of sizing constraint.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1270179016


From fparain at openjdk.org  Fri Jul 21 17:14:12 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 21 Jul 2023 17:14:12 GMT
Subject: [lworld] Integrated: 8312417: [lworld] Replacing NULL with nullptr in
 x86 code
In-Reply-To: <6yN1Vfn0SKaZS12Lxm3VgXoIBQVX8z6z8BFaoKMseIg=.3157d4f1-5359-48f1-9bbe-f38ce0c790ad@github.com>
References: <6yN1Vfn0SKaZS12Lxm3VgXoIBQVX8z6z8BFaoKMseIg=.3157d4f1-5359-48f1-9bbe-f38ce0c790ad@github.com>
Message-ID: <6cSAZQLkXc8xhRpJ8vZlXemvfXh-P5XbhthI-QE8pQo=.f912c6d4-60eb-4981-bacd-da41ee289545@github.com>

On Wed, 19 Jul 2023 20:24:54 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Replacing NULL with nullptr in x86 code.
> Builds tested with Mach5 (tier1).

This pull request has now been integrated.

Changeset: c1976b27
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c1976b273f7edad0cee6960ff473504ff615ec43
Stats:     76 lines in 8 files changed: 0 ins; 0 del; 76 mod

8312417: [lworld] Replacing NULL with nullptr in x86 code

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

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


From fparain at openjdk.org  Fri Jul 21 20:33:59 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 21 Jul 2023 20:33:59 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <lPx9vUZMf93A3LJixyPcl-_1qHHwFQ5lYpxJq5J7NEQ=.e68d3bd7-70a1-4c79-96a2-7300f293f9bc@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>
 <10Z4f8S3in1e7t--VyvFkDisLgiH2H4HBoeyCPAdp9c=.a759a9ac-06ed-4a54-b662-22cabbf9f96a@github.com>
 <lPx9vUZMf93A3LJixyPcl-_1qHHwFQ5lYpxJq5J7NEQ=.e68d3bd7-70a1-4c79-96a2-7300f293f9bc@github.com>
Message-ID: <8MlpQQ3HkBZTxCnKlvZe9Jquw_-Q5j6kU8bDB3Klwew=.c3d08434-3c13-4e88-b03b-c71790e3f41a@github.com>

On Fri, 21 Jul 2023 02:56:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thanks for pointing out this! I got through of the specifications just now.
>> 
>> Final fields containing value objects, under both L and Q descriptors, can be routinely flattened. Mutable fields containing value objects under Q descriptors can be routinely flattened; mutable fields containing value objects under L descriptors must provide atomic loads and stores, which requires either atomic instructions or an indirection.
>> 
>> Per my understanding, this means:
>> 1. The final fields can be flattened for all L/Q descriptors
>> 2. The non-final fields can be flattened for Q descriptors
>> 3. The non-final fields cannot be flattened for L descriptor value objects due to the atomic feature.
>> 
>> 
>> For value objects with many fields, the JVM may decide to fall back to buffering its value in the heap, which is the traditional indirected representation.
>> 
>> And the above means size of the flattened fields should not exceed some value. Right? 
>> 
>> Please correct me if any misunderstanding! Thanks!
>
> Yes, this is correct, but final fields can be flattened irrespective of sizing constraint.

The state of Valhalla document is not a specification, but a document about the general design of the Valhalla features in the VM. Currently, fields with L-descriptors are never flattened even the final ones. There are some non-trivial problems to be solved regarding their status before initialization and until we have a good solution to those problems, the safest option is to not flattened them.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1271082739


From jbhateja at openjdk.org  Sat Jul 22 02:10:07 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 22 Jul 2023 02:10:07 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <8MlpQQ3HkBZTxCnKlvZe9Jquw_-Q5j6kU8bDB3Klwew=.c3d08434-3c13-4e88-b03b-c71790e3f41a@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>
 <10Z4f8S3in1e7t--VyvFkDisLgiH2H4HBoeyCPAdp9c=.a759a9ac-06ed-4a54-b662-22cabbf9f96a@github.com>
 <lPx9vUZMf93A3LJixyPcl-_1qHHwFQ5lYpxJq5J7NEQ=.e68d3bd7-70a1-4c79-96a2-7300f293f9bc@github.com>
 <8MlpQQ3HkBZTxCnKlvZe9Jquw_-Q5j6kU8bDB3Klwew=.c3d08434-3c13-4e88-b03b-c71790e3f41a@github.com>
Message-ID: <CYosIiK5wigkUwRYr48kNoN9WN1Qn1WFTkj38ATurMo=.eb0d955e-393a-47cb-8b77-5d3e0c4feaeb@github.com>

On Fri, 21 Jul 2023 20:31:45 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Yes, this is correct, but final fields can be flattened irrespective of sizing constraint.
>
> The state of Valhalla document is not a specification, but a document about the general design of the Valhalla features in the VM. Currently, fields with L-descriptors are never flattened even the final ones. There are some non-trivial problems to be solved regarding their status before initialization and until we have a good solution to those problems, the safest option is to not flattened them.

Thanks @fparain

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1271221457


From jbhateja at openjdk.org  Sat Jul 22 03:25:01 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 22 Jul 2023 03:25:01 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <8MlpQQ3HkBZTxCnKlvZe9Jquw_-Q5j6kU8bDB3Klwew=.c3d08434-3c13-4e88-b03b-c71790e3f41a@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>
 <10Z4f8S3in1e7t--VyvFkDisLgiH2H4HBoeyCPAdp9c=.a759a9ac-06ed-4a54-b662-22cabbf9f96a@github.com>
 <lPx9vUZMf93A3LJixyPcl-_1qHHwFQ5lYpxJq5J7NEQ=.e68d3bd7-70a1-4c79-96a2-7300f293f9bc@github.com>
 <8MlpQQ3HkBZTxCnKlvZe9Jquw_-Q5j6kU8bDB3Klwew=.c3d08434-3c13-4e88-b03b-c71790e3f41a@github.com>
Message-ID: <tU0Xh_HoE72Dwv_u5xRK_FXifBckmccg8pJkH35AX-Y=.9b9a36ff-6f16-4698-975b-b984b14afa38@github.com>

On Fri, 21 Jul 2023 20:31:45 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> The state of Valhalla document is not a specification, but a document about the general design of the Valhalla features in the VM. Currently, fields with L-descriptors are never flattened even the final ones. There are some non-trivial problems to be solved regarding their status before initialization and until we have a good solution to those problems, the safest option is to not flattened them.

null initialized L descriptor final fields may be tricky to handle, being pessimist looks appropriate in this case.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1271236781


From jatin.bhateja at intel.com  Sun Jul 23 17:07:10 2023
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Sun, 23 Jul 2023 17:07:10 +0000
Subject: CFV: New Valhalla Committer: Xiaohong Gong
In-Reply-To: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
References: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
Message-ID: <PH8PR11MB796742898773703798CFDC55E83DA@PH8PR11MB7967.namprd11.prod.outlook.com>

Voting Xiaohong Gong [1] is now closed.

Yes: 3
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination.

Best regards,
Jatin Bhateja

[1] https://mail.openjdk.org/pipermail/valhalla-dev/2023-July/011287.html

________________________________
From: Bhateja, Jatin <jatin.bhateja at intel.com>
Sent: Friday, July 7, 2023 2:29:00 PM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Xiaohong Gong


I hereby nominate Xiaohong Gong (OpenJDK name: xgong) to Valhalla Committer.



Xiaohong is a long-time committer in JDK and Panama Project. She

authored numerous bug fixes and enhancements in C2 and Vector API.



In the context of Valhalla Project, Xiaohong has contributed 5 patches to Valhalla

w.r.t Vector API implementation as value objects and primitive values (most

notably, [3] [4] in lworld branch [7] and [5] [6] in lworld+vector branch [8]).



Votes are due by 2023-07-21 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,

Jatin Bhateja



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



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



[3] https://github.com/openjdk/valhalla/commit/d8e7d2eb3837c6b18a2c88955ae2ab89667889bb

         8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer



[4] https://github.com/openjdk/valhalla/commit/53b40f92b5af2d438a340209c56bcc6e5af0378e

    8309650: [lworld] Fix mismatch inline type issue during method calls



[5] https://github.com/openjdk/valhalla/commit/4ce98c10963a989fd3ecb52ca346f479c0ae181a

    8307715: Integrate VectorMask/Shuffle with value/primitive classes



[6] https://github.com/openjdk/valhalla/commit/bb135138d1314e84bc1371cc9a9d425eafc26c70

    8311080: [lworld+vector] Fix jdk build failures with different options



[7] https://github.com/openjdk/valhalla/tree/lworld



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


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

From xgong at openjdk.org  Mon Jul 24 02:31:05 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 24 Jul 2023 02:31:05 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <tU0Xh_HoE72Dwv_u5xRK_FXifBckmccg8pJkH35AX-Y=.9b9a36ff-6f16-4698-975b-b984b14afa38@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>
 <10Z4f8S3in1e7t--VyvFkDisLgiH2H4HBoeyCPAdp9c=.a759a9ac-06ed-4a54-b662-22cabbf9f96a@github.com>
 <lPx9vUZMf93A3LJixyPcl-_1qHHwFQ5lYpxJq5J7NEQ=.e68d3bd7-70a1-4c79-96a2-7300f293f9bc@github.com>
 <8MlpQQ3HkBZTxCnKlvZe9Jquw_-Q5j6kU8bDB3Klwew=.c3d08434-3c13-4e88-b03b-c71790e3f41a@github.com>
 <tU0Xh_HoE72Dwv_u5xRK_FXifBckmccg8pJkH35AX-Y=.9b9a36ff-6f16-4698-975b-b984b14afa38@github.com>
Message-ID: <XwH8xkB1k6fZx1Hla56jS8jgx_4-mqRSvtcLdgrZ0OU=.12f65eb6-9e3b-45d5-b349-47e434ff385b@github.com>

On Sat, 22 Jul 2023 03:21:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The state of Valhalla document is not a specification, but a document about the general design of the Valhalla features in the VM. Currently, fields with L-descriptors are never flattened even the final ones. There are some non-trivial problems to be solved regarding their status before initialization and until we have a good solution to those problems, the safest option is to not flattened them.
>
>> The state of Valhalla document is not a specification, but a document about the general design of the Valhalla features in the VM. Currently, fields with L-descriptors are never flattened even the final ones. There are some non-trivial problems to be solved regarding their status before initialization and until we have a good solution to those problems, the safest option is to not flattened them.
> 
> null initialized L descriptor final fields may be tricky to handle, being pessimist looks appropriate in this case.

Sounds reasonable to me! It also reminds me that the value object JEP [1] said a value object can only be scalarized when it is on stack or passed through a method call in C2 compiler. 

So maybe changing to `!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten)` is safer for current status. WDYT @fparain  @jatin-bhateja ?
 
[1] https://openjdk.org/jeps/8277163

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1271661731


From jbhateja at openjdk.org  Mon Jul 24 04:02:02 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Jul 2023 04:02:02 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <XwH8xkB1k6fZx1Hla56jS8jgx_4-mqRSvtcLdgrZ0OU=.12f65eb6-9e3b-45d5-b349-47e434ff385b@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <Xrmf5bTRacffBAqv-eq1O0YlteyReizY_xNrlh2FLSA=.094e2ebf-0930-4df1-9c50-8e3d49e4caef@github.com>
 <10Z4f8S3in1e7t--VyvFkDisLgiH2H4HBoeyCPAdp9c=.a759a9ac-06ed-4a54-b662-22cabbf9f96a@github.com>
 <lPx9vUZMf93A3LJixyPcl-_1qHHwFQ5lYpxJq5J7NEQ=.e68d3bd7-70a1-4c79-96a2-7300f293f9bc@github.com>
 <8MlpQQ3HkBZTxCnKlvZe9Jquw_-Q5j6kU8bDB3Klwew=.c3d08434-3c13-4e88-b03b-c71790e3f41a@github.com>
 <tU0Xh_HoE72Dwv_u5xRK_FXifBckmccg8pJkH35AX-Y=.9b9a36ff-6f16-4698-975b-b984b14afa38@github.com>
 <XwH8xkB1k6fZx1Hla56jS8jgx_4-mqRSvtcLdgrZ0OU=.12f65eb6-9e3b-45d5-b349-47e434ff385b@github.com>
Message-ID: <6-nJ43ajP3MEQquVTQcqw-PPrv1yhg4f6WLWYeEh8pE=.8a168226-5351-4ab2-9830-617cecfb15a5@github.com>

On Mon, 24 Jul 2023 02:27:53 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> The state of Valhalla document is not a specification, but a document about the general design of the Valhalla features in the VM. Currently, fields with L-descriptors are never flattened even the final ones. There are some non-trivial problems to be solved regarding their status before initialization and until we have a good solution to those problems, the safest option is to not flattened them.
>> 
>> null initialized L descriptor final fields may be tricky to handle, being pessimist looks appropriate in this case.
>
> Sounds reasonable to me! It also reminds me that the value object JEP [1] said a value object can only be scalarized when it is on stack or passed through a method call in C2 compiler. 
> 
> So maybe changing to `!(too_big_to_flatten | too_atomic_to_flatten | too_volatile_to_flatten)` is safer for current status. WDYT @fparain  @jatin-bhateja ?
>  
> [1] https://openjdk.org/jeps/8277163

Looks fine to me, the case where we are making this check is meant for T_PRIMITIVE_OBJECTS (Q descriptor value object), thus as per above understanding (1 and 2), final constraint can be removed.  Value object anyways carry an L descriptor (T_OBJECT) and hence are currently not being handled.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/888#discussion_r1271706275


From xgong at openjdk.org  Tue Jul 25 09:56:20 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 25 Jul 2023 09:56:20 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
Message-ID: <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>

> Currently all the non-static final fields with inline type can be flattened, even if the layout size of the inline type is beyond
> the max flat size specified by `InlineFieldMaxFlatSize`. Please refer to the condition check [1] which decides whether a field
> can be flattened or not.
> 
> Field flattening has two major side effects: atomicity and size. Fields with atomic access limitation or large size that exceeds
> the specified threshold value cannot be flattened. And final fields are special that they are immutable after initialized. So the atomic check for them can be ignored. Hence, 1) for the atomicity free type like the primitive class, the final and non-final fields with such type can be flattened. And 2) for the normal value class that has atomic feature, only the final fields with such type can be flattened. And all kinds of the flattened fields should not exceed the specified max flat size. Please see more details from [1] [2].
> 
> The original condition [1] matches the atomicity check but not the flat size limitation. Promoting the flat size check before all other checks matches the flattening policy and can make the VM option `InlineFieldMaxFlatSize` work for final fields as well.
> 
> This patch also fixed the jtreg crashes involved after the field flattening condition is changed. Those tests fail with setting
> `-XX:+InlineFieldMaxFlatSize=0` by default. The main issue is the non-flattened inline type field is not buffered which is expected to be. The root cause is when parsing `withfield`, the compiler checks whether the field is primitive class type while not its flattening status. Changing to check the flattening status instead can fix the crash.
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L759
> [2] https://mail.openjdk.org/pipermail/valhalla-dev/2023-June/011262.html
> [3] https://mail.openjdk.org/pipermail/valhalla-dev/2023-July/011265.html

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

  Not flatten L-descriptor value object field even it is final

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/888/files
  - new: https://git.openjdk.org/valhalla/pull/888/files/ac432345..5742e1e8

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

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

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


From jbhateja at openjdk.org  Tue Jul 25 18:16:10 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 25 Jul 2023 18:16:10 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
Message-ID: <QI2Veh8Sh5PfS2FEsZUEO0-e8Rmxx1YWYsLd0wowKN4=.8c487bed-140d-44cc-af18-7c98ff1fd492@github.com>

On Tue, 25 Jul 2023 09:56:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently all the non-static final fields with inline type can be flattened, even if the layout size of the inline type is beyond
>> the max flat size specified by `InlineFieldMaxFlatSize`. Please refer to the condition check [1] which decides whether a field
>> can be flattened or not.
>> 
>> Field flattening has two major side effects: atomicity and size. Fields with atomic access limitation or large size that exceeds
>> the specified threshold value cannot be flattened. And final fields are special that they are immutable after initialized. So the atomic check for them can be ignored. Hence, 1) for the atomicity free type like the primitive class, the final and non-final fields with such type can be flattened. And 2) for the normal value class that has atomic feature, only the final fields with such type can be flattened. And all kinds of the flattened fields should not exceed the specified max flat size. Please see more details from [1] [2].
>> 
>> The original condition [1] matches the atomicity check but not the flat size limitation. Promoting the flat size check before all other checks matches the flattening policy and can make the VM option `InlineFieldMaxFlatSize` work for final fields as well.
>> 
>> This patch also fixed the jtreg crashes involved after the field flattening condition is changed. Those tests fail with setting
>> `-XX:+InlineFieldMaxFlatSize=0` by default. The main issue is the non-flattened inline type field is not buffered which is expected to be. The root cause is when parsing `withfield`, the compiler checks whether the field is primitive class type while not its flattening status. Changing to check the flattening status instead can fix the crash.
>> 
>> [1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L759
>> [2] https://mail.openjdk.org/pipermail/valhalla-dev/2023-June/011262.html
>> [3] https://mail.openjdk.org/pipermail/valhalla-dev/2023-July/011265.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not flatten L-descriptor value object field even it is final

LGTM

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

Marked as reviewed by jbhateja (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/888#pullrequestreview-1546069697


From vromero at openjdk.org  Tue Jul 25 20:46:09 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 25 Jul 2023 20:46:09 GMT
Subject: RFR: 8313080: [lw5] javac parser is not accepting some array types
 with nullness markers
Message-ID: <SoyUdSt0LEh055vHIn8i1CWKbIXMTEgTrm8a9Dryp1g=.ed04c917-6b24-448f-a2e0-6042be74288f@github.com>

Code like:


class Test {
    void m(Test[][] t1, Test[][][] t2) {
        Test[][]! l1 = (Test[][]!) t1;
        Test[][][]! l2 = (Test[][][]!) t2;

        Test[]![]! l3 = (Test[]![]!) t1;
        Test[]![]![]! l4 = (Test[]![]![]!) t2;
    }
}


is being rejected by javac. Basically the compiler can't deal with nullness markers interleaved in array type declarations. This patch is fixing this issue.

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

Commit messages:
 - 8313080: [lw5] javac parser is not accepting some array types with nullness markers

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

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


From vromero at openjdk.org  Tue Jul 25 22:14:59 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 25 Jul 2023 22:14:59 GMT
Subject: Integrated: 8313080: [lw5] javac parser is not accepting some array
 types with nullness markers
In-Reply-To: <SoyUdSt0LEh055vHIn8i1CWKbIXMTEgTrm8a9Dryp1g=.ed04c917-6b24-448f-a2e0-6042be74288f@github.com>
References: <SoyUdSt0LEh055vHIn8i1CWKbIXMTEgTrm8a9Dryp1g=.ed04c917-6b24-448f-a2e0-6042be74288f@github.com>
Message-ID: <vD4iZt8kbQRp9P3F1QSmZsvcRniMXazSa6ag_nUWO8Y=.0dfc5f3f-67c7-45c6-8e96-27bbcbf2063f@github.com>

On Tue, 25 Jul 2023 20:40:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Code like:
> 
> 
> class Test {
>     void m(Test[][] t1, Test[][][] t2) {
>         Test[][]! l1 = (Test[][]!) t1;
>         Test[][][]! l2 = (Test[][][]!) t2;
> 
>         Test[]![]! l3 = (Test[]![]!) t1;
>         Test[]![]![]! l4 = (Test[]![]![]!) t2;
>     }
> }
> 
> 
> is being rejected by javac. Basically the compiler can't deal with nullness markers interleaved in array type declarations. This patch is fixing this issue.

This pull request has now been integrated.

Changeset: 916fbb61
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/916fbb618a3a271b70a8ad95124d78492bced02d
Stats:     53 lines in 3 files changed: 49 ins; 0 del; 4 mod

8313080: [lw5] javac parser is not accepting some array types with nullness markers

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

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


From xgong at openjdk.org  Thu Jul 27 01:47:58 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 27 Jul 2023 01:47:58 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
Message-ID: <HPe7YuBhYiHdGg-1vNtK6pKlhakQNMX5X6kxD-wXo_A=.620fda8d-5abd-49c4-9b03-1d0b7219a295@github.com>

On Tue, 25 Jul 2023 09:56:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently all the non-static final fields with inline type can be flattened, even if the layout size of the inline type is beyond
>> the max flat size specified by `InlineFieldMaxFlatSize`. Please refer to the condition check [1] which decides whether a field
>> can be flattened or not.
>> 
>> Field flattening has two major side effects: atomicity and size. Fields with atomic access limitation or large size that exceeds
>> the specified threshold value cannot be flattened. And final fields are special that they are immutable after initialized. So the atomic check for them can be ignored. Hence, 1) for the atomicity free type like the primitive class, the final and non-final fields with such type can be flattened. And 2) for the normal value class that has atomic feature, only the final fields with such type can be flattened. And all kinds of the flattened fields should not exceed the specified max flat size. Please see more details from [1] [2].
>> 
>> The original condition [1] matches the atomicity check but not the flat size limitation. Promoting the flat size check before all other checks matches the flattening policy and can make the VM option `InlineFieldMaxFlatSize` work for final fields as well.
>> 
>> This patch also fixed the jtreg crashes involved after the field flattening condition is changed. Those tests fail with setting
>> `-XX:+InlineFieldMaxFlatSize=0` by default. The main issue is the non-flattened inline type field is not buffered which is expected to be. The root cause is when parsing `withfield`, the compiler checks whether the field is primitive class type while not its flattening status. Changing to check the flattening status instead can fix the crash.
>> 
>> [1] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/classfile/fieldLayoutBuilder.cpp#L759
>> [2] https://mail.openjdk.org/pipermail/valhalla-dev/2023-June/011262.html
>> [3] https://mail.openjdk.org/pipermail/valhalla-dev/2023-July/011265.html
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not flatten L-descriptor value object field even it is final

Hi @fparain , could you please help check whether the latest change is good to go in? Thanks a lot!

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1652792356


From frederic.parain at oracle.com  Thu Jul 27 19:45:03 2023
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 27 Jul 2023 15:45:03 -0400
Subject: CFV: New Valhalla Committer: Xiaohong Gong
In-Reply-To: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
References: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
Message-ID: <6204414d-e69d-5451-33be-12f2fd8ed640@oracle.com>

Vote: yes

Fred

On 7/7/23 4:59 AM, Bhateja, Jatin wrote:
> I hereby nominate Xiaohong Gong (OpenJDK name: xgong) to Valhalla 
> Committer.
> Xiaohong is a long-time committer in JDK and Panama Project. She
> authored numerous bug fixes and enhancements in C2 and Vector API.
> In the context of Valhalla Project, Xiaohong has contributed 5 
> patchesto Valhalla
> w.r.t Vector API implementation as value objects and primitive values 
> (most
> notably, [3] [4]in lworld branch [7] and [5] [6] in lworld+vector 
> branch [8]).
> Votes are due by 2023-07-21 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,
> Jatin Bhateja
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> [3] 
> https://github.com/openjdk/valhalla/commit/d8e7d2eb3837c6b18a2c88955ae2ab89667889bb
> 8303416: [lworld] Fix JVM crash at Unsafe_FinishPrivateBuffer
> [4] 
> https://github.com/openjdk/valhalla/commit/53b40f92b5af2d438a340209c56bcc6e5af0378e
> 8309650: [lworld] Fix mismatch inline type issue during method calls
> [5] 
> https://github.com/openjdk/valhalla/commit/4ce98c10963a989fd3ecb52ca346f479c0ae181a
> 8307715: Integrate VectorMask/Shuffle with value/primitive classes
> [6] 
> https://github.com/openjdk/valhalla/commit/bb135138d1314e84bc1371cc9a9d425eafc26c70
> 8311080: [lworld+vector] Fix jdk build failures with different options
> [7] https://github.com/openjdk/valhalla/tree/lworld
> [8] https://github.com/openjdk/valhalla/tree/lworld+vector
>


From dsimms at openjdk.org  Fri Jul 28 07:25:13 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 28 Jul 2023 07:25:13 GMT
Subject: [lworld] RFR: 8309344: [lworld] Initial ZGenerational fixes and
 support
Message-ID: <E-htgOxMVNPWSvQLRYIel-kVlBB0cOF6MNlSPv8Wp0A=.556734c1-8be4-416b-81fa-af985add9c15@github.com>

* BarrierSet typo
* Segmented array initialization disabled
* Sanity testing with InlineOops

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

Commit messages:
 - 8309344: [lworld] Initial ZGenerational fixes and support

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

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


From dsimms at openjdk.org  Mon Jul 31 09:41:10 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 31 Jul 2023 09:41:10 GMT
Subject: [lworld] Integrated: 8309344: [lworld] Initial ZGenerational fixes and
 support
In-Reply-To: <E-htgOxMVNPWSvQLRYIel-kVlBB0cOF6MNlSPv8Wp0A=.556734c1-8be4-416b-81fa-af985add9c15@github.com>
References: <E-htgOxMVNPWSvQLRYIel-kVlBB0cOF6MNlSPv8Wp0A=.556734c1-8be4-416b-81fa-af985add9c15@github.com>
Message-ID: <H4WO9qhfLYYfECK7eCiz4fuKNyrydwDd-HSbm-u1-EQ=.3187a831-44fa-4627-91c4-f8ce9e3419f8@github.com>

On Fri, 28 Jul 2023 07:18:53 GMT, David Simms <dsimms at openjdk.org> wrote:

> * BarrierSet typo
> * Segmented array initialization disabled
> * Sanity testing with InlineOops

This pull request has now been integrated.

Changeset: 48040955
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/48040955ae0dc71023c4e58ae41051b4d630a2b4
Stats:     21 lines in 3 files changed: 18 ins; 0 del; 3 mod

8309344: [lworld] Initial ZGenerational fixes and support

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

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


From vromero at openjdk.org  Mon Jul 31 16:26:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 31 Jul 2023 16:26:25 GMT
Subject: RFR: experiment: generate Q descriptors for lw5 code
Message-ID: <AJ6nUvuhdqihakE1HGkp-H6JEK8zVhPrvh4KwLTyECE=.8f8cc450-f72d-4feb-815e-d69a1c133d98@github.com>

This patch allows the generation of Q descriptors for lw5 code. This is just experimental, and the support could be removed at any time without notice

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

Commit messages:
 - Update ValueConstructorRef.java
 - Update SideEffectTest.java
 - Update QualifiedSuperCtor.java
 - reusing existing primitive classes tests
 - Merge branch 'lw5' into generate.qdescriptors
 - adding some tests to support Q descriptors experiment
 - additional improvements
 - Merge branch 'lw5' into generate.qdescriptors
 - some refactorings
 - emit Q descriptors, experiments

Changes: https://git.openjdk.org/valhalla/pull/891/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=891&range=00
  Stats: 1484 lines in 155 files changed: 829 ins; 260 del; 395 mod
  Patch: https://git.openjdk.org/valhalla/pull/891.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/891/head:pull/891

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


From vromero at openjdk.org  Mon Jul 31 16:31:19 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 31 Jul 2023 16:31:19 GMT
Subject: Integrated: experiment: generate Q descriptors for lw5 code
In-Reply-To: <AJ6nUvuhdqihakE1HGkp-H6JEK8zVhPrvh4KwLTyECE=.8f8cc450-f72d-4feb-815e-d69a1c133d98@github.com>
References: <AJ6nUvuhdqihakE1HGkp-H6JEK8zVhPrvh4KwLTyECE=.8f8cc450-f72d-4feb-815e-d69a1c133d98@github.com>
Message-ID: <nXJjHXlWo_UNwq141yx6kLHh08IqusHg4ULoHccmEFY=.a73c4cc8-c8a1-4f81-9e76-6ba0756966fa@github.com>

On Mon, 31 Jul 2023 16:08:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This patch allows the generation of Q descriptors for lw5 code. This is just experimental, and the support could be removed at any time without notice

This pull request has now been integrated.

Changeset: 97b5c846
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/97b5c8461544379d74858ef8845ba3e8327fa848
Stats:     1484 lines in 155 files changed: 829 ins; 260 del; 395 mod

experiment: generate Q descriptors for lw5 code

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

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


From roger.riggs at oracle.com  Mon Jul 31 19:39:38 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 31 Jul 2023 15:39:38 -0400
Subject: CFV: New Valhalla Committer: Xiaohong Gong
In-Reply-To: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
References: <PH8PR11MB7967F0D90FA892D24C74FAA3E82DA@PH8PR11MB7967.namprd11.prod.outlook.com>
Message-ID: <ed80acb1-399d-4015-f88a-5abc12524ad0@oracle.com>

Vote: Yes

On 7/7/23 4:59 AM, Bhateja, Jatin wrote:
> I hereby nominate Xiaohong Gong (OpenJDK name: xgong) to Valhalla 
> Committer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230731/cdcc4b53/attachment.htm>

From vromero at openjdk.org  Mon Jul 31 21:30:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 31 Jul 2023 21:30:07 GMT
Subject: RFR: Merge lworld
Message-ID: <0dwfIu-_RI9otrsCsS1MzNkE6R5GJR_QJQgcF5Ansso=.7ca0cb04-54b0-4d16-82e5-2a110929ab46@github.com>

Merge branch 'lworld' into lw5

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

Commit messages:
 - Merge branch 'lworld' into merge_with_lworld
 - 8309344: [lworld] Initial ZGenerational fixes and support
 - 8312417: [lworld] Replacing NULL with nullptr in x86 code
 - 8312231: Replacing NULL with nullptr in shared code
 - 8311383: [lworld] Restoring inline class mirrors with CDS.
 - 8310651: [lworld] ValueConstantDesc fails after merge with jdk-21+25
 - 8309357: [lworld] CDS is broken with InlineKlasses after the merge

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/valhalla/pull/892/files
  Stats: 449 lines in 80 files changed: 43 ins; 10 del; 396 mod
  Patch: https://git.openjdk.org/valhalla/pull/892.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/892/head:pull/892

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


From vromero at openjdk.org  Mon Jul 31 21:49:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 31 Jul 2023 21:49:08 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <0dwfIu-_RI9otrsCsS1MzNkE6R5GJR_QJQgcF5Ansso=.7ca0cb04-54b0-4d16-82e5-2a110929ab46@github.com>
References: <0dwfIu-_RI9otrsCsS1MzNkE6R5GJR_QJQgcF5Ansso=.7ca0cb04-54b0-4d16-82e5-2a110929ab46@github.com>
Message-ID: <yIcnd0H7JpDF_o542awOBJS_8DsIvfw8a50fi3QTbtM=.b1b0627d-da60-450d-b699-491dc1b67de4@github.com>

On Mon, 31 Jul 2023 21:24:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5

This pull request has now been integrated.

Changeset: e24e94c3
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e24e94c36b3547eb76082cbbc4bfb800ee75b69a
Stats:     449 lines in 80 files changed: 43 ins; 10 del; 396 mod

Merge lworld

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

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