From jbhateja at openjdk.org  Thu Jun  1 15:27:40 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 1 Jun 2023 15:27:40 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16
 scalar operations.
In-Reply-To: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
References: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
Message-ID: <cYTZUt8y6eCuYfx1oSD7MC1bOeKaYKHYNM1jKoesWlo=.54acc1e1-ddd1-471c-9b39-ab8202ceda29@github.com>

On Mon, 22 May 2023 17:07:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Starting with 4th Generation Xeon, Intel has made extensive extensions to existing ISA to support 16 bit scalar and vector floating point operations based on IEEE 754 FP16 format.
> 
> We plan to support this in multiple stages spanning across Java side definition of Float16 type, scalar operation and finally SLP vectorization support.
> 
> This patch adds  minimal Java and Compiler side support for one API Float16.add.
> 
> Following is the gist of changes introduced with the patch :-
> 
> - Minimal implementation of Float16 primitive class supporting one operation (Float16.add)
> - X86 AVX512-FP16 feature detection at VM startup.
> - C2 IR and Inline expander changes for Float16.add API.
> - FP16 constant folding handling.
> - Backend support : Instruction selection patterns and assembler support.
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

> ### Webrevs
> * 00: [Full](https://webrevs.openjdk.org/?repo=valhalla&pr=848&range=00) ([98d8ea1f](https://git.openjdk.org/valhalla/pull/848/files/98d8ea1f207eca16d1f8bf02f55115ecbea16f15))

![image](https://github.com/openjdk/valhalla/assets/59989778/fa9438b5-f893-4a61-a5da-4eed6de32a27)

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

PR Comment: https://git.openjdk.org/valhalla/pull/848#issuecomment-1572262949


From vladimir.x.ivanov at oracle.com  Thu Jun  1 17:24:21 2023
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 1 Jun 2023 10:24:21 -0700
Subject: Result: New Valhalla Committer: Jatin Bhateja
Message-ID: <1d245509-751b-ae51-2eb5-ff44b96dfcf6@oracle.com>

Voting for Jatin Bhateja [1] is now closed.

Yes: 9
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Best regards,
Vladimir Ivanov

[1] https://mail.openjdk.org/pipermail/valhalla-dev/2023-May/011077.html


From xgong at openjdk.org  Fri Jun  2 05:47:39 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 2 Jun 2023 05:47:39 GMT
Subject: [lworld+vector] Integrated: 8307715: Integrate VectorMask/Shuffle with
 value/primitive classes
In-Reply-To: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
References: <oIHFo2Z1MZL1h48aYSF_X3r1LGFRGS0PdFNwfDa5pR4=.2a5493b9-d419-43ec-af41-3505535a4e7b@github.com>
Message-ID: <wpgzVFhtVTvkxZQwBjxVoa5-In4bEFEnUi5-YBCGFds=.c9740400-3773-4a9b-9996-703458d38244@github.com>

On Tue, 16 May 2023 04:08:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 4ce98c10
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4ce98c10963a989fd3ecb52ca346f479c0ae181a
Stats:     5514 lines in 54 files changed: 869 ins; 2556 del; 2089 mod

8307715: Integrate VectorMask/Shuffle with value/primitive classes

Reviewed-by: jbhateja

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

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


From dsimms at openjdk.org  Fri Jun  2 11:17:42 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 2 Jun 2023 11:17:42 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <g6jhONU1kqbOqzAou1pGBC-WHVSzPFHl60Eb8K5UzZM=.2f23ac6e-7167-4751-bef7-6b49d2f6d3b5@github.com>
References: <g6jhONU1kqbOqzAou1pGBC-WHVSzPFHl60Eb8K5UzZM=.2f23ac6e-7167-4751-bef7-6b49d2f6d3b5@github.com>
Message-ID: <bNCNYzDwtRwenEqb2XOrRzeRmSWlqdqb2w58jbYiPhY=.cbb4d9e3-3090-4ec7-a03b-68d72d59432c@github.com>

On Wed, 31 May 2023 13:34:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> * jdk-21+21
> * jdk-21+22
> * jdk-21+23
> * jdk-21+24

This pull request has now been integrated.

Changeset: 46bf70ae
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/46bf70ae4c6e718f9bc835d510d0d645920e834d
Stats:     190826 lines in 3289 files changed: 137112 ins; 27649 del; 26065 mod

Merge jdk

Merge jdk-21+21, jdk-21+22, jdk-21+23 and jdk-21+24

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

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


From thartmann at openjdk.org  Fri Jun  2 12:42:47 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 2 Jun 2023 12:42:47 GMT
Subject: [lworld] RFR: 8308756: [lworld]
 compiler/ciReplay/TestInliningProtectionDomain.java fails because CDS is
 disabled
Message-ID: <orTC36JxBTPngAH65LqhigwAIcxcR2HvaAchG8MStWE=.5cd1c188-d824-462c-bba5-847cbc19f929@github.com>

I added `-XX:-InlineTypeReturnedAsFields` as a temporary workaround with [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) until [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) is fixed but that disables CDS because of a flag mismatch (see [JDK-8272290](https://bugs.openjdk.org/browse/JDK-8272290)). The test now fails due to mainline issue [JDK-8277301](https://bugs.openjdk.org/browse/JDK-8277301) which we seem to reliably trigger after the recent merge.

Let's just disable the problematic sub-test completely until [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) is fixed.

Thanks,
Tobias

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

Commit messages:
 - 8308756: [lworld] compiler/ciReplay/TestInliningProtectionDomain.java fails because CDS is disabled

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

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


From thartmann at openjdk.org  Fri Jun  2 13:19:28 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 2 Jun 2023 13:19:28 GMT
Subject: [lworld] Integrated: 8308756: [lworld]
 compiler/ciReplay/TestInliningProtectionDomain.java fails because CDS is
 disabled
In-Reply-To: <orTC36JxBTPngAH65LqhigwAIcxcR2HvaAchG8MStWE=.5cd1c188-d824-462c-bba5-847cbc19f929@github.com>
References: <orTC36JxBTPngAH65LqhigwAIcxcR2HvaAchG8MStWE=.5cd1c188-d824-462c-bba5-847cbc19f929@github.com>
Message-ID: <syuR3KLxBMGcji2WxY_4NNy61U6aJIjlezyVCgnYJiA=.7f22346f-0c8b-46ee-98cd-e82e45d52ebd@github.com>

On Fri, 2 Jun 2023 12:36:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I added `-XX:-InlineTypeReturnedAsFields` as a temporary workaround with [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) until [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) is fixed but that disables CDS because of a flag mismatch (see [JDK-8272290](https://bugs.openjdk.org/browse/JDK-8272290)). The test now fails due to mainline issue [JDK-8277301](https://bugs.openjdk.org/browse/JDK-8277301) which we seem to reliably trigger after the recent merge.
> 
> Let's just disable the problematic sub-test completely until [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) is fixed.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8308756: [lworld] compiler/ciReplay/TestInliningProtectionDomain.java fails because CDS is disabled

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

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


From thartmann at openjdk.org  Fri Jun  2 13:23:05 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 2 Jun 2023 13:23:05 GMT
Subject: [lworld] Integrated: 8309353: [lworld] C2 compilations fails with
 assert(false) failed: type flow analysis failed for OSR compilation
Message-ID: <JMoxAG9SAS6bejPtepO6Dj9jK686KsN_IZDPWearwnA=.5df056ad-7066-491b-aba8-ef5f146c1c8e@github.com>

With [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) we added a trap at calls to methods with unloaded return type in C2 until [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) is fixed. This can lead to a rare and harmless compilation bailout   for OSR compilations which triggers an assert now that we merged in [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) from mainline. Let's simply disable that assert again until [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) is fixed.

Thanks,
Tobias

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

Commit messages:
 - 8309353: [lworld] C2 compilations fails with assert(false) failed: type flow analysis failed for OSR compilation

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

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


From thartmann at openjdk.org  Fri Jun  2 13:23:06 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 2 Jun 2023 13:23:06 GMT
Subject: [lworld] Integrated: 8309353: [lworld] C2 compilations fails with
 assert(false) failed: type flow analysis failed for OSR compilation
In-Reply-To: <JMoxAG9SAS6bejPtepO6Dj9jK686KsN_IZDPWearwnA=.5df056ad-7066-491b-aba8-ef5f146c1c8e@github.com>
References: <JMoxAG9SAS6bejPtepO6Dj9jK686KsN_IZDPWearwnA=.5df056ad-7066-491b-aba8-ef5f146c1c8e@github.com>
Message-ID: <5lciihayzKn72aGEuQRyHSsFU-XiCwLQOWGOaLGyNWo=.687e5451-9d91-4cf1-a0f2-f8a81ca91192@github.com>

On Fri, 2 Jun 2023 13:13:56 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> With [JDK-8301007](https://bugs.openjdk.org/browse/JDK-8301007) we added a trap at calls to methods with unloaded return type in C2 until [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) is fixed. This can lead to a rare and harmless compilation bailout   for OSR compilations which triggers an assert now that we merged in [JDK-8303951](https://bugs.openjdk.org/browse/JDK-8303951) from mainline. Let's simply disable that assert again until [JDK-8284443](https://bugs.openjdk.org/browse/JDK-8284443) is fixed.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8309353: [lworld] C2 compilations fails with assert(false) failed: type flow analysis failed for OSR compilation

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

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


From thartmann at openjdk.org  Mon Jun  5 12:37:47 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 5 Jun 2023 12:37:47 GMT
Subject: [lworld] RFR: 8309466: [lworld] Problemlist HelloDynamicInlineClass
 until JDK-8309357 is fixed
Message-ID: <l-feDQLwwaNYit3jjAbTtABihOIKOLBAk607gkUrgng=.a5e6511d-ea18-4158-9738-2362d0992b4d@github.com>

Putting the test on the problem list until [JDK-8309357](https://bugs.openjdk.org/browse/JDK-8309357) is fixed.

Thanks,
Tobias

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

Commit messages:
 - 8309466: [lworld] Problemlist HelloDynamicInlineClass until JDK-8309357 is fixed

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

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


From thartmann at openjdk.org  Mon Jun  5 12:43:32 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 5 Jun 2023 12:43:32 GMT
Subject: [lworld] RFR: 8309466: [lworld] Problemlist
 HelloDynamicInlineClass until JDK-8309357 is fixed [v2]
In-Reply-To: <l-feDQLwwaNYit3jjAbTtABihOIKOLBAk607gkUrgng=.a5e6511d-ea18-4158-9738-2362d0992b4d@github.com>
References: <l-feDQLwwaNYit3jjAbTtABihOIKOLBAk607gkUrgng=.a5e6511d-ea18-4158-9738-2362d0992b4d@github.com>
Message-ID: <z6ZkR08mCWuXx_2gmlSCFxy85BzbY9h31glphI-81as=.7105b28f-1670-4c3a-8ef6-b8b15221acc4@github.com>

> Putting the tests on the problem list until [JDK-8309357](https://bugs.openjdk.org/browse/JDK-8309357) is fixed.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Added test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/858/files
  - new: https://git.openjdk.org/valhalla/pull/858/files/9feaa657..90ff38e6

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

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

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


From thartmann at openjdk.org  Mon Jun  5 13:14:35 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 5 Jun 2023 13:14:35 GMT
Subject: [lworld] Integrated: 8309466: [lworld] Problem list CDS tests until
 JDK-8309357 is fixed
In-Reply-To: <l-feDQLwwaNYit3jjAbTtABihOIKOLBAk607gkUrgng=.a5e6511d-ea18-4158-9738-2362d0992b4d@github.com>
References: <l-feDQLwwaNYit3jjAbTtABihOIKOLBAk607gkUrgng=.a5e6511d-ea18-4158-9738-2362d0992b4d@github.com>
Message-ID: <XqWF1nGgUWVFVN6H7ZUTdKQnD1KloLAHBaK0uqeUJxE=.040117c5-b754-4ae1-9acf-6059737363f0@github.com>

On Mon, 5 Jun 2023 12:31:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Putting the tests on the problem list until [JDK-8309357](https://bugs.openjdk.org/browse/JDK-8309357) is fixed.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8309466: [lworld] Problem list CDS tests until JDK-8309357 is fixed

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

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


From xgong at openjdk.org  Tue Jun  6 09:12:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 6 Jun 2023 09:12:27 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <IoBaXno_ojU_8netCa5sMa7mIiX5LOJbS7-csjyVmu8=.6ff19e64-5911-407f-9a34-1fd560c5430e@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
 <IoBaXno_ojU_8netCa5sMa7mIiX5LOJbS7-csjyVmu8=.6ff19e64-5911-407f-9a34-1fd560c5430e@github.com>
Message-ID: <P6TjvWkLnXQU1Jw6bxjMJgzNqLXsnppKEy1G7AiA1wA=.ca71627f-3fd8-4056-b588-edab4f8c97b9@github.com>

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

>> Merge from lworld into lworld+vector.
>> 
>> Please review and approve.
>> 
>> Best Regards,
>> Jatin
>
> Hi @TobiHartmann ,
> Can you kindly sponsor the patch.
> 
> Best Regards,
> Jatin

Hi @jatin-bhateja , could you please rebase this PR and resolve the conflicts, so that we can let this merge in as soon as possible? Thanks! I also tried to applied this merge PR and resolve the conflicts locally. But I met new jtreg regression, and I think we can fix it with followed patches after this merge is in. WDYT?

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

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


From dsimms at openjdk.org  Wed Jun  7 07:10:33 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 7 Jun 2023 07:10:33 GMT
Subject: [lworld] Integrated: 8309586: [lworld] Feature version post merge
 doesn't match CheckFeatureGate1.java & CheckFeatureGate2.java
Message-ID: <8i2wOu2jcU2o3Lmm-ssN3rf_JVgnBt1roq6HA7k7kxg=.2a5394b2-5e56-40dd-bfcd-dd4e0dc260f8@github.com>

Tweak expected output version

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

Commit messages:
 - 8309586: [lworld] Feature version post merge doesn't match CheckFeatureGate1.java & CheckFeatureGate2.java

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

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


From dsimms at openjdk.org  Wed Jun  7 07:10:34 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 7 Jun 2023 07:10:34 GMT
Subject: [lworld] Integrated: 8309586: [lworld] Feature version post merge
 doesn't match CheckFeatureGate1.java & CheckFeatureGate2.java
In-Reply-To: <8i2wOu2jcU2o3Lmm-ssN3rf_JVgnBt1roq6HA7k7kxg=.2a5394b2-5e56-40dd-bfcd-dd4e0dc260f8@github.com>
References: <8i2wOu2jcU2o3Lmm-ssN3rf_JVgnBt1roq6HA7k7kxg=.2a5394b2-5e56-40dd-bfcd-dd4e0dc260f8@github.com>
Message-ID: <ms1nGtxsX_tVPcBiRmgBRJA5As9_6SHzf1YWKdYqGXI=.fb970115-aac5-4a2f-a0eb-b8f719a96028@github.com>

On Wed, 7 Jun 2023 07:02:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Tweak expected output version

This pull request has now been integrated.

Changeset: 94636f4c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/94636f4c8282474e58ea8229711102e104966257
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8309586: [lworld] Feature version post merge doesn't match CheckFeatureGate1.java & CheckFeatureGate2.java

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

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


From jbhateja at openjdk.org  Thu Jun  8 12:32:17 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 8 Jun 2023 12:32:17 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <IoBaXno_ojU_8netCa5sMa7mIiX5LOJbS7-csjyVmu8=.6ff19e64-5911-407f-9a34-1fd560c5430e@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
 <IoBaXno_ojU_8netCa5sMa7mIiX5LOJbS7-csjyVmu8=.6ff19e64-5911-407f-9a34-1fd560c5430e@github.com>
Message-ID: <BzPWEt3Wkk9v5GtW61LMjtihXsjs7ke-Ryn1uWIdK0Y=.830e2be4-fa9b-4169-aab1-0c8f0dacc873@github.com>

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

>> Merge from lworld into lworld+vector.
>> 
>> Please review and approve.
>> 
>> Best Regards,
>> Jatin
>
> Hi @TobiHartmann ,
> Can you kindly sponsor the patch.
> 
> Best Regards,
> Jatin

> Hi @jatin-bhateja , could you please rebase this PR and resolve the conflicts, so that we can let this merge in as soon as possible? Thanks! I also tried to applied this merge PR and resolve the conflicts locally. But I met new jtreg regression, and I think we can fix it with followed patches after this merge is in. WDYT?

Hi @XiaohongGong ,

I am in process of rebasing this merge with latest lworld.
Will update, as discussed any further validations to be done on the merge branch with latest lworld code on top of your recently merged changes.

Best Regards,
Jatin

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

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


From xgong at openjdk.org  Fri Jun  9 01:28:12 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 9 Jun 2023 01:28:12 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <BzPWEt3Wkk9v5GtW61LMjtihXsjs7ke-Ryn1uWIdK0Y=.830e2be4-fa9b-4169-aab1-0c8f0dacc873@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
 <IoBaXno_ojU_8netCa5sMa7mIiX5LOJbS7-csjyVmu8=.6ff19e64-5911-407f-9a34-1fd560c5430e@github.com>
 <BzPWEt3Wkk9v5GtW61LMjtihXsjs7ke-Ryn1uWIdK0Y=.830e2be4-fa9b-4169-aab1-0c8f0dacc873@github.com>
Message-ID: <yThlk4wND9einvzkyk7G_K9qCD_GN1XXKXiO4V26JWw=.70cce37f-7cf1-405b-aa6b-c9d14925bc6f@github.com>

On Thu, 8 Jun 2023 12:29:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Hi @jatin-bhateja , could you please rebase this PR and resolve the conflicts, so that we can let this merge in as soon as possible? Thanks! I also tried to applied this merge PR and resolve the conflicts locally. But I met new jtreg regression, and I think we can fix it with followed patches after this merge is in. WDYT?
> 
> Hi @XiaohongGong ,
> 
> I am in process of rebasing this merge with latest lworld. Will update, as discussed any further validations to be done on the merge branch with latest lworld code on top of your recently merged changes.
> 
> Best Regards, Jatin

Thanks for the updating! I guess there will be too more conflicts with latest lword branch, like the big `VectorShuffle` refactory. I was planning to do another merge after this one, with the changes to the `VectorShuffle`.  But I'm also fine rebasing this one to the latest lworld. Thanks for doing this!

Best Regards,
Xiaohong

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

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


From xgong at openjdk.org  Fri Jun  9 08:37:25 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 9 Jun 2023 08:37:25 GMT
Subject: [lworld] RFR: 8309650: [lworld] Fix mismatch inline type issue during
 method calls
Message-ID: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>

JVM crashes with following assertion failure when running the new added
 test case (i.e. `compiler/valhalla/inlinetypes/TestCastMismatch.java`):


A fatal error has been detected by the Java Runtime Environment:

 Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/graphKit.cpp:3414), pid=1533674, tid=1533690
 assert(stopped() || !toop->is_inlinetypeptr() || obj->is_InlineType()) failed: should have been scalarized

 Problematic frame:
 V [[libjvm.so](http://libjvm.so/)+0xd2c070] GraphKit::gen_checkcast(Node*, Node*, Node**, bool)+0x46c


The failure happens when compiler knows the type of the `checkcast`
 input is a value/primitive class, while the input node is not an
 `InlineTypeNode`. Note that `InlineTypeNode` is use to represent each
 value/primitive class instance.

In the test case, the input of cast is a method call. And from the
 method declaration, the return type of this method is an abstract class
 whose concrete subclass is a value class. From the method signature,
 the compiler knows the return type is not a value class. Hence, when
 it handles the return result of this method call, no `InlineTypeNode`
 is generated. But when compiler handles the `checkcast` bytecode, it
 checks the speculative type of the input, which is actually the concrete
 class of the instance. In this case, it is the value class. So compiler
 expects the input node is an `InlineTypeNode`.

To fix this issue, the compiler has to use the consistent type system
 for different routines. This patch changes to use the speculative
 type of the method call as well when handling the call's return result.
 With this change, an `InlineTypeNode` is generated for this case after
 the call, and the assertion pass.

Verified with `hotspot::hotspot_all, jdk::tier1,tier2,tier3, langtool::tier1`

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

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

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

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


From dsimms at openjdk.org  Fri Jun  9 17:34:04 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 9 Jun 2023 17:34:04 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <tvZ25CjksVq6n6v98gzmuNs75rVO2H5Fwzv-_Unfhko=.80451911-6699-42d0-9f82-9090ee36c1b4@github.com>

* jdk-21+25
* jdk-22+0

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

Commit messages:
 - Logical merge fixes
 - Merge tag 'jdk-22+0' into lworld_merge_jdk_incr_from_21_24
 - 8306841: Generational ZGC: NMT reports Java heap size larger than max heap size
 - 8304425: ClassHierarchyResolver from Reflection
 - 8309235: Unnamed Variables (_) can't be used in JShell
 - 8306431: File.listRoots method description should be re-examined
 - 8309602: update JVMTI history table for jdk 21
 - 8308764: Reporting errors from create_vm may crash
 - 8308152: PropertyDescriptor should work with overridden generic getter method
 - 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553
 - ... and 252 more: https://git.openjdk.org/valhalla/compare/94636f4c...1a7f6b17

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

Changes: https://git.openjdk.org/valhalla/pull/861/files
  Stats: 78980 lines in 1186 files changed: 63502 ins; 9853 del; 5625 mod
  Patch: https://git.openjdk.org/valhalla/pull/861.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/861/head:pull/861

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


From jbhateja at openjdk.org  Mon Jun 12 02:09:09 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 12 Jun 2023 02:09:09 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <BzPWEt3Wkk9v5GtW61LMjtihXsjs7ke-Ryn1uWIdK0Y=.830e2be4-fa9b-4169-aab1-0c8f0dacc873@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
 <IoBaXno_ojU_8netCa5sMa7mIiX5LOJbS7-csjyVmu8=.6ff19e64-5911-407f-9a34-1fd560c5430e@github.com>
 <BzPWEt3Wkk9v5GtW61LMjtihXsjs7ke-Ryn1uWIdK0Y=.830e2be4-fa9b-4169-aab1-0c8f0dacc873@github.com>
Message-ID: <ej-uNiOSrukv3pfqFj75mskpwCSdiaa5vInQ5VrRV_k=.3a6de0b0-387b-4866-ab3c-bfd177697753@github.com>

On Thu, 8 Jun 2023 12:29:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @TobiHartmann ,
>> Can you kindly sponsor the patch.
>> 
>> Best Regards,
>> Jatin
>
>> Hi @jatin-bhateja , could you please rebase this PR and resolve the conflicts, so that we can let this merge in as soon as possible? Thanks! I also tried to applied this merge PR and resolve the conflicts locally. But I met new jtreg regression, and I think we can fix it with followed patches after this merge is in. WDYT?
> 
> Hi @XiaohongGong ,
> 
> I am in process of rebasing this merge with latest lworld.
> Will update, as discussed any further validations to be done on the merge branch with latest lworld code on top of your recently merged changes.
> 
> Best Regards,
> Jatin

> > > Hi @jatin-bhateja , could you please rebase this PR and resolve the conflicts, so that we can let this merge in as soon as possible? Thanks! I also tried to applied this merge PR and resolve the conflicts locally. But I met new jtreg regression, and I think we can fix it with followed patches after this merge is in. WDYT?
> > 
> > 
> > Hi @XiaohongGong ,
> > I am in process of rebasing this merge with latest lworld. Will update, as discussed any further validations to be done on the merge branch with latest lworld code on top of your recently merged changes.
> > Best Regards, Jatin
> 
> Thanks for the updating! I guess there will be too more conflicts with latest lword branch, like the big `VectorShuffle` refactory. I was planning to do another merge after this one, with the changes to the `VectorShuffle`. But I'm also fine rebasing this one to the latest lworld. Thanks for doing this!
> 
> Best Regards, Xiaohong

Hi @XiaohongGong ,

There have been significant changes in FieldInfo structure after https://bugs.openjdk.org/browse/JDK-8292818
I again started a new merge since there have been couple of mainline merges into lworld on top of your recently checked in patch related to shuffle and mask handling.

I have appropriately resolved the conflicts related to multifield handling in oops model and plan to withdraw this PR and plan submit a new merge pull request soon.

Best Regards,
Jatin

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

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


From dsimms at openjdk.org  Mon Jun 12 05:22:56 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 12 Jun 2023 05:22:56 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <tvZ25CjksVq6n6v98gzmuNs75rVO2H5Fwzv-_Unfhko=.80451911-6699-42d0-9f82-9090ee36c1b4@github.com>
References: <tvZ25CjksVq6n6v98gzmuNs75rVO2H5Fwzv-_Unfhko=.80451911-6699-42d0-9f82-9090ee36c1b4@github.com>
Message-ID: <GaXlCrMOzKbbv6f-pGLe12TWubMt7CyQKcvPeJuwkEk=.3e6eb970-3525-42c9-af09-14bcef70d144@github.com>

> * jdk-21+25
> * jdk-22+0

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1516 commits:

 - Logical merge fixes
 - Merge tag 'jdk-22+0' into lworld_merge_jdk_incr_from_21_24
   
   Added tag jdk-22+0 for changeset bb377b26
 - Logical merge fix
 - Merge tag 'jdk-21+25' into lworld_merge_jdk_incr_from_21_24
   
   Added tag jdk-21+25 for changeset a46b5acc
 - Merge commit '8dbd3840039dfe962b8fda0e4fa2b2d53068fb5e' into lworld_merge_jdk_incr_from_21_24
 - Merge commit '25b98030569d863e605f398d5f97211008c58ca3' into lworld_merge_jdk_incr_from_21_24
 - Logical merge fixes and disable igvn worklist assert
 - Merge commit '1b8e6bf31ccc0eb2db3c26ed2fac2c406eda53be' into lworld_merge_jdk_incr_from_21_24
 - Logical merge fix: KlassKind
 - Merge commit 'c72b5474255d56f704930509525de69711dd9bfb' into lworld_merge_jdk_incr_from_21_24
 - ... and 1506 more: https://git.openjdk.org/valhalla/compare/bb377b26...1a7f6b17

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

Changes: https://git.openjdk.org/valhalla/pull/861/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=861&range=01
  Stats: 205861 lines in 1571 files changed: 197216 ins; 2009 del; 6636 mod
  Patch: https://git.openjdk.org/valhalla/pull/861.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/861/head:pull/861

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


From dsimms at openjdk.org  Mon Jun 12 05:22:58 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 12 Jun 2023 05:22:58 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <tvZ25CjksVq6n6v98gzmuNs75rVO2H5Fwzv-_Unfhko=.80451911-6699-42d0-9f82-9090ee36c1b4@github.com>
References: <tvZ25CjksVq6n6v98gzmuNs75rVO2H5Fwzv-_Unfhko=.80451911-6699-42d0-9f82-9090ee36c1b4@github.com>
Message-ID: <mqiihPpyqsGPtBQ4RbLBWiTQE471LopgfpEAyLTnL3I=.d433ec3c-3207-4ca0-9337-c91c1a45fca7@github.com>

On Fri, 9 Jun 2023 17:23:48 GMT, David Simms <dsimms at openjdk.org> wrote:

> * jdk-21+25
> * jdk-22+0

This pull request has now been integrated.

Changeset: c26c6921
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c26c692137a5639a84d5e2406c6b58b89f4d06ef
Stats:     78980 lines in 1186 files changed: 63502 ins; 9853 del; 5625 mod

Merge jdk

Merge jdk-21+25 and jdk-22+0

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

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


From tobias.hartmann at oracle.com  Mon Jun 12 13:40:18 2023
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 12 Jun 2023 15:40:18 +0200
Subject: Usage of stack pointers
In-Reply-To: <CAJmD-=6TvyZpsCDwxM7qhOg_W4mm1=GQXHVjK1L7WzytgPxOPg@mail.gmail.com>
References: <CAJmD-=6TvyZpsCDwxM7qhOg_W4mm1=GQXHVjK1L7WzytgPxOPg@mail.gmail.com>
Message-ID: <a2ce66e8-bed3-6565-2475-8f47dd487bd6@oracle.com>

Hi Andrii,

Ideally, hot methods are C2 compiled and therefore heap allocation / copying is only required when
storing into containers.

Stack allocation support for C2 has been proposed before [1] and is out of scope of this project.

Best regards,
Tobias

[1] https://github.com/microsoft/openjdk-proposals/blob/main/stack_allocation/Stack_Allocation_JEP.md


On 24.05.23 08:54, Andrey Lomakin wrote:
> Hi guys.
> 
> I don't know whether it is the correct mailing list to ask, but I will try it.
> 
> If I got JEP correctly, value objects are inlined in case of usage of the C2 compiler if they are
> passed as function arguments. It means that we will have an overhead of copying data. So likely,
> this optimization will depend on the size of the value object. But what about passing the stack
> pointer with the ability to convert stack-based value objects into heap objects if the passed
> references leak the called method??
> 
> Are such optimizations considered or possible?
> 
> -- 
> Best regards,
> Andrii Lomakin.
> 


From xgong at openjdk.org  Tue Jun 13 02:19:09 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 13 Jun 2023 02:19:09 GMT
Subject: [lworld] RFR: 8309650: [lworld] Fix mismatch inline type issue
 during method calls
In-Reply-To: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
References: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
Message-ID: <ynxymQf6TR-1cCTJF504vHWLd2bS25Hmm3EXlSG1xfw=.a781ef9c-6c6b-4c49-9efd-a8ad5f511520@github.com>

On Fri, 9 Jun 2023 08:31:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JVM crashes with following assertion failure when running the new added
>  test case (i.e. `compiler/valhalla/inlinetypes/TestCastMismatch.java`):
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
>  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/graphKit.cpp:3414), pid=1533674, tid=1533690
>  assert(stopped() || !toop->is_inlinetypeptr() || obj->is_InlineType()) failed: should have been scalarized
> 
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0xd2c070] GraphKit::gen_checkcast(Node*, Node*, Node**, bool)+0x46c
> 
> 
> The failure happens when compiler knows the type of the `checkcast`
>  input is a value/primitive class, while the input node is not an
>  `InlineTypeNode`. Note that `InlineTypeNode` is use to represent each
>  value/primitive class instance.
> 
> In the test case, the input of cast is a method call. And from the
>  method declaration, the return type of this method is an abstract class
>  whose concrete subclass is a value class. From the method signature,
>  the compiler knows the return type is not a value class. Hence, when
>  it handles the return result of this method call, no `InlineTypeNode`
>  is generated. But when compiler handles the `checkcast` bytecode, it
>  checks the speculative type of the input, which is actually the concrete
>  class of the instance. In this case, it is the value class. So compiler
>  expects the input node is an `InlineTypeNode`.
> 
> To fix this issue, the compiler has to use the consistent type system
>  for different routines. This patch changes to use the speculative
>  type of the method call as well when handling the call's return result.
>  With this change, an `InlineTypeNode` is generated for this case after
>  the call, and the assertion pass.
> 
> Verified with `hotspot::hotspot_all, jdk::tier1,tier2,tier3, langtool::tier1`

Hi @TobiHartmann , could you please kindly take a look at this PR? Thanks a lot in advance!

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

PR Comment: https://git.openjdk.org/valhalla/pull/860#issuecomment-1588412589


From thartmann at openjdk.org  Tue Jun 13 14:06:15 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 13 Jun 2023 14:06:15 GMT
Subject: [lworld] RFR: 8309650: [lworld] Fix mismatch inline type issue
 during method calls
In-Reply-To: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
References: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
Message-ID: <sKWpiXB10pl-mXmo4zL2V62aIhDvypw4Vnmc4LnoqCs=.9bfcfdc3-1cd4-49ff-9a0a-ca7a2cbecd8c@github.com>

On Fri, 9 Jun 2023 08:31:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JVM crashes with following assertion failure when running the new added
>  test case (i.e. `compiler/valhalla/inlinetypes/TestCastMismatch.java`):
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
>  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/graphKit.cpp:3414), pid=1533674, tid=1533690
>  assert(stopped() || !toop->is_inlinetypeptr() || obj->is_InlineType()) failed: should have been scalarized
> 
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0xd2c070] GraphKit::gen_checkcast(Node*, Node*, Node**, bool)+0x46c
> 
> 
> The failure happens when compiler knows the type of the `checkcast`
>  input is a value/primitive class, while the input node is not an
>  `InlineTypeNode`. Note that `InlineTypeNode` is use to represent each
>  value/primitive class instance.
> 
> In the test case, the input of cast is a method call. And from the
>  method declaration, the return type of this method is an abstract class
>  whose concrete subclass is a value class. From the method signature,
>  the compiler knows the return type is not a value class. Hence, when
>  it handles the return result of this method call, no `InlineTypeNode`
>  is generated. But when compiler handles the `checkcast` bytecode, it
>  checks the speculative type of the input, which is actually the concrete
>  class of the instance. In this case, it is the value class. So compiler
>  expects the input node is an `InlineTypeNode`.
> 
> To fix this issue, the compiler has to use the consistent type system
>  for different routines. This patch changes to use the speculative
>  type of the method call as well when handling the call's return result.
>  With this change, an `InlineTypeNode` is generated for this case after
>  the call, and the assertion pass.
> 
> Verified with `hotspot::hotspot_all, jdk::tier1,tier2,tier3, langtool::tier1`

Looks good to me, thanks for fixing! Let me run this through our testing and report back once it passed.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/860#pullrequestreview-1477263835


From thartmann at openjdk.org  Wed Jun 14 07:41:23 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 14 Jun 2023 07:41:23 GMT
Subject: [lworld] RFR: 8309650: [lworld] Fix mismatch inline type issue
 during method calls
In-Reply-To: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
References: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
Message-ID: <mjPq9YwiwTz1dgrE2hMeWAE2W1KMUMDk_ck82sOtXOo=.cb103975-6288-48ec-a005-bd95f18aa1ff@github.com>

On Fri, 9 Jun 2023 08:31:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JVM crashes with following assertion failure when running the new added
>  test case (i.e. `compiler/valhalla/inlinetypes/TestCastMismatch.java`):
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
>  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/graphKit.cpp:3414), pid=1533674, tid=1533690
>  assert(stopped() || !toop->is_inlinetypeptr() || obj->is_InlineType()) failed: should have been scalarized
> 
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0xd2c070] GraphKit::gen_checkcast(Node*, Node*, Node**, bool)+0x46c
> 
> 
> The failure happens when compiler knows the type of the `checkcast`
>  input is a value/primitive class, while the input node is not an
>  `InlineTypeNode`. Note that `InlineTypeNode` is use to represent each
>  value/primitive class instance.
> 
> In the test case, the input of cast is a method call. And from the
>  method declaration, the return type of this method is an abstract class
>  whose concrete subclass is a value class. From the method signature,
>  the compiler knows the return type is not a value class. Hence, when
>  it handles the return result of this method call, no `InlineTypeNode`
>  is generated. But when compiler handles the `checkcast` bytecode, it
>  checks the speculative type of the input, which is actually the concrete
>  class of the instance. In this case, it is the value class. So compiler
>  expects the input node is an `InlineTypeNode`.
> 
> To fix this issue, the compiler has to use the consistent type system
>  for different routines. This patch changes to use the speculative
>  type of the method call as well when handling the call's return result.
>  With this change, an `InlineTypeNode` is generated for this case after
>  the call, and the assertion pass.
> 
> Verified with `hotspot::hotspot_all, jdk::tier1,tier2,tier3, langtool::tier1`

All testing passed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/860#issuecomment-1590645334


From xgong at openjdk.org  Wed Jun 14 07:57:28 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 14 Jun 2023 07:57:28 GMT
Subject: [lworld] RFR: 8309650: [lworld] Fix mismatch inline type issue
 during method calls
In-Reply-To: <mjPq9YwiwTz1dgrE2hMeWAE2W1KMUMDk_ck82sOtXOo=.cb103975-6288-48ec-a005-bd95f18aa1ff@github.com>
References: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
 <mjPq9YwiwTz1dgrE2hMeWAE2W1KMUMDk_ck82sOtXOo=.cb103975-6288-48ec-a005-bd95f18aa1ff@github.com>
Message-ID: <4AUkGwTNNJKnvvK-rhireEQ-Ca04udB1B3uCF0wRfZo=.1ba902a6-21d1-4b20-b9ed-cf5c70d83c5a@github.com>

On Wed, 14 Jun 2023 07:38:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> All testing passed.

Thanks for the review and testing @TobiHartmann !

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

PR Comment: https://git.openjdk.org/valhalla/pull/860#issuecomment-1590666641


From xgong at openjdk.org  Wed Jun 14 07:57:28 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 14 Jun 2023 07:57:28 GMT
Subject: [lworld] RFR: 8309650: [lworld] Fix mismatch inline type issue
 during method calls
In-Reply-To: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
References: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
Message-ID: <EkEFV_BuQRzfCX05JsFe3Pu7GtatGwO0R1bPY2AGOVs=.5f49aaa6-d0dd-49cd-8fe1-04f90f7fe4f4@github.com>

On Fri, 9 Jun 2023 08:31:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JVM crashes with following assertion failure when running the new added
>  test case (i.e. `compiler/valhalla/inlinetypes/TestCastMismatch.java`):
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
>  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/graphKit.cpp:3414), pid=1533674, tid=1533690
>  assert(stopped() || !toop->is_inlinetypeptr() || obj->is_InlineType()) failed: should have been scalarized
> 
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0xd2c070] GraphKit::gen_checkcast(Node*, Node*, Node**, bool)+0x46c
> 
> 
> The failure happens when compiler knows the type of the `checkcast`
>  input is a value/primitive class, while the input node is not an
>  `InlineTypeNode`. Note that `InlineTypeNode` is use to represent each
>  value/primitive class instance.
> 
> In the test case, the input of cast is a method call. And from the
>  method declaration, the return type of this method is an abstract class
>  whose concrete subclass is a value class. From the method signature,
>  the compiler knows the return type is not a value class. Hence, when
>  it handles the return result of this method call, no `InlineTypeNode`
>  is generated. But when compiler handles the `checkcast` bytecode, it
>  checks the speculative type of the input, which is actually the concrete
>  class of the instance. In this case, it is the value class. So compiler
>  expects the input node is an `InlineTypeNode`.
> 
> To fix this issue, the compiler has to use the consistent type system
>  for different routines. This patch changes to use the speculative
>  type of the method call as well when handling the call's return result.
>  With this change, an `InlineTypeNode` is generated for this case after
>  the call, and the assertion pass.
> 
> Verified with `hotspot::hotspot_all, jdk::tier1,tier2,tier3, langtool::tier1`

Do I need another review or can integrate it now? Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/860#issuecomment-1590667855


From thartmann at openjdk.org  Wed Jun 14 09:16:27 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 14 Jun 2023 09:16:27 GMT
Subject: [lworld] RFR: 8309650: [lworld] Fix mismatch inline type issue
 during method calls
In-Reply-To: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
References: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
Message-ID: <irznQfuckgeMcla2n8lI0DYkwc_5-3lNvc5WoYBKp1Y=.ed04ad7b-508a-488f-b5ad-4a729831a88d@github.com>

On Fri, 9 Jun 2023 08:31:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JVM crashes with following assertion failure when running the new added
>  test case (i.e. `compiler/valhalla/inlinetypes/TestCastMismatch.java`):
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
>  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/graphKit.cpp:3414), pid=1533674, tid=1533690
>  assert(stopped() || !toop->is_inlinetypeptr() || obj->is_InlineType()) failed: should have been scalarized
> 
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0xd2c070] GraphKit::gen_checkcast(Node*, Node*, Node**, bool)+0x46c
> 
> 
> The failure happens when compiler knows the type of the `checkcast`
>  input is a value/primitive class, while the input node is not an
>  `InlineTypeNode`. Note that `InlineTypeNode` is use to represent each
>  value/primitive class instance.
> 
> In the test case, the input of cast is a method call. And from the
>  method declaration, the return type of this method is an abstract class
>  whose concrete subclass is a value class. From the method signature,
>  the compiler knows the return type is not a value class. Hence, when
>  it handles the return result of this method call, no `InlineTypeNode`
>  is generated. But when compiler handles the `checkcast` bytecode, it
>  checks the speculative type of the input, which is actually the concrete
>  class of the instance. In this case, it is the value class. So compiler
>  expects the input node is an `InlineTypeNode`.
> 
> To fix this issue, the compiler has to use the consistent type system
>  for different routines. This patch changes to use the speculative
>  type of the method call as well when handling the call's return result.
>  With this change, an `InlineTypeNode` is generated for this case after
>  the call, and the assertion pass.
> 
> Verified with `hotspot::hotspot_all, jdk::tier1,tier2,tier3, langtool::tier1`

One review is sufficient. Please integrate.

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

PR Comment: https://git.openjdk.org/valhalla/pull/860#issuecomment-1590811249


From xgong at openjdk.org  Wed Jun 14 11:38:34 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 14 Jun 2023 11:38:34 GMT
Subject: [lworld] Integrated: 8309650: [lworld] Fix mismatch inline type issue
 during method calls
In-Reply-To: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
References: <v3MKi9O3wJlEuu8lGQrhIkPOmkci2crssIgnX0qY4r0=.51ff904d-caa7-4ec2-bec0-425948d268ee@github.com>
Message-ID: <Gp8jqnZ0Ax8V3Qxa4ZWem5rcuUN2Fu2fbZ_KCdvPH7M=.92999c8f-bb20-4c72-880c-a8a01e6c5c64@github.com>

On Fri, 9 Jun 2023 08:31:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> JVM crashes with following assertion failure when running the new added
>  test case (i.e. `compiler/valhalla/inlinetypes/TestCastMismatch.java`):
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
>  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/graphKit.cpp:3414), pid=1533674, tid=1533690
>  assert(stopped() || !toop->is_inlinetypeptr() || obj->is_InlineType()) failed: should have been scalarized
> 
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0xd2c070] GraphKit::gen_checkcast(Node*, Node*, Node**, bool)+0x46c
> 
> 
> The failure happens when compiler knows the type of the `checkcast`
>  input is a value/primitive class, while the input node is not an
>  `InlineTypeNode`. Note that `InlineTypeNode` is use to represent each
>  value/primitive class instance.
> 
> In the test case, the input of cast is a method call. And from the
>  method declaration, the return type of this method is an abstract class
>  whose concrete subclass is a value class. From the method signature,
>  the compiler knows the return type is not a value class. Hence, when
>  it handles the return result of this method call, no `InlineTypeNode`
>  is generated. But when compiler handles the `checkcast` bytecode, it
>  checks the speculative type of the input, which is actually the concrete
>  class of the instance. In this case, it is the value class. So compiler
>  expects the input node is an `InlineTypeNode`.
> 
> To fix this issue, the compiler has to use the consistent type system
>  for different routines. This patch changes to use the speculative
>  type of the method call as well when handling the call's return result.
>  With this change, an `InlineTypeNode` is generated for this case after
>  the call, and the assertion pass.
> 
> Verified with `hotspot::hotspot_all, jdk::tier1,tier2,tier3, langtool::tier1`

This pull request has now been integrated.

Changeset: 53b40f92
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/53b40f92b5af2d438a340209c56bcc6e5af0378e
Stats:     96 lines in 3 files changed: 93 ins; 0 del; 3 mod

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

Reviewed-by: thartmann

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

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


From thartmann at openjdk.org  Wed Jun 14 14:16:42 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 14 Jun 2023 14:16:42 GMT
Subject: [lworld] RFR: 8310022: [lworld] C1 compilation asserts with new
 lightweight locking
Message-ID: <xTLcfOEH0VjF6rkMdk1j0HsN9XYuUIvhQv1bWP-4ImY=.7f8f94f6-a432-4f68-b9e4-e10494092dd4@github.com>

Let's remove the asserts until support for the new lightweight locking is implemented by [JDK-8310023](https://bugs.openjdk.org/browse/JDK-8310023) to avoid failures with tests that run with `-XX:LockingMode=2` but don't use any inline types.

Thanks,
Tobias

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

Commit messages:
 - Re-added code
 - 8310022: [lworld] C1 compilation asserts with new lightweight locking

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

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


From thartmann at openjdk.org  Wed Jun 14 14:21:19 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 14 Jun 2023 14:21:19 GMT
Subject: [lworld] Integrated: 8310022: [lworld] C1 compilation asserts with new
 lightweight locking
In-Reply-To: <xTLcfOEH0VjF6rkMdk1j0HsN9XYuUIvhQv1bWP-4ImY=.7f8f94f6-a432-4f68-b9e4-e10494092dd4@github.com>
References: <xTLcfOEH0VjF6rkMdk1j0HsN9XYuUIvhQv1bWP-4ImY=.7f8f94f6-a432-4f68-b9e4-e10494092dd4@github.com>
Message-ID: <JiaFsnjIkQ_F2cr_QrXlsGxRzF1nygBu7TCpAOmD5lc=.3947f15a-a758-4162-a249-5abff642a564@github.com>

On Wed, 14 Jun 2023 14:09:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Let's remove the asserts until support for the new lightweight locking is implemented by [JDK-8310023](https://bugs.openjdk.org/browse/JDK-8310023) to avoid failures with tests that run with `-XX:LockingMode=2` but don't use any inline types.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 07aebbf7
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/07aebbf75b902184a43748b41266c16c2e049c11
Stats:     4 lines in 2 files changed: 0 ins; 1 del; 3 mod

8310022: [lworld] C1 compilation asserts with new lightweight locking

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

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


From tanksherman27 at gmail.com  Thu Jun 15 12:37:20 2023
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 15 Jun 2023 20:37:20 +0800
Subject: What happened to primitive classes?
In-Reply-To: <63319410.61631771.1684768111794.JavaMail.zimbra@univ-eiffel.fr>
References: <CAP2b4GOaqda-hCO+U=goBOKNoLpNMM6NEsWu-D6TruJ8j2X5dw@mail.gmail.com>
 <63319410.61631771.1684768111794.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAP2b4GM0jVoWBsDVj9N2u2+owmR-opVEcWbPdTOZQpA=H0RqCQ@mail.gmail.com>

Well, that's a shame. I was just about to ask about "mutability" on
primitive classes ("Mutability", much in the same way that int i; can later
be reassigned by i = 7;) until I saw that change. Unless these new combined
value and primitive classes are similar enough to have that discussion, at
least

On Mon, May 22, 2023 at 11:08?PM Remi Forax <forax at univ-mlv.fr> wrote:

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

From xgong at openjdk.org  Tue Jun 20 06:31:00 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 20 Jun 2023 06:31:00 GMT
Subject: [lworld+vector] RFR: 8309777: [lworld+vector] Fix re-materialize crash
 for vector objects with un-vectorized multi-fields during deoptimization
Message-ID: <YYY6johRPmSm1Tbf4Eispzw5PtA0X3OeFDTfYxj5OIM=.430df61f-ffdf-404a-9752-73cd33123595@github.com>

Some vector API jtreg tests crash when running on hardwares that do
 not support the relative vector species.

Here is the log:


  A fatal error has been detected by the Java Runtime Environment:

  Internal Error (valhalla/src/hotspot/share/prims/vectorSupport.cpp:317), pid=2529357, tid=2529377
  assert(loc_type == Location::oop || loc_type == Location::narrowoop) failed: expected 'oop'(2) or 'narrowoop'(9) types location but got: 3

  JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-62ba7fc27)
  Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-62ba7fc27, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
  Problematic frame:
  V [[libjvm.so](http://libjvm.so/)+0x1aed828] VectorSupport::allocate_vector_payload(InstanceKlass*, int, BasicType, frame*, RegisterMap*, ObjectValue*, JavaThread*)+0x41


The root cause is `VectorSupport::allocate_vector_payload` assumes the
 `ScopeValue` which denotes the field value generated by C2 compiler
 is a vector or an oop. But after the vector's payload is changed to be
 the `MultiField` annotated field, the non-static fields of the vector
 class is changed to be a series of fields with the same primitive type.
 In C2 compiler, operations for such multi-fields can be vectorized only
 if the running hardware supports the vector operations for the specified
 vector size. For such cases, the field value generated by C2 is a vector.
 Otherwise, the fields are the scalarized primitive type values. Hence
 the re-materizalization for such vector objects should be handled just
 like other normal objects.

To make things right when re-materializing vector objects whose fields
 are not vectorized, two parts need to be modified:

1. In c2 compiler, pass the un-vectorized multi-fields on safepoint when
 scalaring an `InlineTypeNode`. To try to vectorize the multi-fields in
 compiler, only the multi-field base is added to the klass's non-static
 field list. And the other multi-fields are saved in a secondary field list
 of their multi-field base. So if the multi-fields are not vectorized, all
 the field members should be found out and passed to the safepoint.

2. During deoptimization, re-materialize the vector objects with different
 routines based on the `ScopeValue` types. That is, go to the `VectorSupport`
 routine to re-allocate the objects from a vector value, while go to the
 normal objects re-allocation path if the field value is not a vector.

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

Commit messages:
 - 8309777: [lworld+vector] Fix re-materialize crash for vector objects with un-vectorized multi-fields during deoptimization

Changes: https://git.openjdk.org/valhalla/pull/863/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=863&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309777
  Stats: 98 lines in 5 files changed: 63 ins; 17 del; 18 mod
  Patch: https://git.openjdk.org/valhalla/pull/863.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/863/head:pull/863

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


From jbhateja at openjdk.org  Wed Jun 21 02:31:36 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 21 Jun 2023 02:31:36 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
Message-ID: <ko1A-CD56rbG0X9fCOzgnEBn3JsPhIbvjUshcGtq_D0=.595a7a48-0ca6-484f-89ae-df4d64aec26d@github.com>

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

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

Squashing this one and will create a new merge PR.

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

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


From jbhateja at openjdk.org  Wed Jun 21 02:31:36 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 21 Jun 2023 02:31:36 GMT
Subject: [lworld+vector] Withdrawn: Merge lworld
In-Reply-To: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
References: <TCPB1-XMajlG3PViwCZhW7ChnzlSSwQaVqmX5m3muPY=.be32ea4e-6a62-4ac2-87dd-bbf4abfce2ed@github.com>
Message-ID: <rBZhWZZzgFP7Od7t3qaxohqXc_SikY2RBHwXBaYzqvE=.92aec271-105d-4510-bde8-a34302e57075@github.com>

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

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

This pull request has been closed without being integrated.

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

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


From thartmann at openjdk.org  Wed Jun 21 12:53:40 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 21 Jun 2023 12:53:40 GMT
Subject: [lworld] RFR: 8310034: [lworld] C2 compilation fails with assert
 "array can't be flattened"
Message-ID: <ZCKpLc_vqzbt6GEBAY7LkeV3CYMRn-qwXYF7WyynBEg=.e14c07dc-1ad1-421b-aaa8-2e9b79deed7b@github.com>

We assert because the `not_flat` / `not_null_free` properties of the `TypeAry` are not properly set in the intrinsic.

Best regards,
Tobias

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

Commit messages:
 - Fixed newlines
 - 8310034: [lworld] C2 compilation fails with assert "array can't be flattened"

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

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


From thartmann at openjdk.org  Wed Jun 21 13:43:36 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 21 Jun 2023 13:43:36 GMT
Subject: [lworld] Integrated: 8310034: [lworld] C2 compilation fails with
 assert "array can't be flattened"
In-Reply-To: <ZCKpLc_vqzbt6GEBAY7LkeV3CYMRn-qwXYF7WyynBEg=.e14c07dc-1ad1-421b-aaa8-2e9b79deed7b@github.com>
References: <ZCKpLc_vqzbt6GEBAY7LkeV3CYMRn-qwXYF7WyynBEg=.e14c07dc-1ad1-421b-aaa8-2e9b79deed7b@github.com>
Message-ID: <El3YBM02riywYwnEJtES0IW8T-kUv7aF46h5OnDrq_4=.ba717fab-4fbf-42f7-addf-3f845e0f0f05@github.com>

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

> We assert because the `not_flat` / `not_null_free` properties of the `TypeAry` are not properly set in the intrinsic.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

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

8310034: [lworld] C2 compilation fails with assert "array can't be flattened"

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

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


From thartmann at openjdk.org  Thu Jun 22 15:01:32 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 22 Jun 2023 15:01:32 GMT
Subject: [lworld] Integrated: 8310650: [lworld] Problemlist
 PrimitiveClassConstantTest.java
Message-ID: <gfjoJGzWsMKQpqFciOdH48g0e7ZUByERAT3zZwLbwCk=.5e7ee17c-e60c-4c18-b095-9ec0b2bae1be@github.com>

See [JDK-8310649](https://bugs.openjdk.org/browse/JDK-8310649) and [JDK-8310651](https://bugs.openjdk.org/browse/JDK-8310651).

Thanks,
Tobias

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

Commit messages:
 - Problem list some tests after the merge

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

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


From thartmann at openjdk.org  Thu Jun 22 15:01:33 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 22 Jun 2023 15:01:33 GMT
Subject: [lworld] Integrated: 8310650: [lworld] Problemlist
 PrimitiveClassConstantTest.java
In-Reply-To: <gfjoJGzWsMKQpqFciOdH48g0e7ZUByERAT3zZwLbwCk=.5e7ee17c-e60c-4c18-b095-9ec0b2bae1be@github.com>
References: <gfjoJGzWsMKQpqFciOdH48g0e7ZUByERAT3zZwLbwCk=.5e7ee17c-e60c-4c18-b095-9ec0b2bae1be@github.com>
Message-ID: <YHn5jZNeB46OoBD3M_pO-uVsz6uhgyU35iUs7UN0UMg=.17f1fec1-003a-4065-a5bc-b73ebe58b91b@github.com>

On Thu, 22 Jun 2023 14:51:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> See [JDK-8310649](https://bugs.openjdk.org/browse/JDK-8310649) and [JDK-8310651](https://bugs.openjdk.org/browse/JDK-8310651).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8310650: [lworld] Problemlist PrimitiveClassConstantTest.java
8310652: Problemlist ValueConstantDesc.java

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

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


From vromero at openjdk.org  Thu Jun 22 20:43:36 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 22 Jun 2023 20:43:36 GMT
Subject: Integrated: 8310664: remove compiler support for primitive classes
Message-ID: <YJt9Ahtx0Wznudkzb27tU8MztE4idu586zR-ix0xza8=.145b7e51-35e8-4b89-bf06-a2e4e5a69615@github.com>

Remove support for primitive classes in the compiler:
 - switches for checking if primitive classes are allowed and code protected by them
 - remove flavors, Q-types, primitive classes related predicates
 - uses of `.ref` `.val` and projections related code
 - parser support for primitive classes
 - removing the PRIMITIVE_CLASS and ACC_PRIMITIVE flags and its uses
 - some minor refactorings and adjustments to regression tests
 - removing Type.ConstantPoolQType

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

Commit messages:
 - fixing whitespace issue
 - 8310664: remove compiler support for primitive classes

Changes: https://git.openjdk.org/valhalla/pull/868/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=868&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310664
  Stats: 1219 lines in 156 files changed: 117 ins; 856 del; 246 mod
  Patch: https://git.openjdk.org/valhalla/pull/868.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/868/head:pull/868

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


From vromero at openjdk.org  Thu Jun 22 20:43:36 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 22 Jun 2023 20:43:36 GMT
Subject: Integrated: 8310664: remove compiler support for primitive classes
In-Reply-To: <YJt9Ahtx0Wznudkzb27tU8MztE4idu586zR-ix0xza8=.145b7e51-35e8-4b89-bf06-a2e4e5a69615@github.com>
References: <YJt9Ahtx0Wznudkzb27tU8MztE4idu586zR-ix0xza8=.145b7e51-35e8-4b89-bf06-a2e4e5a69615@github.com>
Message-ID: <C0esYxJwCcxv3fWh2kRRRfSG5X65AsR1WXwPUimvYvM=.6568ec73-1a99-4304-9daa-88fda7514a77@github.com>

On Thu, 22 Jun 2023 20:24:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Remove support for primitive classes in the compiler:
>  - switches for checking if primitive classes are allowed and code protected by them
>  - remove flavors, Q-types, primitive classes related predicates
>  - uses of `.ref` `.val` and projections related code
>  - parser support for primitive classes
>  - removing the PRIMITIVE_CLASS and ACC_PRIMITIVE flags and its uses
>  - some minor refactorings and adjustments to regression tests
>  - removing Type.ConstantPoolQType

This pull request has now been integrated.

Changeset: 9496505d
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9496505d6ebe3e7780fe6a3f300c9298c6cffa59
Stats:     1219 lines in 156 files changed: 117 ins; 856 del; 246 mod

8310664: remove compiler support for primitive classes

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

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


From vromero at openjdk.org  Thu Jun 22 22:13:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 22 Jun 2023 22:13:49 GMT
Subject: Integrated: 8310678: [lw5] add implicit constructors
Message-ID: <bYMOd0CMT9d_te9f_rmwdeBFLgDePrgwubW7dXRUG54=.3bf74706-8d34-442c-944b-b4a951bd5236@github.com>

add support for implicit constructors, add the ImplicitCreation and NullRestricted class file attributes, and the NonAtomic interface

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

Commit messages:
 - 8310678: [lw5] add implicit constructors

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

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


From vromero at openjdk.org  Thu Jun 22 22:13:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 22 Jun 2023 22:13:51 GMT
Subject: Integrated: 8310678: [lw5] add implicit constructors
In-Reply-To: <bYMOd0CMT9d_te9f_rmwdeBFLgDePrgwubW7dXRUG54=.3bf74706-8d34-442c-944b-b4a951bd5236@github.com>
References: <bYMOd0CMT9d_te9f_rmwdeBFLgDePrgwubW7dXRUG54=.3bf74706-8d34-442c-944b-b4a951bd5236@github.com>
Message-ID: <l434VcNzqW2rEPnaRMCmq5I2Gr7BogjQzwlggK5ffjU=.c71f5100-f925-4863-9e50-95f29c549694@github.com>

On Thu, 22 Jun 2023 22:06:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> add support for implicit constructors, add the ImplicitCreation and NullRestricted class file attributes, and the NonAtomic interface

This pull request has now been integrated.

Changeset: 7030f9f6
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7030f9f69426c87e935ecb8fd9528b62a18651a8
Stats:     433 lines in 24 files changed: 415 ins; 2 del; 16 mod

8310678: [lw5] add implicit constructors

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

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


From vromero at openjdk.org  Thu Jun 22 23:03:09 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 22 Jun 2023 23:03:09 GMT
Subject: Integrated: 8310679: [lw5] test refactoring,
 repurposing primitive classes tests
In-Reply-To: <GWG3Kt2VfmhE2bvcuqmnNU0uXRarnz9hxGJe9P2m86Y=.f1cfc336-a375-4c3b-9bcf-0c167c8f03e7@github.com>
References: <GWG3Kt2VfmhE2bvcuqmnNU0uXRarnz9hxGJe9P2m86Y=.f1cfc336-a375-4c3b-9bcf-0c167c8f03e7@github.com>
Message-ID: <K8GlsCNkR00uHAnx6WO46jzgs-uif7BSv7hRMCg8C-Q=.1ed8b66a-f68f-4ac9-96ab-6c590e9a8dda@github.com>

On Thu, 22 Jun 2023 22:50:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> refactoring regression tests, adding some new ones and repurposing primitive classes tests

This pull request has now been integrated.

Changeset: 024c99e0
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/024c99e00934decc4e29040fb47b64d9181d8f1c
Stats:     840 lines in 16 files changed: 260 ins; 580 del; 0 mod

8310679: [lw5] test refactoring, repurposing primitive classes tests

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

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


From vromero at openjdk.org  Thu Jun 22 23:03:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 22 Jun 2023 23:03:06 GMT
Subject: Integrated: 8310679: [lw5] test refactoring,
 repurposing primitive classes tests
Message-ID: <GWG3Kt2VfmhE2bvcuqmnNU0uXRarnz9hxGJe9P2m86Y=.f1cfc336-a375-4c3b-9bcf-0c167c8f03e7@github.com>

refactoring regression tests, adding some new ones and repurposing primitive classes tests

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

Commit messages:
 - fixing white space issue
 - 8310679: [lw5] test refactoring, repurposing primitive classes tests

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

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


From vromero at openjdk.org  Fri Jun 23 02:36:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 02:36:31 GMT
Subject: Integrated: 8310684: [lw5] adding missing ImplicitCreation and
 NullRestricted visitors in regression tests
Message-ID: <liJAJVq_nRtQlkGk_Qmtj4fuAK9Gm_mnDiQK0Y21-VY=.389bc789-9375-40d6-b1f5-33c100bb81d5@github.com>

minor fixes to couple of regression tests

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

Commit messages:
 - 8310684: [lw5] adding missing ImplicitCreation and NullRestricted visitors in regression tests

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

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


From vromero at openjdk.org  Fri Jun 23 02:36:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 02:36:31 GMT
Subject: Integrated: 8310684: [lw5] adding missing ImplicitCreation and
 NullRestricted visitors in regression tests
In-Reply-To: <liJAJVq_nRtQlkGk_Qmtj4fuAK9Gm_mnDiQK0Y21-VY=.389bc789-9375-40d6-b1f5-33c100bb81d5@github.com>
References: <liJAJVq_nRtQlkGk_Qmtj4fuAK9Gm_mnDiQK0Y21-VY=.389bc789-9375-40d6-b1f5-33c100bb81d5@github.com>
Message-ID: <hKzeDUNm9RR7ZOodR1u4Udm4KuqxzJfr5G05MaXEb2Q=.c1eef6c8-52f2-48b0-8682-4503e30061c0@github.com>

On Fri, 23 Jun 2023 02:28:13 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> minor fixes to couple of regression tests

This pull request has now been integrated.

Changeset: e9f496a6
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e9f496a6709dd8f10a93895fd1cfe35f1f5f6aa5
Stats:     13 lines in 2 files changed: 12 ins; 0 del; 1 mod

8310684: [lw5] adding missing ImplicitCreation and NullRestricted visitors in regression tests

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

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


From vromero at openjdk.org  Fri Jun 23 03:00:58 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 03:00:58 GMT
Subject: Integrated: 8310685: [lw5] adding support for null restricted types
Message-ID: <331KnN6G7NN3jzxi0sqwRoggDs_TAZTenYyMjSMbtAo=.0d414071-6d3d-41e7-804e-b8cb29a0c092@github.com>

initial support for null restricted types

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

Commit messages:
 - removing whitespace
 - 8310685: [lw5] adding support for null restricted types

Changes: https://git.openjdk.org/valhalla/pull/872/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=872&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310685
  Stats: 1259 lines in 21 files changed: 1206 ins; 4 del; 49 mod
  Patch: https://git.openjdk.org/valhalla/pull/872.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/872/head:pull/872

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


From vromero at openjdk.org  Fri Jun 23 03:01:01 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 03:01:01 GMT
Subject: Integrated: 8310685: [lw5] adding support for null restricted types
In-Reply-To: <331KnN6G7NN3jzxi0sqwRoggDs_TAZTenYyMjSMbtAo=.0d414071-6d3d-41e7-804e-b8cb29a0c092@github.com>
References: <331KnN6G7NN3jzxi0sqwRoggDs_TAZTenYyMjSMbtAo=.0d414071-6d3d-41e7-804e-b8cb29a0c092@github.com>
Message-ID: <WTdqQzmM5Hyk7PXlIxihY3rOeIHaekdqFEKJy41oZTI=.dee2e51d-e19d-4aaa-a402-6f1adbc443a9@github.com>

On Fri, 23 Jun 2023 02:43:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> initial support for null restricted types

This pull request has now been integrated.

Changeset: 5438b74f
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5438b74f7def714577bea9b4fba2fc5a108d4464
Stats:     1259 lines in 21 files changed: 1206 ins; 4 del; 49 mod

8310685: [lw5] adding support for null restricted types

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

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


From vromero at openjdk.org  Fri Jun 23 16:37:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 16:37:35 GMT
Subject: Integrated: 8310686: [lw5] check that only value classes with implicit
 constructor can implement NonAtomic
Message-ID: <N_PmDW5bMY8oyxK8CFhOsbvcrhUVv51rkpDUCnbYJls=.629f29f8-f852-4e00-98c1-63d52b6a0c28@github.com>

check that only value classes with implicit constructor can implement NonAtomic

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

Commit messages:
 - 8310686: check that only value classes with implicit constructor can implement NonAtomic

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

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


From vromero at openjdk.org  Fri Jun 23 16:37:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 16:37:35 GMT
Subject: Integrated: 8310686: [lw5] check that only value classes with implicit
 constructor can implement NonAtomic
In-Reply-To: <N_PmDW5bMY8oyxK8CFhOsbvcrhUVv51rkpDUCnbYJls=.629f29f8-f852-4e00-98c1-63d52b6a0c28@github.com>
References: <N_PmDW5bMY8oyxK8CFhOsbvcrhUVv51rkpDUCnbYJls=.629f29f8-f852-4e00-98c1-63d52b6a0c28@github.com>
Message-ID: <Kdk27Sk0SjVO_FfNAQ8RSq2gOHzbXWUMlkGUPr-XD4g=.f21ba0d2-965f-470a-ba65-eebc1a2142b5@github.com>

On Fri, 23 Jun 2023 16:27:43 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> check that only value classes with implicit constructor can implement NonAtomic

This pull request has now been integrated.

Changeset: 4449b02e
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4449b02e794068408dedecf1364292a9d19f2e54
Stats:     12 lines in 2 files changed: 12 ins; 0 del; 0 mod

8310686: [lw5] check that only value classes with implicit constructor can implement NonAtomic

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

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


From vromero at openjdk.org  Fri Jun 23 17:48:56 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 17:48:56 GMT
Subject: Integrated: 8310812: [lw5] addressing pending issues now that
 non-nullable types are available
Message-ID: <MJ9mGjIGpC_KCvA7ALBBa7NEKgOrxb4nBCW5hffR4Sw=.4d45f0be-5b74-4465-b00b-8e9e89195e89@github.com>

addressing pending issues now that non-nullable types are available

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

Commit messages:
 - 8310812: [lw5] addressing pending issues now that non-nullable types are available

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

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


From vromero at openjdk.org  Fri Jun 23 17:48:57 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 17:48:57 GMT
Subject: Integrated: 8310812: [lw5] addressing pending issues now that
 non-nullable types are available
In-Reply-To: <MJ9mGjIGpC_KCvA7ALBBa7NEKgOrxb4nBCW5hffR4Sw=.4d45f0be-5b74-4465-b00b-8e9e89195e89@github.com>
References: <MJ9mGjIGpC_KCvA7ALBBa7NEKgOrxb4nBCW5hffR4Sw=.4d45f0be-5b74-4465-b00b-8e9e89195e89@github.com>
Message-ID: <KkVjoxpulbebvztJrJ9YXDQBtQUc3Wl58r4n0Ylv950=.0c33afd0-baa7-4e33-a1fa-e017d2c35cad@github.com>

On Fri, 23 Jun 2023 17:41:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> addressing pending issues now that non-nullable types are available

This pull request has now been integrated.

Changeset: ea56651c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ea56651c2121e632373cbdeda3b6cc0ef2ffcc5f
Stats:     5 lines in 4 files changed: 1 ins; 0 del; 4 mod

8310812: [lw5] addressing pending issues now that non-nullable types are available

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

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


From vromero at openjdk.org  Fri Jun 23 21:22:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 21:22:28 GMT
Subject: RFR: 8310819: [lw5] loading NonAtomic can produce completion errors
Message-ID: <54wrGSq8IA-R2xOG2ySvgoUdWKewcAet8aM4ezfOatw=.26b0ff33-e058-4a6d-8f28-757143a5f05e@github.com>

loading java.lang.NonAtomic can produce completion errors

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

Commit messages:
 - 8310819: [lw5] loading NonAtomic can produce completion errors

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

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


From vromero at openjdk.org  Fri Jun 23 21:32:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 21:32:35 GMT
Subject: Integrated: 8310819: [lw5] loading NonAtomic can produce completion
 errors
In-Reply-To: <54wrGSq8IA-R2xOG2ySvgoUdWKewcAet8aM4ezfOatw=.26b0ff33-e058-4a6d-8f28-757143a5f05e@github.com>
References: <54wrGSq8IA-R2xOG2ySvgoUdWKewcAet8aM4ezfOatw=.26b0ff33-e058-4a6d-8f28-757143a5f05e@github.com>
Message-ID: <MlAwumLYLZ_Fwrk2S9tBkpPB7HEju36N2h2VjdPKzy0=.d6123227-dcdb-4aac-89b8-c2128384c2e1@github.com>

On Fri, 23 Jun 2023 21:15:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> loading java.lang.NonAtomic can produce completion errors

This pull request has now been integrated.

Changeset: df0cfa1e
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/df0cfa1e657eb4620c90cdeb44ecc5baef256565
Stats:     11 lines in 1 file changed: 10 ins; 0 del; 1 mod

8310819: [lw5] loading NonAtomic can produce completion errors

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

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


From vromero at openjdk.org  Fri Jun 23 22:21:37 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 22:21:37 GMT
Subject: Integrated: 8310832: [lw5] reflective creation of arrays of
 non-nullable types
Message-ID: <PBYn82x7Z0_gaCBRZQyjrCjzr901Y0YYpCUiq3iwMcU=.2bd9ad8a-b694-449e-ae37-961d2977bfa6@github.com>

adding support for reflective creation of arrays of non-nullable types

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

Commit messages:
 - 8310832: [lw5] reflective creation of arrays of non-nullable types

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

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


From vromero at openjdk.org  Fri Jun 23 22:21:38 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 23 Jun 2023 22:21:38 GMT
Subject: Integrated: 8310832: [lw5] reflective creation of arrays of
 non-nullable types
In-Reply-To: <PBYn82x7Z0_gaCBRZQyjrCjzr901Y0YYpCUiq3iwMcU=.2bd9ad8a-b694-449e-ae37-961d2977bfa6@github.com>
References: <PBYn82x7Z0_gaCBRZQyjrCjzr901Y0YYpCUiq3iwMcU=.2bd9ad8a-b694-449e-ae37-961d2977bfa6@github.com>
Message-ID: <cOT929xJUTdQVhh8w3D2wlkLD8qw5tdanPlBzZKRNe4=.31b5df0e-0be3-49d4-8db3-63573cfb9c39@github.com>

On Fri, 23 Jun 2023 22:12:21 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding support for reflective creation of arrays of non-nullable types

This pull request has now been integrated.

Changeset: 51b49102
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/51b49102f17abf415d94935b99b4aa674559b83f
Stats:     78 lines in 8 files changed: 69 ins; 6 del; 3 mod

8310832: [lw5] reflective creation of arrays of non-nullable types

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

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


From vromero at openjdk.org  Sat Jun 24 02:38:36 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 24 Jun 2023 02:38:36 GMT
Subject: RFR: 8310839: [lw5] implicit constructors must be public and declared
 in a value class
Message-ID: <eNj3YgUeVs_fRWIFohkNk2NJuOYZH8ZkfCE6-_KgbsU=.a1bb8bf2-302f-40ee-a9d8-4e1cfcaeb79b@github.com>

implicit constructors must be public and declared in a value class

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

Commit messages:
 - 8310839: [lw5] implicit constructors must be public and declared in a value class

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

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


From vromero at openjdk.org  Sat Jun 24 02:57:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 24 Jun 2023 02:57:21 GMT
Subject: Integrated: 8310839: [lw5] implicit constructors must be public and
 declared in a value class
In-Reply-To: <eNj3YgUeVs_fRWIFohkNk2NJuOYZH8ZkfCE6-_KgbsU=.a1bb8bf2-302f-40ee-a9d8-4e1cfcaeb79b@github.com>
References: <eNj3YgUeVs_fRWIFohkNk2NJuOYZH8ZkfCE6-_KgbsU=.a1bb8bf2-302f-40ee-a9d8-4e1cfcaeb79b@github.com>
Message-ID: <azZop1grRVVmQvFYdk4hyAGyNXVdxr6zR7mH4kH9krI=.b4d503d4-d6c0-4793-86f3-3c33db1344c1@github.com>

On Sat, 24 Jun 2023 02:32:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> implicit constructors must be public and declared in a value class

This pull request has now been integrated.

Changeset: c71797c8
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c71797c8e457269e7c408340d98da09c6ea97b86
Stats:     118 lines in 4 files changed: 109 ins; 6 del; 3 mod

8310839: [lw5] implicit constructors must be public and declared in a value class

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

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


From vromero at openjdk.org  Sat Jun 24 03:42:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 24 Jun 2023 03:42:51 GMT
Subject: Integrated: 8310840: [lw5] add several regression tests
In-Reply-To: <B7K0PYLOIX-4B2sI-euaNf8Pqw41i1YjhjelTqoHE_U=.0f6a71aa-8005-44c7-b08e-646ac52d1f9b@github.com>
References: <B7K0PYLOIX-4B2sI-euaNf8Pqw41i1YjhjelTqoHE_U=.0f6a71aa-8005-44c7-b08e-646ac52d1f9b@github.com>
Message-ID: <tzWgokPzLj85jb2HIvAu1kCAaSrSrTYeb4bR-Zb8Dck=.fc7851b6-da86-4e45-a82b-c192a0357b7a@github.com>

On Sat, 24 Jun 2023 03:10:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding several regression tests

This pull request has now been integrated.

Changeset: 5b9697dd
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5b9697dd790642df1626f4d94b6f108bff0ca75d
Stats:     751 lines in 32 files changed: 627 ins; 74 del; 50 mod

8310840: [lw5] add several regression tests

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

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


From vromero at openjdk.org  Sat Jun 24 03:42:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 24 Jun 2023 03:42:49 GMT
Subject: Integrated: 8310840: [lw5] add several regression tests
Message-ID: <B7K0PYLOIX-4B2sI-euaNf8Pqw41i1YjhjelTqoHE_U=.0f6a71aa-8005-44c7-b08e-646ac52d1f9b@github.com>

adding several regression tests

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

Commit messages:
 - white space issue
 - white spaces
 - 8310840: [lw5] add several regression tests

Changes: https://git.openjdk.org/valhalla/pull/878/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=878&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310840
  Stats: 751 lines in 32 files changed: 627 ins; 74 del; 50 mod
  Patch: https://git.openjdk.org/valhalla/pull/878.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/878/head:pull/878

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


From vromero at openjdk.org  Sat Jun 24 03:54:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 24 Jun 2023 03:54:25 GMT
Subject: Integrated: Merge lworld
Message-ID: <EgOFmvmHc87QyXrpYtYAjDHulWpzqDG3feMJu6vFz7s=.d87e3006-0d52-4dab-b73f-645476e068db@github.com>

Merge lworld into lw5

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

Commit messages:
 - Merge branch 'lworld' into merge_with_lworld
 - 8310650: [lworld] Problemlist PrimitiveClassConstantTest.java
 - 8310034: [lworld] C2 compilation fails with assert "array can't be flattened"

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

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

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


From vromero at openjdk.org  Sat Jun 24 03:54:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 24 Jun 2023 03:54:25 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <EgOFmvmHc87QyXrpYtYAjDHulWpzqDG3feMJu6vFz7s=.d87e3006-0d52-4dab-b73f-645476e068db@github.com>
References: <EgOFmvmHc87QyXrpYtYAjDHulWpzqDG3feMJu6vFz7s=.d87e3006-0d52-4dab-b73f-645476e068db@github.com>
Message-ID: <llAL4p48lfMfjfK6jXKx0-fapMAs6LxHbwu25hFoi1w=.f43873c2-fca3-4fda-8246-99c6af54c6a0@github.com>

On Sat, 24 Jun 2023 03:48:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge lworld into lw5

This pull request has now been integrated.

Changeset: 28a1d44f
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/28a1d44fbfcc22256cef20ec5fcf06eb4c7e4e0f
Stats:     4 lines in 3 files changed: 2 ins; 0 del; 2 mod

Merge lworld

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

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


From jbhateja at openjdk.org  Sun Jun 25 03:09:01 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 25 Jun 2023 03:09:01 GMT
Subject: [lworld+vector] RFR: Merge lworld
Message-ID: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>

Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 

Other Fixes addressed:-

A) CDS related: 
  - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
  - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
  
  - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	

  - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 

B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 

C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 

D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 

E) De-optimization related:-
  - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).

  - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::nof_nonstatic_field()_ and is agnostic to scalarization, instead it should consider the actual count of inputs fields connected to InlineTypeIR node [12]

F) A minor change in scalarization logic of multi-fields [13]    

With above changes in place most of the VectorAPI JTREG test points around vector/shuffle/masks are passing, we plan to fix remaining regressions with subsequent check-ins. 

[1] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/oops/inlineKlass.cpp#L541
[2] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/java.base/share/classes/java/lang/Class.java#L616
[3] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/classfile/classFileParser.cpp#L1527
[4] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/classfile/classFileParser.cpp#L1644
[5] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/classfile/classFileParser.cpp#L1692
[6] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/classfile/classFileParser.cpp#L1611
[7] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/vectornode.hpp#L1714 
[8] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/vectornode.hpp#L1716
[9] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/prims/vectorSupport.cpp#L320
[10] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/prims/vectorSupport.cpp#L323
[11] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L858
[12] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L327
[13] https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L44

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

Commit messages:
 - Cleanup payload allocation during deoptimization.
 - Whitespace fix.
 - Merge lworld
 - 8309586: [lworld] Feature version post merge doesn't match CheckFeatureGate1.java & CheckFeatureGate2.java
 - 8309466: [lworld] Problem list CDS tests until JDK-8309357 is fixed
 - 8309353: [lworld] C2 compilations fails with assert(false) failed: type flow analysis failed for OSR compilation
 - 8308756: [lworld] compiler/ciReplay/TestInliningProtectionDomain.java fails because CDS is disabled
 - Merge jdk
 - 8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
 - 8306698: Add overloads to MethodTypeDesc::of
 - ... and 2306 more: https://git.openjdk.org/valhalla/compare/4ce98c10...64ed7ffa

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

Changes: https://git.openjdk.org/valhalla/pull/866/files
  Stats: 1008748 lines in 11193 files changed: 686979 ins; 214208 del; 107561 mod
  Patch: https://git.openjdk.org/valhalla/pull/866.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/866/head:pull/866

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


From xgong at openjdk.org  Sun Jun 25 04:12:25 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 25 Jun 2023 04:12:25 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <aZrqpOEjhHVTXwB7cJq9R1MsMOLnRUFVrcJc4p-VOYQ=.b804ba13-1dc0-489f-adc0-453f8585c21a@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

Hi @jatin-bhateja ,

I ran the jtreg tests like `Byte128VectorTests.java` on ARM Neon machines, but I got too many such crashes:

test Byte128VectorTests.withByte128VectorTests(byte[i + 1]): failure
java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.vm.vector.VectorSupport$VectorPayloadMF128B
        at java.base/jdk.internal.vm.vector.VectorSupport$VectorPayloadMF.newInstanceFactory(VectorSupport.java:187)
        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.ByteVector$ByteSpecies.dummyVectorMF(ByteVector.java:4314)
        at jdk.incubator.vector/jdk.incubator.vector.ByteVector.fromArray(ByteVector.java:3080)
        at Byte128VectorTests.withByte128VectorTests(Byte128VectorTests.java:3755)
        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)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1593)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.AssertionError [in thread "MainThread"]
        at java.base/java.lang.reflect.Field.<init>(Field.java:133)
        at java.base/java.lang.reflect.Field.copy(Field.java:160)
        at java.base/java.lang.reflect.ReflectAccess.copyField(ReflectAccess.java:109)
        at java.base/jdk.internal.reflect.ReflectionFactory.copyField(ReflectionFactory.java:281)
        at java.base/java.lang.Class.getDeclaredField(Class.java:2886)
        at java.base/jdk.internal.vm.vector.VectorSupport$VectorPayloadMF.multiFieldOffset(VectorSupport.java:326)
        at java.base/jdk.internal.vm.vector.VectorSupport$VectorPayloadMF128B.<clinit>(VectorSupport.java:437)
        at java.base/jdk.internal.vm.vector.VectorSupport$VectorPayloadMF.newInstanceFactory(VectorSupport.java:187)
        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.ByteVector$ByteSpecies.dummyVectorMF(ByteVector.java:4314)
        at jdk.incubator.vector/jdk.incubator.vector.ByteVector.fromArray(ByteVector.java:3080)
        at Byte128VectorTests.ABSByte128VectorTests(Byte128VectorTests.java:5227)
        ... 29 more


Did I miss something? 

Thanks,
Xiaohong

Could you please rebase this merge with latest `lworld`, since I merged a fix several days ago on that branch: https://github.com/openjdk/valhalla/pull/860 ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1605860231
PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1605860436


From xgong at openjdk.org  Sun Jun 25 04:16:28 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 25 Jun 2023 04:16:28 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <K79xaNqWjrQ6wEr43e5AjsiHd9XMdcBykJpUhe6YBFc=.6bde741b-7042-42a5-91ff-9ad221b48e0d@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

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

> 281:   jint larval = (jint)*((jint*)&is_larval);
> 282:   // Vector payload value in an aligned adjacent tuple (8, 16, 32 or 64 bytes).
> 283:   return allocate_vector_payload_helper(ik, num_elem, elem_bt, larval, THREAD); // safepoint

I checked method `allocate_vector_payload_helper()`, and I didn't find any fields assignment inside it. Is this right or any further plan to add those assgnment? Besides, I have created a similar fix for the deoptimization: https://github.com/openjdk/valhalla/pull/863. Could you please take a look at it? Maybe we can integrate that change with this merge, or create a separate one if necessary.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/866#discussion_r1241024264


From xgong at openjdk.org  Sun Jun 25 04:21:31 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 25 Jun 2023 04:21:31 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <K79xaNqWjrQ6wEr43e5AjsiHd9XMdcBykJpUhe6YBFc=.6bde741b-7042-42a5-91ff-9ad221b48e0d@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <K79xaNqWjrQ6wEr43e5AjsiHd9XMdcBykJpUhe6YBFc=.6bde741b-7042-42a5-91ff-9ad221b48e0d@github.com>
Message-ID: <pDC2DeF8i4PCFGIQkDwKKC8oFD2-04yUm-3Zd9RrReM=.5e214f21-9bca-4003-a05c-7667c94ed6b2@github.com>

On Sun, 25 Jun 2023 04:13:03 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
>> 
>> Other Fixes addressed:-
>> 
>> A) CDS related: 
>>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>>   
>>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
>> 
>>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
>> 
>> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
>> 
>> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
>> 
>> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
>> 
>> E) De-optimization related:-
>>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
>> 
>>   - nfield count which determines number of field level bookkeeping at Safe...
>
> src/hotspot/share/prims/vectorSupport.cpp line 283:
> 
>> 281:   jint larval = (jint)*((jint*)&is_larval);
>> 282:   // Vector payload value in an aligned adjacent tuple (8, 16, 32 or 64 bytes).
>> 283:   return allocate_vector_payload_helper(ik, num_elem, elem_bt, larval, THREAD); // safepoint
> 
> I checked method `allocate_vector_payload_helper()`, and I didn't find any fields assignment inside it. Is this right or any further plan to add those assgnment? Besides, I have created a similar fix for the deoptimization: https://github.com/openjdk/valhalla/pull/863. Could you please take a look at it? Maybe we can integrate that change with this merge, or create a separate one if necessary.

Oh, I see the followed calling to `Deoptimization::reassign_fields_by_klass()`. An alternative way is to keep the vector assignment in `vectorSupport.cpp` like before, and other fields reassign in `deoptimization.cpp` like other normal objects. So that we doesn't need to modify too much during deoptimization. The only thing we have to do is passing the secondary fields to safepoint if not vectorized. WDYT?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/866#discussion_r1241024761


From xgong at openjdk.org  Sun Jun 25 06:23:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 25 Jun 2023 06:23:29 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <sM_yNf1JbDTOCF_zJAPDJu0U23v-jdFYBommGslMnks=.192d0524-5c86-496a-b405-b5fc4e871036@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

For the scalarization changes on multifields https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L327, you'v assumed that multifields are used for `vector_payload` or `vector_payload_mf` classes. Although it is true currently, it will be more reasonable if we scalarize the `InlineTypeNode` without such assumptions. What about if multifields are used elsewhere?

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1605892299


From xgong at openjdk.org  Sun Jun 25 06:57:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 25 Jun 2023 06:57:30 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <gJhlzYSz027xIynH6zxgbJkvVu5AdFGbFS31sWhJCQo=.816ae699-07bd-4ba6-8ea9-3b0a7d7badc1@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

After payload element type for `VectorShuffle` is changed from `byte` to the same type with vector, following payload classes and the related codes in hotspot are never used and can be removed:


VectorPayloadMF8B
VectorPayloadMF16B
VectorPayloadMF32B

`static bool is_vector_shuffle(Klass* klass)` in `vectorSupport.cpp` is never used and can be removed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1605900341
PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1605900728


From jbhateja at openjdk.org  Sun Jun 25 16:17:30 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 25 Jun 2023 16:17:30 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <Ceeioucb9SeIeCyb5EMiEm3OV6RaNf4dVV8Yj3raB8Q=.adc3b28a-80d0-43ef-836a-526031549914@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> * Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch.

Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606146863


From jbhateja at openjdk.org  Sun Jun 25 16:21:31 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 25 Jun 2023 16:21:31 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <e4CVVlZX9IGDZZxcb0lgDZ6kwoWP-4Ru-ljeP_IO2Vw=.17119696-9c2a-431b-ab5c-17e5e1dec6c6@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

> Could you please rebase this merge with latest `lworld`, since I merged a fix several days ago on that branch: #860 ?

I do not want to make more changes in this merge, can we can address this in next merge ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606148516


From jbhateja at openjdk.org  Sun Jun 25 16:32:28 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 25 Jun 2023 16:32:28 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <sM_yNf1JbDTOCF_zJAPDJu0U23v-jdFYBommGslMnks=.192d0524-5c86-496a-b405-b5fc4e871036@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <sM_yNf1JbDTOCF_zJAPDJu0U23v-jdFYBommGslMnks=.192d0524-5c86-496a-b405-b5fc4e871036@github.com>
Message-ID: <-zfvXbNUPbEXKxnzuWbtqGviYnb49YVNOKVTRN8VLDo=.1cb6339f-d656-4e1e-9044-5a565437def3@github.com>

On Sun, 25 Jun 2023 06:20:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> For the scalarization changes on multifields https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L327, you'v assumed that multifields are used for `vector_payload` or `vector_payload_mf` classes. Although it is true currently, it will be more reasonable if we scalarize the `InlineTypeNode` without such assumptions. What about if multifields are used elsewhere?

Yes, I plan to address this after this merge, currently there is a discrepancy b/w field count returned by _ciInstanceKlass::nof_nonstatic_fields()_  vs  InlineTypeNode::field_count(),  this is because ci* data model directly works over oops data model which is populated by classFileParser, thus a multifield is a regular field  @multifield annotation, its only during c2 parsing we scalarize it. 

We will need to add a new interface to query supported vector size in ciInstance which is implemented by both the compilers, this will be used to return correct field count which matches with IR.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606151091


From jbhateja at openjdk.org  Sun Jun 25 16:48:30 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 25 Jun 2023 16:48:30 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <pDC2DeF8i4PCFGIQkDwKKC8oFD2-04yUm-3Zd9RrReM=.5e214f21-9bca-4003-a05c-7667c94ed6b2@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <K79xaNqWjrQ6wEr43e5AjsiHd9XMdcBykJpUhe6YBFc=.6bde741b-7042-42a5-91ff-9ad221b48e0d@github.com>
 <pDC2DeF8i4PCFGIQkDwKKC8oFD2-04yUm-3Zd9RrReM=.5e214f21-9bca-4003-a05c-7667c94ed6b2@github.com>
Message-ID: <qeFKLpsJt-46H0Gr-W3OTp8Jx0lDEcN7v-AWuSjl4QI=.1daec3b6-3cff-4e65-9abc-8f921d34d4e0@github.com>

On Sun, 25 Jun 2023 04:18:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Oh, I see the followed calling to `Deoptimization::reassign_fields_by_klass()`. An alternative way is to keep the vector assignment in `vectorSupport.cpp` like before, and other fields reassign in `deoptimization.cpp` like other normal objects. So that we doesn't need to modify too much during deoptimization. The only thing we have to do is passing the secondary fields to safepoint if not vectorized. WDYT?

I think is better to completely de-couple allocation and re-assignment so that we have clean interface, having one routine for allocation and re-initialization worked until now because VectorBox could never have a scalar / constant inputs, but this is now relaxed since InlineTypeNodes created during fallback implementation can have non-vector inputs, thus a split in initialization b/w allocation and existing re-assignment routines looks clumsy to me,

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/866#discussion_r1241236430


From xgong at openjdk.org  Mon Jun 26 01:11:28 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 Jun 2023 01:11:28 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <e4CVVlZX9IGDZZxcb0lgDZ6kwoWP-4Ru-ljeP_IO2Vw=.17119696-9c2a-431b-ab5c-17e5e1dec6c6@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <e4CVVlZX9IGDZZxcb0lgDZ6kwoWP-4Ru-ljeP_IO2Vw=.17119696-9c2a-431b-ab5c-17e5e1dec6c6@github.com>
Message-ID: <qHSG2N6K0a9L1wzDgM_7hBXqLU0PFXsvZNvPFkxQTE4=.e0cfa388-bea5-41d7-bdda-d5cb8b18351b@github.com>

On Sun, 25 Jun 2023 16:18:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Could you please rebase this merge with latest `lworld`, since I merged a fix several days ago on that branch: #860 ?
> 
> I do not want to make more changes in this merge, can we can address this in next merge ?

Sure, having a next merge is fine to me. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606385879


From xgong at openjdk.org  Mon Jun 26 01:27:28 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 Jun 2023 01:27:28 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <-zfvXbNUPbEXKxnzuWbtqGviYnb49YVNOKVTRN8VLDo=.1cb6339f-d656-4e1e-9044-5a565437def3@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <sM_yNf1JbDTOCF_zJAPDJu0U23v-jdFYBommGslMnks=.192d0524-5c86-496a-b405-b5fc4e871036@github.com>
 <-zfvXbNUPbEXKxnzuWbtqGviYnb49YVNOKVTRN8VLDo=.1cb6339f-d656-4e1e-9044-5a565437def3@github.com>
Message-ID: <VvQkjFik49BqJ3fReuZsXol8WZg2xXsqR9HcgfNIAzY=.6edb4e37-9506-4dbf-b11f-612e783607e6@github.com>

On Sun, 25 Jun 2023 16:29:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > For the scalarization changes on multifields https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L327, you'v assumed that multifields are used for `vector_payload` or `vector_payload_mf` classes. Although it is true currently, it will be more reasonable if we scalarize the `InlineTypeNode` without such assumptions. What about if multifields are used elsewhere?
> 
> Yes, I plan to address it after this merge, currently there is a discrepancy b/w field count returned by _ciInstanceKlass::nof_nonstatic_fields()_ vs InlineTypeNode::field_count(), this is because ci* data model directly works over oops data model which is populated by classFileParser, thus a multifield is a regular field @multifield annotation, its only during c2 parsing we scalarize it.
> 
> We will need to add a new interface to query supported vector size in ciInstance which is implemented by both the compilers, this will be used to return correct field count which matches with IR.

Could you please take a look at the similar changes in https://github.com/openjdk/valhalla/pull/863/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aea, which I firstly get the `nof_nonstatic_fields()`, and then extend the fields by the secondary fields once the field is a multifield_base.  Adding another interface in `ciInstanceKlass` sounds ok, but I don't think it's a good idea creating several similar interfaces. If the changes in https://github.com/openjdk/valhalla/pull/863 looks fine to you, I can rebase it once this PR is merged.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606396811


From xgong at openjdk.org  Mon Jun 26 01:43:28 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 Jun 2023 01:43:28 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <qeFKLpsJt-46H0Gr-W3OTp8Jx0lDEcN7v-AWuSjl4QI=.1daec3b6-3cff-4e65-9abc-8f921d34d4e0@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <K79xaNqWjrQ6wEr43e5AjsiHd9XMdcBykJpUhe6YBFc=.6bde741b-7042-42a5-91ff-9ad221b48e0d@github.com>
 <pDC2DeF8i4PCFGIQkDwKKC8oFD2-04yUm-3Zd9RrReM=.5e214f21-9bca-4003-a05c-7667c94ed6b2@github.com>
 <qeFKLpsJt-46H0Gr-W3OTp8Jx0lDEcN7v-AWuSjl4QI=.1daec3b6-3cff-4e65-9abc-8f921d34d4e0@github.com>
Message-ID: <a9b65fws-zyRo4q0PgS3tO5ZtObbrkJoiaKBxAa8jV0=.867f7bed-6d54-4c7b-9a25-58e0328d57de@github.com>

On Sun, 25 Jun 2023 16:45:57 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Oh, I see the followed calling to `Deoptimization::reassign_fields_by_klass()`. An alternative way is to keep the vector assignment in `vectorSupport.cpp` like before, and other fields reassign in `deoptimization.cpp` like other normal objects. So that we doesn't need to modify too much during deoptimization. The only thing we have to do is passing the secondary fields to safepoint if not vectorized. WDYT?
>
>> Oh, I see the followed calling to `Deoptimization::reassign_fields_by_klass()`. An alternative way is to keep the vector assignment in `vectorSupport.cpp` like before, and other fields reassign in `deoptimization.cpp` like other normal objects. So that we doesn't need to modify too much during deoptimization. The only thing we have to do is passing the secondary fields to safepoint if not vectorized. WDYT?
> 
> I think its better to completely de-couple allocation and re-assignment so that we have clean interface, having one routine for allocation and re-initialization worked until now because VectorBox could never have a scalar / constant inputs, but this is now relaxed since InlineTypeNodes created during fallback implementation can have non-vector inputs, thus a split in initialization b/w allocation and existing re-assignment routines looks clumsy to me,

OK, I took another look at the changes in deoptimization.cpp, and the solution makes sense to me. Thanks!

BTW, do you think the condition `EnableVectorSupport` applied on the vector and vector_payload_mf classes in `Deoptimize::reasign_fields()` [1] and `Deoptimize::realloc_objects()` [2] can be removed now? Before, we only have the VectorBox cases which depends on this flag, but now, the default implementation also creates vector or scalar ops. 

[1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1548
[2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/866#discussion_r1241369871


From jbhateja at openjdk.org  Mon Jun 26 05:49:33 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Jun 2023 05:49:33 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <JoLiuOwuHudw44Qw1s_8RAn6EM_CN4W_IzOOPWyCk_o=.77e51f4d-98a4-43c3-a988-ec4c51ebc220@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

> > > For the scalarization changes on multifields https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L327, you'v assumed that multifields are used for `vector_payload` or `vector_payload_mf` classes. Although it is true currently, it will be more reasonable if we scalarize the `InlineTypeNode` without such assumptions. What about if multifields are used elsewhere?
> > 
> > 
> > Yes, I plan to address it after this merge, currently there is a discrepancy b/w field count returned by _ciInstanceKlass::nof_nonstatic_fields()_ vs InlineTypeNode::field_count(), this is because ci* data model directly works over oops data model which is populated by classFileParser, thus a multifield is a regular field @multifield annotation, its only during c2 parsing we scalarize it.
> > We will need to add a new interface to query supported vector size in ciInstance which is implemented by both the compilers, this will be used to return correct field count which matches with IR.
> 
> Could you please take a look at the similar changes in https://github.com/openjdk/valhalla/pull/863/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aea, which the compiler firstly get the `nof_nonstatic_fields()`, and then extend the fields by the secondary fields once the field is a multifield_base. Adding another interface in `ciInstanceKlass` sounds ok, but I don't think it's a good idea creating one more similar interface. It already has `nof_nonstatic_fields` and `nof_declared_nonstatic_fields` now.
> 
> If the changes under `hotspot/share/opto` in #863 looks fine to you, I can rebase it once this PR is merged, or you integrate it in this PR. Then I will abandon the 863. WDYT?

Yes, I grepped though the code and currently there are not many occurrences of _"nof_declared_nonstatic_fields"_ and your patch #863 is addressing them,  But having consistency b/w field count returned by ci* object model and C2 IR is also desirable.
BTW, its only C2 which creates Vector IR currently, hence adding a new API  _ciEnv::supports_vector_size(int num_elem, BasicType elem_bt)_  which is implemented by both C1 (returning false) and C2 using _Matcher::vector_size_supported_ may cleanup some code from your patch, WDYT ?

All the ci* query APIs which returns ciField based on offset / index have already been extended to support multifield. But I plan to revisit them after merge patch gets integrated.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606692773


From xgong at openjdk.org  Mon Jun 26 06:35:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 Jun 2023 06:35:30 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <JoLiuOwuHudw44Qw1s_8RAn6EM_CN4W_IzOOPWyCk_o=.77e51f4d-98a4-43c3-a988-ec4c51ebc220@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <JoLiuOwuHudw44Qw1s_8RAn6EM_CN4W_IzOOPWyCk_o=.77e51f4d-98a4-43c3-a988-ec4c51ebc220@github.com>
Message-ID: <s8iua_hTZQS0XDLx8G1dM5YktEh9N8PbAFVvquEICrU=.03f8b6a3-4d7c-4380-b2c1-f32b23d4684f@github.com>

On Mon, 26 Jun 2023 05:46:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > > For the scalarization changes on multifields https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L327, you'v assumed that multifields are used for `vector_payload` or `vector_payload_mf` classes. Although it is true currently, it will be more reasonable if we scalarize the `InlineTypeNode` without such assumptions. What about if multifields are used elsewhere?
> > > 
> > > 
> > > Yes, I plan to address it after this merge, currently there is a discrepancy b/w field count returned by _ciInstanceKlass::nof_nonstatic_fields()_ vs InlineTypeNode::field_count(), this is because ci* data model directly works over oops data model which is populated by classFileParser, thus a multifield is a regular field @multifield annotation, its only during c2 parsing we scalarize it.
> > > We will need to add a new interface to query supported vector size in ciInstance which is implemented by both the compilers, this will be used to return correct field count which matches with IR.
> > 
> > 
> > Could you please take a look at the similar changes in https://github.com/openjdk/valhalla/pull/863/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aea, which the compiler firstly get the `nof_nonstatic_fields()`, and then extend the fields by the secondary fields once the field is a multifield_base. Adding another interface in `ciInstanceKlass` sounds ok, but I don't think it's a good idea creating one more similar interface. It already has `nof_nonstatic_fields` and `nof_declared_nonstatic_fields` now.
> > If the changes under `hotspot/share/opto` in #863 looks fine to you, I can rebase it once this PR is merged, or you integrate it in this PR. Then I will abandon the 863. WDYT?
> 
> Yes, I grepped though the code and currently there are not many occurrences of _"nof_declared_nonstatic_fields"_ and your patch #863 is addressing them, But having consistency b/w field count returned by ci* object model and C2 IR is also desirable. BTW, its only C2 which creates Vector IR currently, hence adding a new API _ciEnv::supports_vector_size(int num_elem, BasicType elem_bt)_ which is implemented by both C1 (returning false) and C2 using _Matcher::vector_size_supported_ may cleanup some code from your patch, WDYT ?
> 
> All the ci* query APIs which returns ciField based on offset / index have already been extended to support multifield. But I plan to revisit them after merge patch gets integrated.

Yes, I agree that adding such an interface can simply many code. However, for the multifield vectorization, it doesn't only need to check the supported vector size, but also the relative ops with the vector size. Do you plan to check these ops as well?  

To clean more, I think it's better to add the multifields to the non_static_fields at the stage of ci field parsing based on the `vector_size_supported`, and so does to the `secondary_fields_count` just like what I did when we tried to scalarize/vectorize the multifields (see: https://github.com/XiaohongGong/valhalla/pull/2/commits/90c5d213ee3abaa17bdac1f40c2614cd1bf9698c#diff-68d9ded9e6db72428f930d6e3d25ad12f804cc3550f7dde862bae0c513358220R97). We have to make sure the `InlineTypeNode::fields_count()` is the same with the declared nonstatic fields from `ciInstanceKlass`. So that in the compiler stage, all things are synced and consistent.  But I think this is a big refactory to multifields and deserved to revisit in future.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606741127


From jbhateja at openjdk.org  Mon Jun 26 07:11:30 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Jun 2023 07:11:30 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <s8iua_hTZQS0XDLx8G1dM5YktEh9N8PbAFVvquEICrU=.03f8b6a3-4d7c-4380-b2c1-f32b23d4684f@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <JoLiuOwuHudw44Qw1s_8RAn6EM_CN4W_IzOOPWyCk_o=.77e51f4d-98a4-43c3-a988-ec4c51ebc220@github.com>
 <s8iua_hTZQS0XDLx8G1dM5YktEh9N8PbAFVvquEICrU=.03f8b6a3-4d7c-4380-b2c1-f32b23d4684f@github.com>
Message-ID: <aO8Ti8TEUAgsIt4wpCSTc_4CE8UApFgNxFOqs7gwkE0=.778b510b-debd-4696-a530-b01d0e78e2a5@github.com>

On Mon, 26 Jun 2023 06:32:23 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > > > > For the scalarization changes on multifields https://github.com/jatin-bhateja/valhalla/blob/84b3b1e11cdef2c870d1f430c7db2ae60f752d5f/src/hotspot/share/opto/inlinetypenode.cpp#L327, you'v assumed that multifields are used for `vector_payload` or `vector_payload_mf` classes. Although it is true currently, it will be more reasonable if we scalarize the `InlineTypeNode` without such assumptions. What about if multifields are used elsewhere?
> > > > 
> > > > 
> > > > Yes, I plan to address it after this merge, currently there is a discrepancy b/w field count returned by _ciInstanceKlass::nof_nonstatic_fields()_ vs InlineTypeNode::field_count(), this is because ci* data model directly works over oops data model which is populated by classFileParser, thus a multifield is a regular field @multifield annotation, its only during c2 parsing we scalarize it.
> > > > We will need to add a new interface to query supported vector size in ciInstance which is implemented by both the compilers, this will be used to return correct field count which matches with IR.
> > > 
> > > 
> > > Could you please take a look at the similar changes in https://github.com/openjdk/valhalla/pull/863/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aea, which the compiler firstly get the `nof_nonstatic_fields()`, and then extend the fields by the secondary fields once the field is a multifield_base. Adding another interface in `ciInstanceKlass` sounds ok, but I don't think it's a good idea creating one more similar interface. It already has `nof_nonstatic_fields` and `nof_declared_nonstatic_fields` now.
> > > If the changes under `hotspot/share/opto` in #863 looks fine to you, I can rebase it once this PR is merged, or you integrate it in this PR. Then I will abandon the 863. WDYT?
> > 
> > 
> > Yes, I grepped though the code and currently there are not many occurrences of _"nof_declared_nonstatic_fields"_ and your patch #863 is addressing them, But having consistency b/w field count returned by ci* object model and C2 IR is also desirable. BTW, its only C2 which creates Vector IR currently, hence adding a new API _ciEnv::supports_vector_size(int num_elem, BasicType elem_bt)_ which is implemented by both C1 (returning false) and C2 using _Matcher::vector_size_supported_ may cleanup some code from your patch, WDYT ?
> > All the ci* query APIs which returns ciField based on offset / index have already been extended to support multifield. But I plan to revisit them after merge patch gets integrated.
> 
> Yes, I agree that adding such an interface can simply many code. However, for the multifield vectorization, it doesn't only need to check the supported vector size, but also the relative ops with the vector size. Do you plan to check these ops as well?
> 
Correct, newly introduced interface should check for Load/Store/BroadCast Operations similar to _InlineTypeNode::is_multifield_scalarized_ 
https://github.com/jatin-bhateja/valhalla/blob/merge_lworld2/src/hotspot/share/opto/inlinetypenode.cpp#L43

> To clean more, I think it's better to add the multifields to the non_static_fields at the stage of ci field parsing based on the `vector_size_supported`, and so does to the `secondary_fields_count` just like what I did when we tried to scalarize/vectorize the multifields (see: [XiaohongGong at 90c5d21#diff-68d9ded9e6db72428f930d6e3d25ad12f804cc3550f7dde862bae0c513358220R97](https://github.com/XiaohongGong/valhalla/commit/90c5d213ee3abaa17bdac1f40c2614cd1bf9698c#diff-68d9ded9e6db72428f930d6e3d25ad12f804cc3550f7dde862bae0c513358220R97)). We have to make sure the `InlineTypeNode::fields_count()` is the same with the declared nonstatic fields from `ciInstanceKlass`. So that in the compiler stage, all things are synced and consistent. But I think this is a big refactory to multifields and deserved to revisit in future.

Yes, as mentioned I will revisit ciField side of handling after merge and will add newly discussed interface so that ci* field count is in sync with C2 IR.
![image](https://github.com/openjdk/valhalla/assets/59989778/80d9792e-f9a0-4cec-a414-f60d7ba4b880)

We are bookkeeping multifield in a special ciMultifield structure currently and  field query  APIs  based on index / offset traverses this structure.  Both offset and index based traversal should perform a linearized walk over this hierarchical structure,  since all the FieldInfo objects now contains unique indices.

JDK-8292818 added a new _index field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6].

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606837477


From xgong at openjdk.org  Mon Jun 26 07:26:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 Jun 2023 07:26:29 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <aO8Ti8TEUAgsIt4wpCSTc_4CE8UApFgNxFOqs7gwkE0=.778b510b-debd-4696-a530-b01d0e78e2a5@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <JoLiuOwuHudw44Qw1s_8RAn6EM_CN4W_IzOOPWyCk_o=.77e51f4d-98a4-43c3-a988-ec4c51ebc220@github.com>
 <s8iua_hTZQS0XDLx8G1dM5YktEh9N8PbAFVvquEICrU=.03f8b6a3-4d7c-4380-b2c1-f32b23d4684f@github.com>
 <aO8Ti8TEUAgsIt4wpCSTc_4CE8UApFgNxFOqs7gwkE0=.778b510b-debd-4696-a530-b01d0e78e2a5@github.com>
Message-ID: <BdzkcKT8pq-w2zlccCigegpfisabeOAKIhXibKFohPc=.f5cefb00-0943-48cc-becf-faad930ac4fd@github.com>

On Mon, 26 Jun 2023 07:06:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Yes, as mentioned I will revisit ciField side of handling after merge and will add newly discussed interface so that ci* field count is in sync with C2 IR.
image
>
> We are bookkeeping multifield in a special ciMultifield structure currently and field query APIs based on index / offset traverses this structure. Both offset and index based traversal should perform a linearized walk over this hierarchical structure, since all the FieldInfo objects now contains unique indices.
>
> JDK-8292818 added a new _index field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6].

Make sense to me. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606861064


From xgong at openjdk.org  Mon Jun 26 07:26:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 Jun 2023 07:26:30 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <GeHo45gumsjWKriHxhZonG8TV8NWulUgLke1yap-cTw=.bf95cafa-fde8-47d3-8115-1a2983b0f1a2@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

I'm fine with this patch except for some comments I added above and the jtreg crashes. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606861912


From jbhateja at openjdk.org  Mon Jun 26 07:43:33 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Jun 2023 07:43:33 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <GeHo45gumsjWKriHxhZonG8TV8NWulUgLke1yap-cTw=.bf95cafa-fde8-47d3-8115-1a2983b0f1a2@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <GeHo45gumsjWKriHxhZonG8TV8NWulUgLke1yap-cTw=.bf95cafa-fde8-47d3-8115-1a2983b0f1a2@github.com>
Message-ID: <cQpZUPqp7De78ruRQwLeTFcuCK8ZdM1Ne8fNmncpqnY=.8b2d57d0-6642-49f9-bef6-496c59461165@github.com>

On Mon, 26 Jun 2023 07:24:21 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> I'm fine with this patch except for some comments I added above and the jtreg crashes. Thanks!

Are you still facing JTREG crashes with -Xshare:off ?  
I ran tests on AVX512 machine with default setting using above flags and most of the test points are passing as mentioned in PR description in all the *VectorTests.


===============================================
jdk/incubator/vector/Float128VectorTests.java
Total tests run: 2565, Passes: 2562, Failures: 3, Skips: 0
===============================================


Failures are of similar kind around masked vector operations and looks like related to de-optimization. 

With UseAVX2 I am also able to reproduces similar issue in stand alone test


// CMD: java -XX:CompileThresholdScaling=0.1 -XX:+TraceDeoptimization -XX:-TieredCompilation -XX:UseAVX=2 -XX:+DeoptimizeALot -Xbatch --add-modules=jdk.incubator.vector -cp . deopt_shuffle_Byte512
import jdk.incubator.vector.*;

class deopt_shuffle_Byte512 {
  public static void leaf(VectorShuffle<?> shuffle) {
     throw new AssertionError(shuffle.toString());
  }
  public static int micro(int [] arr, int ctr) {
      VectorShuffle<?> shuffle = VectorShuffle.fromArray(ByteVector.SPECIES_512, arr, 0);
      if ((ctr % 2500) == 2000) {
          leaf(shuffle);
      }
      return shuffle.laneSource(ctr & (ByteVector.SPECIES_512.length() - 1));
  }
  public static void main(String [] args) {
      long res = 0;
      int [] arr = new int[64];
      for (int i = 0; i < arr.length; i++) {
          arr[i] = 63 - i;
      }
      for (int i = 0; i < 100000; i++) {
          res += micro(arr, i);
      }
      System.out.println("[res] " + res);
  }
}



Exception in thread "main" java.lang.AssertionError: Shuffle[63, 62, 0, 61, 0, 0, 60, 0, 0, 0, 59, 0, 0, 0, 0, 58, 0, 0, 0, 0, 0, 57, 0, 0, 0, 0, 0, 0, 56, 0, 0, 0, 0, 0, 0, 0, 55, 0, 0, 0, 0, 0, 0, 0, 0, 54, 0, 0, 0, 0, 0, 0, 0, 0, 0, 53, 0, 0, 0, 0, 0, 0, 0, 0]
Exception in thread "main" java.lang.AssertionError: Shuffle[63, 62, 61, 60, 59, 58, 57, 56, 55, 54, 53, 52, 51, 50, 49, 48, 47, 46, 45, 44, 43, 42, 41, 40, 39, 38, 37, 36, 35, 34, 33, 32, 31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0]
SHUFFLE_Byte512 FAIL

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606892090


From xgong at openjdk.org  Mon Jun 26 07:52:33 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 Jun 2023 07:52:33 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <cQpZUPqp7De78ruRQwLeTFcuCK8ZdM1Ne8fNmncpqnY=.8b2d57d0-6642-49f9-bef6-496c59461165@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <GeHo45gumsjWKriHxhZonG8TV8NWulUgLke1yap-cTw=.bf95cafa-fde8-47d3-8115-1a2983b0f1a2@github.com>
 <cQpZUPqp7De78ruRQwLeTFcuCK8ZdM1Ne8fNmncpqnY=.8b2d57d0-6642-49f9-bef6-496c59461165@github.com>
Message-ID: <yP3mfYbBZQUvSwrsK9jpUzMGCW7Aim-iCQaSCgFvdB4=.caa89006-d78d-4d16-be6b-ec3fdb6f5db7@github.com>

On Mon, 26 Jun 2023 07:41:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Are you still facing JTREG crashes with -Xshare:off ?

Ohh, I forgot this flag. I will rerun with it. Thanks!

> Failures are of similar kind around masked vector operations and looks like related to de-optimization.

Yes, I met the same incorrectness issue with deoptimization, and did not get the root cause yet. We can look at this issue once your patch is merged.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606901989


From xgong at openjdk.org  Mon Jun 26 08:05:32 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 26 Jun 2023 08:05:32 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <yP3mfYbBZQUvSwrsK9jpUzMGCW7Aim-iCQaSCgFvdB4=.caa89006-d78d-4d16-be6b-ec3fdb6f5db7@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <GeHo45gumsjWKriHxhZonG8TV8NWulUgLke1yap-cTw=.bf95cafa-fde8-47d3-8115-1a2983b0f1a2@github.com>
 <cQpZUPqp7De78ruRQwLeTFcuCK8ZdM1Ne8fNmncpqnY=.8b2d57d0-6642-49f9-bef6-496c59461165@github.com>
 <yP3mfYbBZQUvSwrsK9jpUzMGCW7Aim-iCQaSCgFvdB4=.caa89006-d78d-4d16-be6b-ec3fdb6f5db7@github.com>
Message-ID: <HV-JeOxuuTnlS5jfgd-y2VKIObWjaxD_8AYvpz7tbKo=.fa60f3d8-4d9c-4237-8b02-c380054bc083@github.com>

On Mon, 26 Jun 2023 07:48:38 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Are you still facing JTREG crashes with -Xshare:off ?
> 
> Ohh, I forgot this flag. I will rerun with it. Thanks!
> 
> > Failures are of similar kind around masked vector operations and looks like related to de-optimization.
> 
> Yes, I met the same incorrectness issue with deoptimization, and did not get the root cause yet. We can look at this issue once your patch is merged.

The jtreg crashes are gone with `-Xshare::off`.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1606921774


From mcimadamore at openjdk.org  Mon Jun 26 09:34:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jun 2023 09:34:28 GMT
Subject: Integrated: 8310685: [lw5] adding support for null restricted
 types
In-Reply-To: <331KnN6G7NN3jzxi0sqwRoggDs_TAZTenYyMjSMbtAo=.0d414071-6d3d-41e7-804e-b8cb29a0c092@github.com>
References: <331KnN6G7NN3jzxi0sqwRoggDs_TAZTenYyMjSMbtAo=.0d414071-6d3d-41e7-804e-b8cb29a0c092@github.com>
Message-ID: <ywww7SpN6iZmZnK0mFftuRAkDHz8gfJ7QmhaJ-Tnafg=.f7b315a2-6528-4dc7-ab14-6e85108bf791@github.com>

On Fri, 23 Jun 2023 02:43:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> initial support for null restricted types

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

> 1168:                       * make sure that the caller really wants to warn
> 1169:                       */
> 1170:                      if (s.isNonNullable() && warnStack.head.pos() != null) {

This is a bit odd. We are defining a type relationship - if "BOT" is not a subtype of T! that is fine, we should just return false. Giving an error seems a bit strange here (I don't think it is normal for subtyping to generate errors).

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

> 1244:                     && isSubtypeNoCapture(sup.getEnclosingType(),
> 1245:                                           s.getEnclosingType());
> 1246:                 if (result && warnStack.head.pos() != null && s.hasNarrowerNullabilityThan(t)) {

I have memories of the previous implementation where we discussed maybe keeping subtyping routines as is, but adding some other check to validate the "polarity" of the type arguments. Wouldn't something similar work here too?

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

> 302:     }
> 303: 
> 304:     public void errBangTypes(DiagnosticPosition pos, Error errKey) {

perhaps this can be checkNonNullable?

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

> 2126:         if (tree.lhs.type.isNonNullable()) {
> 2127:             code.emitop0(dup);
> 2128:             genNullCheck(tree.rhs);

Should the null check always be generated even if we know that the RHS is non-nullable? (I'm not sure here)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/872#discussion_r1241890775
PR Review Comment: https://git.openjdk.org/valhalla/pull/872#discussion_r1241892023
PR Review Comment: https://git.openjdk.org/valhalla/pull/872#discussion_r1241892741
PR Review Comment: https://git.openjdk.org/valhalla/pull/872#discussion_r1241895974


From jbhateja at openjdk.org  Mon Jun 26 10:53:04 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Jun 2023 10:53:04 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <v5iBZvnJ0EEkf-T2RypVB5sXEmyjCfNyeO98-cbjTyQ=.9bbd905b-5c8e-4b71-8aaa-b91703a56601@github.com>

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

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

  Review comments resolutions.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/866/files
  - new: https://git.openjdk.org/valhalla/pull/866/files/64ed7ffa..0123a199

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

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

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


From jbhateja at openjdk.org  Mon Jun 26 10:53:06 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Jun 2023 10:53:06 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <HV-JeOxuuTnlS5jfgd-y2VKIObWjaxD_8AYvpz7tbKo=.fa60f3d8-4d9c-4237-8b02-c380054bc083@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <GeHo45gumsjWKriHxhZonG8TV8NWulUgLke1yap-cTw=.bf95cafa-fde8-47d3-8115-1a2983b0f1a2@github.com>
 <cQpZUPqp7De78ruRQwLeTFcuCK8ZdM1Ne8fNmncpqnY=.8b2d57d0-6642-49f9-bef6-496c59461165@github.com>
 <yP3mfYbBZQUvSwrsK9jpUzMGCW7Aim-iCQaSCgFvdB4=.caa89006-d78d-4d16-be6b-ec3fdb6f5db7@github.com>
 <HV-JeOxuuTnlS5jfgd-y2VKIObWjaxD_8AYvpz7tbKo=.fa60f3d8-4d9c-4237-8b02-c380054bc083@github.com>
Message-ID: <KKta9tyAZx33Xr5sQA1tRyhBPUA5XQt-zMUjBuz3i7Q=.d3963bf5-022e-4d83-93b9-840fc5abaa71@github.com>

On Mon, 26 Jun 2023 08:02:17 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> Are you still facing JTREG crashes with -Xshare:off ?
>> 
>> Ohh, I forgot this flag. I will rerun with it. Thanks!
>> 
>>> Failures are of similar kind around masked vector operations and looks like related to de-optimization.
>> 
>> Yes, I met the same incorrectness issue with deoptimization, and did not get the root cause yet. We can look at this issue once your patch is merged.
>
>> > Are you still facing JTREG crashes with -Xshare:off ?
>> 
>> Ohh, I forgot this flag. I will rerun with it. Thanks!
>> 
>> > Failures are of similar kind around masked vector operations and looks like related to de-optimization.
>> 
>> Yes, I met the same incorrectness issue with deoptimization, and did not get the root cause yet. We can look at this issue once your patch is merged.
> 
> The jtreg crashes are gone with `-Xshare::off`.

Hi @XiaohongGong , I have addresses and responded to all comments. Let me know if its good to merge now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1607174619


From jbhateja at openjdk.org  Mon Jun 26 10:53:09 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Jun 2023 10:53:09 GMT
Subject: [lworld+vector] RFR: Merge lworld
In-Reply-To: <gJhlzYSz027xIynH6zxgbJkvVu5AdFGbFS31sWhJCQo=.816ae699-07bd-4ba6-8ea9-3b0a7d7badc1@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <gJhlzYSz027xIynH6zxgbJkvVu5AdFGbFS31sWhJCQo=.816ae699-07bd-4ba6-8ea9-3b0a7d7badc1@github.com>
Message-ID: <3cmf1wkwDny1LQN6w2O3bupiI-gVlfsMnoJV-Nnu6IE=.105cae57-8c4e-42fd-a953-57190307ee4a@github.com>

On Sun, 25 Jun 2023 06:52:27 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> After payload element type for `VectorShuffle` is changed from `byte` to the same type with vector, following payload classes and the related codes in hotspot are never used and can be removed:
> 
> ```
> VectorPayloadMF8B
> VectorPayloadMF16B
> VectorPayloadMF32B
> ```

I have submitted a patch on mainline to backout shuffle related changes citing performance issues JDK-8310459. So these classes may be needed in next mainline merge.

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

PR Comment: https://git.openjdk.org/valhalla/pull/866#issuecomment-1607178195


From jbhateja at openjdk.org  Mon Jun 26 10:53:13 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Jun 2023 10:53:13 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <a9b65fws-zyRo4q0PgS3tO5ZtObbrkJoiaKBxAa8jV0=.867f7bed-6d54-4c7b-9a25-58e0328d57de@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <K79xaNqWjrQ6wEr43e5AjsiHd9XMdcBykJpUhe6YBFc=.6bde741b-7042-42a5-91ff-9ad221b48e0d@github.com>
 <pDC2DeF8i4PCFGIQkDwKKC8oFD2-04yUm-3Zd9RrReM=.5e214f21-9bca-4003-a05c-7667c94ed6b2@github.com>
 <qeFKLpsJt-46H0Gr-W3OTp8Jx0lDEcN7v-AWuSjl4QI=.1daec3b6-3cff-4e65-9abc-8f921d34d4e0@github.com>
 <a9b65fws-zyRo4q0PgS3tO5ZtObbrkJoiaKBxAa8jV0=.867f7bed-6d54-4c7b-9a25-58e0328d57de@github.com>
Message-ID: <gVWXgxasdzzharLTclNabHETuQFEB_8GbSqGk5QW53Y=.958b4bdd-7da4-42e9-b7ca-b47d64060bbf@github.com>

On Mon, 26 Jun 2023 01:38:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> OK, I took another look at the changes in deoptimization.cpp, and the solution makes sense to me. Thanks!
> 
> BTW, do you think the condition `EnableVectorSupport` applied on the vector and vector_payload_mf classes in `Deoptimize::reasign_fields()` [1] and `Deoptimize::realloc_objects()` [2] can be removed now? Before, we only have the VectorBox cases which depends on this flag, but now, the default implementation also creates vector or scalar ops.
> 
> [1] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1548 [2] https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/deoptimization.cpp#L1144

Thanks for suggesting this, ideally we can completely do away with special handling for vector box allocations since general case of instance allocations should suffice,  we are doing two additional things in vector allocations currently

1.  Larval bit setting in mark work of newly allocated oop.
2.  Explicit payload allocation and payload field initialization handling[1] for both flattened and non-flattened case,  but vector payloads always flatten with default InlineFieldMaxFlatSize limit. 

May be after the merge we can cleanup explicit allocation handling for vector boxes since re-assignment is already based on existing infra.

[1] https://github.com/jatin-bhateja/valhalla/blob/merge_lworld2/src/hotspot/share/prims/vectorSupport.cpp#L324

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/866#discussion_r1241971007


From vromero at openjdk.org  Mon Jun 26 17:58:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 26 Jun 2023 17:58:35 GMT
Subject: Integrated: 8310685: [lw5] adding support for null restricted
 types
In-Reply-To: <ywww7SpN6iZmZnK0mFftuRAkDHz8gfJ7QmhaJ-Tnafg=.f7b315a2-6528-4dc7-ab14-6e85108bf791@github.com>
References: <331KnN6G7NN3jzxi0sqwRoggDs_TAZTenYyMjSMbtAo=.0d414071-6d3d-41e7-804e-b8cb29a0c092@github.com>
 <ywww7SpN6iZmZnK0mFftuRAkDHz8gfJ7QmhaJ-Tnafg=.f7b315a2-6528-4dc7-ab14-6e85108bf791@github.com>
Message-ID: <WEHSg02u1BghGcmn-Fy8LRczM64dCW5cGUTqf8b_W1o=.8e896a1f-aa42-4fe6-9e43-92429a47d3a0@github.com>

On Mon, 26 Jun 2023 09:26:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> initial support for null restricted types
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1170:
> 
>> 1168:                       * make sure that the caller really wants to warn
>> 1169:                       */
>> 1170:                      if (s.isNonNullable() && warnStack.head.pos() != null) {
> 
> This is a bit odd. We are defining a type relationship - if "BOT" is not a subtype of T! that is fine, we should just return false. Giving an error seems a bit strange here (I don't think it is normal for subtyping to generate errors).

yep you are right

> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 2128:
> 
>> 2126:         if (tree.lhs.type.isNonNullable()) {
>> 2127:             code.emitop0(dup);
>> 2128:             genNullCheck(tree.rhs);
> 
> Should the null check always be generated even if we know that the RHS is non-nullable? (I'm not sure here)

I'm not sure either, I preferred to stay on the safe side. We can always revisit this later

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/872#discussion_r1242556817
PR Review Comment: https://git.openjdk.org/valhalla/pull/872#discussion_r1242555284


From xgong at openjdk.org  Tue Jun 27 05:46:32 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 27 Jun 2023 05:46:32 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <v5iBZvnJ0EEkf-T2RypVB5sXEmyjCfNyeO98-cbjTyQ=.9bbd905b-5c8e-4b71-8aaa-b91703a56601@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
 <v5iBZvnJ0EEkf-T2RypVB5sXEmyjCfNyeO98-cbjTyQ=.9bbd905b-5c8e-4b71-8aaa-b91703a56601@github.com>
Message-ID: <Tb5HDJCtCOg__vxsEKRJ5H1JP9X-CtnANgRrIrvNBKs=.7220235d-5106-4dda-93c5-fa22406f4a70@github.com>

On Mon, 26 Jun 2023 10:53:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
>> 
>> Other Fixes addressed:-
>> 
>> A) CDS related: 
>>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>>   
>>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
>> 
>>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
>> 
>> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
>> 
>> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
>> 
>> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
>> 
>> E) De-optimization related:-
>>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
>> 
>>   - nfield count which determines number of field level bookkeeping at Safe...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

Looks good to me!

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

Marked as reviewed by xgong (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/866#pullrequestreview-1499981159


From jbhateja at openjdk.org  Tue Jun 27 06:23:42 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 27 Jun 2023 06:23:42 GMT
Subject: [lworld+vector] Integrated: Merge lworld
In-Reply-To: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
References: <hKgJvmjoxSaH-DHriDiRpdToNuoxJOuDfUrdmcris8E=.9d2357ea-cf62-4bc9-9056-dd0c9e29dbfc@github.com>
Message-ID: <nltFwQgUAxykXAr_ET6jzcKqh_xyTKiL251kcMlJdAM=.d1474811-ab5b-4b33-8948-cde2d2b051dd@github.com>

On Thu, 22 Jun 2023 06:47:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector, JDK-8292818 made significant modification to FieldInfo by replacing 96 bits fixed set of metadata fields with UNSIGNED5 compressed fields. 
> 
> Other Fixes addressed:-
> 
> A) CDS related: 
>   - All the _VectorPayloadMF*_ classes are part of java.base modules and thus gets archived into a classes.jsa. 
>   - Code for bookkeeping InlineKlassFixedBlock pointer containing  packing/unpacking adapters, exact bundle size etc. is removed from lworld branch, this causes problem in down stream flow accessing those fields.
>   
>   - InstanceKlass::size method takes into account size of InlineKlassFixedBlock and therefore its contents are already part of shared archive, reinitialized the pointer by making an explicit call to _inlineklass_static_block()_ [1] during unshared field restoration.	
> 
>   - Java class structure [2] contains primaryType (pointer to primitive klass mirrors) and secondaryTypes (pointer to primitive values mirrors), these are no-longer getting restored during shared archive loading at VM startup. These pointer are used for class level equality comparison. As a workaround, using -Xshare:off flag during regression testing, this will be fixed in a follow up patch. 
> 
> B) Removed redundant ResourceMarks during field parsing [3], this was resulting into crashes during re-allocations of  __temp_field_info_ (a GrowableArray) due to __nesting_ level mismatch b/w actual allocation site and re-allocation sites. Re-allocations happens because upfront space reservation for growable array do not take into account multifield bundle size. 
> 
> C) JDK-8292818 added a new __index_ field on top regular fields specified in JVM specification (name_index, signature_index, flags_index, access_index) into FieldInfo structure, handled its initialization while parsing multifield[4], injected[5] and user defined fields[6]. 
> 
> D) Small change in VectorBox creation routine for proper initialization[7] of _declared_nonstatic_fields before accessing it[8]. 
> 
> E) De-optimization related:-
>   - De-coupled[9] allocation and re-assignment during vector box re-materialization leveraging existing re-assignment framework[10]. This prevents introducing special handlings for non-vector Locations in existing routines since an InlineTypeNode may have scalar / vector / constant inputs (scalarized multifield bundle initialization during make_default [11]).
> 
>   - nfield count which determines number of field level bookkeeping at SafePoint was initialized using _ciInlineKlass::...

This pull request has now been integrated.

Changeset: d44617c3
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d44617c37a7e31b6488ce94c24c7dbe04c3d3754
Stats:     1008762 lines in 11193 files changed: 686983 ins; 214214 del; 107565 mod

Merge lworld

Co-authored-by: Xiaohong Gong <xgong at openjdk.org>
Reviewed-by: xgong

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

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


From xgong at openjdk.org  Tue Jun 27 07:25:23 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 27 Jun 2023 07:25:23 GMT
Subject: [lworld+vector] RFR: 8309777: [lworld+vector] Fix re-materialize
 crash for vector objects with un-vectorized multi-fields during
 deoptimization
In-Reply-To: <YYY6johRPmSm1Tbf4Eispzw5PtA0X3OeFDTfYxj5OIM=.430df61f-ffdf-404a-9752-73cd33123595@github.com>
References: <YYY6johRPmSm1Tbf4Eispzw5PtA0X3OeFDTfYxj5OIM=.430df61f-ffdf-404a-9752-73cd33123595@github.com>
Message-ID: <ar4kfW5LUqiRRyrLpQ-cbk15cYfSloOfiKCmy4fIzzc=.79dba42a-3aeb-4d16-b08a-32b532b39ce6@github.com>

On Tue, 20 Jun 2023 06:23:58 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Some vector API jtreg tests crash when running on hardwares that do
>  not support the relative vector species.
> 
> Here is the log:
> 
> 
>   A fatal error has been detected by the Java Runtime Environment:
> 
>   Internal Error (valhalla/src/hotspot/share/prims/vectorSupport.cpp:317), pid=2529357, tid=2529377
>   assert(loc_type == Location::oop || loc_type == Location::narrowoop) failed: expected 'oop'(2) or 'narrowoop'(9) types location but got: 3
> 
>   JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-62ba7fc27)
>   Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-62ba7fc27, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>   Problematic frame:
>   V [[libjvm.so](http://libjvm.so/)+0x1aed828] VectorSupport::allocate_vector_payload(InstanceKlass*, int, BasicType, frame*, RegisterMap*, ObjectValue*, JavaThread*)+0x41
> 
> 
> The root cause is `VectorSupport::allocate_vector_payload` assumes the
>  `ScopeValue` which denotes the field value generated by C2 compiler
>  is a vector or an oop. But after the vector's payload is changed to be
>  the `MultiField` annotated field, the non-static fields of the vector
>  class is changed to be a series of fields with the same primitive type.
>  In C2 compiler, operations for such multi-fields can be vectorized only
>  if the running hardware supports the vector operations for the specified
>  vector size. For such cases, the field value generated by C2 is a vector.
>  Otherwise, the fields are the scalarized primitive type values. Hence
>  the re-materizalization for such vector objects should be handled just
>  like other normal objects.
> 
> To make things right when re-materializing vector objects whose fields
>  are not vectorized, two parts need to be modified:
> 
> 1. In c2 compiler, pass the un-vectorized multi-fields on safepoint when
>  scalaring an `InlineTypeNode`. To try to vectorize the multi-fields in
>  compiler, only the multi-field base is added to the klass's non-static
>  field list. And the other multi-fields are saved in a secondary field list
>  of their multi-field base. So if the multi-fields are not vectorized, all
>  the field members should be found out and passed to the safepoint.
> 
> 2. During deoptimization, re-materialize the vector objects with different
>  routines based on the `ScopeValue` types. That is, go to the `VectorSupport`
>  routine to re-allocate the objects from a vector value, while go to the
>  normal objects re-allocation path if the field value is not a vector.

Since this issue is fixed by https://github.com/openjdk/valhalla/pull/866 which has been merged, close this PR now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/863#issuecomment-1608938948


From xgong at openjdk.org  Tue Jun 27 07:25:24 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 27 Jun 2023 07:25:24 GMT
Subject: [lworld+vector] Withdrawn: 8309777: [lworld+vector] Fix re-materialize
 crash for vector objects with un-vectorized multi-fields during deoptimization
In-Reply-To: <YYY6johRPmSm1Tbf4Eispzw5PtA0X3OeFDTfYxj5OIM=.430df61f-ffdf-404a-9752-73cd33123595@github.com>
References: <YYY6johRPmSm1Tbf4Eispzw5PtA0X3OeFDTfYxj5OIM=.430df61f-ffdf-404a-9752-73cd33123595@github.com>
Message-ID: <XitIw5c152ONHdn6OIbVIYOwWMbrmRepvwH3lX1O24I=.a6176b01-091c-4e1e-8b8a-824987ef53ac@github.com>

On Tue, 20 Jun 2023 06:23:58 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Some vector API jtreg tests crash when running on hardwares that do
>  not support the relative vector species.
> 
> Here is the log:
> 
> 
>   A fatal error has been detected by the Java Runtime Environment:
> 
>   Internal Error (valhalla/src/hotspot/share/prims/vectorSupport.cpp:317), pid=2529357, tid=2529377
>   assert(loc_type == Location::oop || loc_type == Location::narrowoop) failed: expected 'oop'(2) or 'narrowoop'(9) types location but got: 3
> 
>   JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-62ba7fc27)
>   Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-62ba7fc27, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>   Problematic frame:
>   V [[libjvm.so](http://libjvm.so/)+0x1aed828] VectorSupport::allocate_vector_payload(InstanceKlass*, int, BasicType, frame*, RegisterMap*, ObjectValue*, JavaThread*)+0x41
> 
> 
> The root cause is `VectorSupport::allocate_vector_payload` assumes the
>  `ScopeValue` which denotes the field value generated by C2 compiler
>  is a vector or an oop. But after the vector's payload is changed to be
>  the `MultiField` annotated field, the non-static fields of the vector
>  class is changed to be a series of fields with the same primitive type.
>  In C2 compiler, operations for such multi-fields can be vectorized only
>  if the running hardware supports the vector operations for the specified
>  vector size. For such cases, the field value generated by C2 is a vector.
>  Otherwise, the fields are the scalarized primitive type values. Hence
>  the re-materizalization for such vector objects should be handled just
>  like other normal objects.
> 
> To make things right when re-materializing vector objects whose fields
>  are not vectorized, two parts need to be modified:
> 
> 1. In c2 compiler, pass the un-vectorized multi-fields on safepoint when
>  scalaring an `InlineTypeNode`. To try to vectorize the multi-fields in
>  compiler, only the multi-field base is added to the klass's non-static
>  field list. And the other multi-fields are saved in a secondary field list
>  of their multi-field base. So if the multi-fields are not vectorized, all
>  the field members should be found out and passed to the safepoint.
> 
> 2. During deoptimization, re-materialize the vector objects with different
>  routines based on the `ScopeValue` types. That is, go to the `VectorSupport`
>  routine to re-allocate the objects from a vector value, while go to the
>  normal objects re-allocation path if the field value is not a vector.

This pull request has been closed without being integrated.

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

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


From vromero at openjdk.org  Wed Jun 28 04:18:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Jun 2023 04:18:31 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types
Message-ID: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>

addressing some review comments related to PR [1]

[1] https://github.com/openjdk/valhalla/pull/872

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

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

Changes: https://git.openjdk.org/valhalla/pull/880/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=880&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310905
  Stats: 63 lines in 6 files changed: 30 ins; 12 del; 21 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 Jun 28 04:18:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Jun 2023 04:18:32 GMT
Subject: RFR: 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: <2B7O2qzZqO73oAOM8rfnLaaUcFtqutAoh-GN2UT1aT8=.8334c208-079a-4a43-ac0a-8db620b7065f@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

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

> 544:             sb.append(hashCode());
> 545:         }
> 546:         if (isNullable()) {

strictly speaking currently we should only have the non-nullable case but I have provided the rest for completeness

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

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


From vromero at openjdk.org  Wed Jun 28 20:50:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 28 Jun 2023 20:50:21 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v2]
In-Reply-To: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
Message-ID: <oy7Pn2RxFGdUHpdDM79gzQmkxKIOlC2-meAk8S-sYAE=.a4158233-a7f7-42c0-b08c-f531f240c563@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 more review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/880/files
  - new: https://git.openjdk.org/valhalla/pull/880/files/f28c4d08..dd3fcccf

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

  Stats: 91 lines in 2 files changed: 41 ins; 33 del; 17 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 mcimadamore at openjdk.org  Thu Jun 29 00:33:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 29 Jun 2023 00:33:15 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v2]
In-Reply-To: <oy7Pn2RxFGdUHpdDM79gzQmkxKIOlC2-meAk8S-sYAE=.a4158233-a7f7-42c0-b08c-f531f240c563@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <oy7Pn2RxFGdUHpdDM79gzQmkxKIOlC2-meAk8S-sYAE=.a4158233-a7f7-42c0-b08c-f531f240c563@github.com>
Message-ID: <gdWeKuDlc6HTTSNJkY3ibLX62tA7No4L8MOGq9SOCNo=.9acc5e17-d2a0-48dc-9fa8-2c20ac9a4010@github.com>

On Wed, 28 Jun 2023 20:50:21 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 more review comments

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

> 1300:             @Override
> 1301:             public Boolean visitType(Type t, Type s) {
> 1302:                 if (differentNullability.apply(t, s)) {

Is this truly a recursive visitor? I'm wondering, because if you don't need the visitor capabilities, then you could just drop the use of lambdas which will make the code a bit cleaner. E.g. instead of:

nullabilityComparator.reset((t1, t2) -> !t1.sameNullabilityAs(t2))
                            .visit(s, t);

do:

if (!s.sameNullabilityAs(t)) {
     nullabilityComparator.warn(...);
}

In which case, maybe NullabilityComparator is just NullabilityWarner?

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

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


From vromero at openjdk.org  Thu Jun 29 01:03:19 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 29 Jun 2023 01:03:19 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v2]
In-Reply-To: <gdWeKuDlc6HTTSNJkY3ibLX62tA7No4L8MOGq9SOCNo=.9acc5e17-d2a0-48dc-9fa8-2c20ac9a4010@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
 <oy7Pn2RxFGdUHpdDM79gzQmkxKIOlC2-meAk8S-sYAE=.a4158233-a7f7-42c0-b08c-f531f240c563@github.com>
 <gdWeKuDlc6HTTSNJkY3ibLX62tA7No4L8MOGq9SOCNo=.9acc5e17-d2a0-48dc-9fa8-2c20ac9a4010@github.com>
Message-ID: <414VkIiK4bPyeLh3knh2Mk_XXNrroCity86XySc6_f0=.4d7f4633-32d8-4a77-b92a-0a94ecf08239@github.com>

On Thu, 29 Jun 2023 00:30:43 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 more review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1302:
> 
>> 1300:             @Override
>> 1301:             public Boolean visitType(Type t, Type s) {
>> 1302:                 if (differentNullability.apply(t, s)) {
> 
> Is this truly a recursive visitor? I'm wondering, because if you don't need the visitor capabilities, then you could just drop the use of lambdas which will make the code a bit cleaner. E.g. instead of:
> 
> nullabilityComparator.reset((t1, t2) -> !t1.sameNullabilityAs(t2))
>                             .visit(s, t);
> 
> do:
> 
> if (!s.sameNullabilityAs(t)) {
>      nullabilityComparator.warn(...);
> }
> 
> In which case, maybe NullabilityComparator is just NullabilityWarner?

yes the visitor is needed, I found other test cases for which this approach is not enough, I will be adding another iteration with more test cases

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

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


From Xiaohong.Gong at arm.com  Fri Jun 30 07:04:07 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Fri, 30 Jun 2023 07:04:07 +0000
Subject: Question on the inline type flattening decision
Message-ID: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>

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/classfile/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/20230630/27df5c54/attachment.htm>

From frederic.parain at oracle.com  Fri Jun 30 13:27:40 2023
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 30 Jun 2023 09:27:40 -0400
Subject: Question on the inline type flattening decision
In-Reply-To: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
References: <GVXPR08MB7750D3D4B3D73DC996AAE02BF52AA@GVXPR08MB7750.eurprd08.prod.outlook.com>
Message-ID: <ef6e70fb-5fba-3f2e-c7f7-827ce9addc85@oracle.com>

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/classfile/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 vromero at openjdk.org  Fri Jun 30 17:55:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 30 Jun 2023 17:55:35 GMT
Subject: RFR: 8310905: [lw5] addressing review comments on null restricted
 types [v3]
In-Reply-To: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
References: <zpp2exr-_OxRPsHO9nlSlOKYFfoddANsVtNptLeJ71g=.0fdef706-a090-4e9d-821c-139a93633832@github.com>
Message-ID: <KD1yMOagZgxvpeIdHzR_WpBXnvFEqmUrb487Ayp-2ZY=.9223f32b-58f5-434c-9418-5f184c02b7ea@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 methods to NullabilityComparator visitor, adding more test cases

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

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

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

  Stats: 186 lines in 3 files changed: 177 ins; 0 del; 9 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 lomakin.andrey at gmail.com  Mon Jun 12 13:58:46 2023
From: lomakin.andrey at gmail.com (Andrii Lomakin)
Date: Mon, 12 Jun 2023 13:58:46 -0000
Subject: Usage of stack pointers
In-Reply-To: <a2ce66e8-bed3-6565-2475-8f47dd487bd6@oracle.com>
References: <CAJmD-=6TvyZpsCDwxM7qhOg_W4mm1=GQXHVjK1L7WzytgPxOPg@mail.gmail.com>
 <a2ce66e8-bed3-6565-2475-8f47dd487bd6@oracle.com>
Message-ID: <CAJmD-=4AAs=6p-QuFGk_86HQGGsbgBuW-GmLOO4DPUeNomQ6uw@mail.gmail.com>

Got it, thanks!

On Mon, Jun 12, 2023 at 3:40?PM Tobias Hartmann <tobias.hartmann at oracle.com>
wrote:

> Hi Andrii,
>
> Ideally, hot methods are C2 compiled and therefore heap allocation /
> copying is only required when
> storing into containers.
>
> Stack allocation support for C2 has been proposed before [1] and is out of
> scope of this project.
>
> Best regards,
> Tobias
>
> [1]
> https://github.com/microsoft/openjdk-proposals/blob/main/stack_allocation/Stack_Allocation_JEP.md
>
>
> On 24.05.23 08:54, Andrey Lomakin wrote:
> > Hi guys.
> >
> > I don't know whether it is the correct mailing list to ask, but I will
> try it.
> >
> > If I got JEP correctly, value objects are inlined in case of usage of
> the C2 compiler if they are
> > passed as function arguments. It means that we will have an overhead of
> copying data. So likely,
> > this optimization will depend on the size of the value object. But what
> about passing the stack
> > pointer with the ability to convert stack-based value objects into heap
> objects if the passed
> > references leak the called method?
> >
> > Are such optimizations considered or possible?
> >
> > --
> > Best regards,
> > Andrii Lomakin.
> >
>


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

From Xiaohong.Gong at arm.com  Thu Jun 29 02:48:48 2023
From: Xiaohong.Gong at arm.com (Xiaohong Gong)
Date: Thu, 29 Jun 2023 02:48:48 -0000
Subject: Question on the inline type flattening decision
Message-ID: <GVXPR08MB775032DDE40F58751CAFD289F525A@GVXPR08MB7750.eurprd08.prod.outlook.com>

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/classfile/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/20230629/69ed86f4/attachment.htm>