From dsimms at openjdk.org  Mon Oct  2 08:33:41 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 2 Oct 2023 08:33:41 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <6z-L5jByauAFtGD7PS0OXhpV0VakAnR87UfObCRKubk=.6b06494c-c488-4bcf-94c0-1ea3597955f7@github.com>
References: <6z-L5jByauAFtGD7PS0OXhpV0VakAnR87UfObCRKubk=.6b06494c-c488-4bcf-94c0-1ea3597955f7@github.com>
Message-ID: <K8S9Y79EVx16CJJzuHV3XuK6eghlXI_l15J89FAxpa4=.cd10ea5b-c0c6-4dd1-bfc2-2476d54f00ff@github.com>

On Wed, 27 Sep 2023 12:47:01 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+9

This pull request has now been integrated.

Changeset: 40b2e61d
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/40b2e61d35cdc3ba4586592fb71fec345bdd63df
Stats:     9930 lines in 357 files changed: 5425 ins; 2140 del; 2365 mod

Merge jdk

Merge jdk-22+9

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

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


From dsimms at openjdk.org  Tue Oct  3 08:58:03 2023
From: dsimms at openjdk.org (David Simms)
Date: Tue, 3 Oct 2023 08:58:03 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <9lw54hzKWEIpQ17zx7baOjzI4gNw3cLUdEISNumtHdU=.c49ba197-4c1b-4c65-8aca-08b60fdb93b4@github.com>

Merge jdk-22+10

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

Commit messages:
 - Deferred test failures problem listed
 - Merge tag 'jdk-22+10' into lworld_merge_jdk_22_10_incr
 - 8308843: Generational ZGC: Remove gc/z/TestHighUsage.java
 - 8313768: Reduce interaction with volatile field in j.u.l.StreamHandler
 - 8314075: Update JCov version for JDK 22
 - 8307184: Incorrect/inconsistent specification and implementation for Elements.getDocComment
 - 8313693: Introduce an internal utility for the Damerau?Levenshtein distance calculation
 - 8314022: Problem-list tests failing with jtreg 7.3
 - 8288936: Wrong lock ordering writing G1HeapRegionTypeChange JFR event
 - 8311170: Simplify and modernize equals and hashCode in security area
 - ... and 69 more: https://git.openjdk.org/valhalla/compare/40b2e61d...c3b615c6

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

Changes: https://git.openjdk.org/valhalla/pull/932/files
  Stats: 13187 lines in 635 files changed: 5134 ins; 4070 del; 3983 mod
  Patch: https://git.openjdk.org/valhalla/pull/932.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/932/head:pull/932

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


From vromero at openjdk.org  Tue Oct  3 17:45:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Oct 2023 17:45:22 GMT
Subject: Integrated: Merge lworld
Message-ID: <7IKl4Ardt671WFAwbTZGpqZ_oyumgmgG2dAZDm2k3d0=.48c833b6-39c6-4832-9655-49c6b48cc947@github.com>

Merge branch 'lworld' into lw5

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - 8316561: [lw5] class file attribute NullRestricted shouldn't be generated for arrays
 - 8316325: [lw5] sync javac with the current JVMS, particularly assertions on new class attributes
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - 8314913: [lw5] null restrictions can only be applied to value classes
 - 8314899: [lw5] rename j.l.NonAtomic to j.l.LooselyConsistentValue
 - Merge lworld
 - 8314181: [lw5] the check for illegal circularity should only be done if value classes are available
 - ... and 21 more: https://git.openjdk.org/valhalla/compare/40b2e61d...4d884ccd

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

Changes: https://git.openjdk.org/valhalla/pull/933/files
  Stats: 7166 lines in 263 files changed: 4432 ins; 1760 del; 974 mod
  Patch: https://git.openjdk.org/valhalla/pull/933.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/933/head:pull/933

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


From vromero at openjdk.org  Tue Oct  3 17:45:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Oct 2023 17:45:24 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <7IKl4Ardt671WFAwbTZGpqZ_oyumgmgG2dAZDm2k3d0=.48c833b6-39c6-4832-9655-49c6b48cc947@github.com>
References: <7IKl4Ardt671WFAwbTZGpqZ_oyumgmgG2dAZDm2k3d0=.48c833b6-39c6-4832-9655-49c6b48cc947@github.com>
Message-ID: <Men-5DALF-vFfnkx292sYLNVYBq3wmWdIasRtu_Sju0=.0688c5cc-448e-45a6-b222-7968adf10b25@github.com>

On Tue, 3 Oct 2023 17:37:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5

This pull request has now been integrated.

Changeset: dc715159
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/dc715159feda32945d5c2351ede9c6be04a64d6f
Stats:     10206 lines in 390 files changed: 5426 ins; 2140 del; 2640 mod

Merge lworld

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

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


From vromero at openjdk.org  Tue Oct  3 18:37:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Oct 2023 18:37:46 GMT
Subject: RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield
Message-ID: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>

This PR is removing bytecods vnew, aconst_init, and withfield. Some tests will have to be ignored as for them to pass some changes need to be made to the verifier which still expects value classes to have factory methods (vnew)

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

Commit messages:
 - Merge branch 'lw5' into JDK-8316628
 - 8316628: [lw5] remove vnew, aconst_init, and withfield

Changes: https://git.openjdk.org/valhalla/pull/934/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316628
  Stats: 1071 lines in 44 files changed: 1 ins; 944 del; 126 mod
  Patch: https://git.openjdk.org/valhalla/pull/934.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/934/head:pull/934

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


From vromero at openjdk.org  Tue Oct  3 22:09:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Oct 2023 22:09:27 GMT
Subject: RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield [v2]
In-Reply-To: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
References: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
Message-ID: <j51xRdVFtLiwyBbYyYA2FZo17Xjy5u_BuZw5AuwB-yE=.39f16433-4014-415c-9383-2c4e5c93aaf8@github.com>

> This PR is removing bytecods vnew, aconst_init, and withfield. Some tests will have to be ignored as for them to pass some changes need to be made to the verifier which still expects value classes to have factory methods (vnew)

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

  ignoring failing tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/934/files
  - new: https://git.openjdk.org/valhalla/pull/934/files/58fe0044..9681a053

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

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

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


From vromero at openjdk.org  Tue Oct  3 23:12:54 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Oct 2023 23:12:54 GMT
Subject: RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield [v3]
In-Reply-To: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
References: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
Message-ID: <nr2zJN4E1IMs6A45jIfQBeAApSruiGOwsO8x2-21u4o=.a26a4d27-982f-481a-ae73-1e4bd1dbc6ed@github.com>

> This PR is removing bytecods vnew, aconst_init, and withfield. Some tests will have to be ignored as for them to pass some changes need to be made to the verifier which still expects value classes to have factory methods (vnew)

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

  minor change to jvm.ClassWriter

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/934/files
  - new: https://git.openjdk.org/valhalla/pull/934/files/9681a053..513928d8

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

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

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


From vromero at openjdk.org  Tue Oct  3 23:24:00 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Oct 2023 23:24:00 GMT
Subject: RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield [v4]
In-Reply-To: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
References: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
Message-ID: <Vd-0xFvvn6NOcElOmstcWW4YpMcjZKlIil-tNV8XaoY=.fe84ab8a-a2ab-4d90-b170-47ce375097c9@github.com>

> This PR is removing bytecods vnew, aconst_init, and withfield. Some tests will have to be ignored as for them to pass some changes need to be made to the verifier which still expects value classes to have factory methods (vnew)

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

  minor fixes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/934/files
  - new: https://git.openjdk.org/valhalla/pull/934/files/513928d8..1f774515

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

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

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


From vromero at openjdk.org  Tue Oct  3 23:24:01 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 3 Oct 2023 23:24:01 GMT
Subject: Integrated: 8316628: [lw5] remove vnew, aconst_init, and withfield
In-Reply-To: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
References: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
Message-ID: <oSlnTRHxibPt692d-cMKSE71FRtRRm2HeQISeKLD1wo=.ba092365-96cd-4041-9834-d8121a92f8a0@github.com>

On Tue, 3 Oct 2023 18:28:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is removing bytecods vnew, aconst_init, and withfield. Some tests will have to be ignored as for them to pass some changes need to be made to the verifier which still expects value classes to have factory methods (vnew)

This pull request has now been integrated.

Changeset: ec05d377
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ec05d3777b5ffcf3f55943952484c74a6b54046b
Stats:     1150 lines in 114 files changed: 77 ins; 949 del; 124 mod

8316628: [lw5] remove vnew, aconst_init, and withfield

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

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


From dsimms at openjdk.org  Wed Oct  4 06:36:04 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 4 Oct 2023 06:36:04 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <9lw54hzKWEIpQ17zx7baOjzI4gNw3cLUdEISNumtHdU=.c49ba197-4c1b-4c65-8aca-08b60fdb93b4@github.com>
References: <9lw54hzKWEIpQ17zx7baOjzI4gNw3cLUdEISNumtHdU=.c49ba197-4c1b-4c65-8aca-08b60fdb93b4@github.com>
Message-ID: <09HyEYFj3bKHSSAKKLc7HYvIHZRVhRzeTb9At04QY3Y=.44208827-858b-4fab-9832-42ca1c435657@github.com>

On Tue, 3 Oct 2023 08:47:05 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+10

This pull request has now been integrated.

Changeset: 39426cf6
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/39426cf6a66128c14d48ed3d9416f84fb86d4e03
Stats:     13187 lines in 635 files changed: 5134 ins; 4070 del; 3983 mod

Merge jdk

Merge jdk-22+10

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

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


From dsimms at openjdk.org  Wed Oct  4 09:18:08 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 4 Oct 2023 09:18:08 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <OyigmqdPt3wvcuZnACLRhLRKCQSEETSoqDi-xwVYV58=.91f2f018-3a8d-4b53-a2f7-7c4f268cd1b5@github.com>

Merge tag 'jdk-22+11' into lworld_merge_jdk_22_11
Added tag jdk-22+11 for changeset b32d6411

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

Commit messages:
 - Merge tag 'jdk-22+11' into lworld_merge_jdk_22_11
 - 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base
 - 8313765: Invalid CEN header (invalid zip64 extra data field size)
 - 8310275: Bug in assignment operator of ReservedMemoryRegion
 - 8314144: gc/g1/ihop/TestIHOPStatic.java fails due to extra concurrent mark with -Xcomp
 - 8314209: Wrong @since tag for RandomGenerator::equiDoubles
 - 8314211: Add NativeLibraryUnload event
 - 8313760: [REDO] Enhance AES performance
 - 8313720: C2 SuperWord: wrong result with -XX:+UseVectorCmov -XX:+UseCMoveUnconditionally
 - 8314262: GHA: Cut down cross-compilation sysroots deeper
 - ... and 69 more: https://git.openjdk.org/valhalla/compare/39426cf6...c90b3bf1

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

Changes: https://git.openjdk.org/valhalla/pull/935/files
  Stats: 9169 lines in 330 files changed: 5447 ins; 694 del; 3028 mod
  Patch: https://git.openjdk.org/valhalla/pull/935.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/935/head:pull/935

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


From dsimms at openjdk.org  Fri Oct  6 07:50:12 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 6 Oct 2023 07:50:12 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <OyigmqdPt3wvcuZnACLRhLRKCQSEETSoqDi-xwVYV58=.91f2f018-3a8d-4b53-a2f7-7c4f268cd1b5@github.com>
References: <OyigmqdPt3wvcuZnACLRhLRKCQSEETSoqDi-xwVYV58=.91f2f018-3a8d-4b53-a2f7-7c4f268cd1b5@github.com>
Message-ID: <dneTepJrnSxIeV6csvPgTe5WwHAezNtRKkCJi4pQLx8=.597f9f7d-db73-442f-880c-e51cf09e8772@github.com>

On Wed, 4 Oct 2023 09:07:20 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-22+11' into lworld_merge_jdk_22_11
> Added tag jdk-22+11 for changeset b32d6411

This pull request has now been integrated.

Changeset: 9beecaef
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9beecaef3145afc580904dede557aa7faa3debd7
Stats:     9169 lines in 330 files changed: 5447 ins; 694 del; 3028 mod

Merge jdk

jdk-22+11

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

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


From duke at openjdk.org  Fri Oct  6 18:26:34 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 6 Oct 2023 18:26:34 GMT
Subject: RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield [v4]
In-Reply-To: <Vd-0xFvvn6NOcElOmstcWW4YpMcjZKlIil-tNV8XaoY=.fe84ab8a-a2ab-4d90-b170-47ce375097c9@github.com>
References: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
 <Vd-0xFvvn6NOcElOmstcWW4YpMcjZKlIil-tNV8XaoY=.fe84ab8a-a2ab-4d90-b170-47ce375097c9@github.com>
Message-ID: <QsH8YWcOcldyK7Zg5L3segPOERyVaGI6ixlrw73t_vM=.674f87a7-e21e-4dda-a46d-c1570b76470c@github.com>

On Tue, 3 Oct 2023 23:24:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This PR is removing bytecods vnew, aconst_init, and withfield. Some tests will have to be ignored as for them to pass some changes need to be made to the verifier which still expects value classes to have factory methods (vnew)
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor fixes

I?still?think that?having a?magic `static?T.<new>:(?)T` factory?method for?every `T.<init>:(?)V`?method, which?would do?the?`new`, `dup`,?`<init>`?dance behind?the?scenes, would?be a?good?idea.[^1]

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

This?would?allow the?`new`?bytecode to?eventually?go the?way of?`jsr`/`ret`, and?`<init>:(?)V` would?become a?method?called by?the?VM, similarly?to?`<clinit>:()V`, except?that `<init>:(?)V` allows?calling `super.<init>:(?)V`.


[^1]: This?has?been suggested?in:
https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-July/002342.html
https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-July/002343.html

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

PR Comment: https://git.openjdk.org/valhalla/pull/934#issuecomment-1751223717


From forax at univ-mlv.fr  Fri Oct  6 20:12:43 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 6 Oct 2023 22:12:43 +0200 (CEST)
Subject: RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield [v4]
In-Reply-To: <QsH8YWcOcldyK7Zg5L3segPOERyVaGI6ixlrw73t_vM=.674f87a7-e21e-4dda-a46d-c1570b76470c@github.com>
References: <X30nOwZ8XCLvfKBXBZBwdYNaGMB5j1YBNd6FrYBi-HA=.14f3943d-7883-4c08-8778-674513a07aba@github.com>
 <Vd-0xFvvn6NOcElOmstcWW4YpMcjZKlIil-tNV8XaoY=.fe84ab8a-a2ab-4d90-b170-47ce375097c9@github.com>
 <QsH8YWcOcldyK7Zg5L3segPOERyVaGI6ixlrw73t_vM=.674f87a7-e21e-4dda-a46d-c1570b76470c@github.com>
Message-ID: <652515891.15666580.1696623163305.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Archie L. Cobbs" <duke at openjdk.org>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Friday, October 6, 2023 8:26:34 PM
> Subject: Re: RFR: 8316628: [lw5] remove vnew, aconst_init, and withfield [v4]

> On Tue, 3 Oct 2023 23:24:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:
> 
>>> This PR is removing bytecods vnew, aconst_init, and withfield. Some tests will
>>> have to be ignored as for them to pass some changes need to be made to the
>>> verifier which still expects value classes to have factory methods (vnew)
>>
>> Vicente Romero has updated the pull request incrementally with one additional
>> commit since the last revision:
>> 
>>   minor fixes
> 
> I?still?think that?having a?magic `static?T.<new>:(?)T` factory?method for?every
> `T.<init>:(?)V`?method, which?would do?the?`new`, `dup`,?`<init>`?dance behind
> ?the?scenes, would?be a?good?idea.[^1]
> 
> --------------------------------------------------------------------------------
> 
> This?would?allow the?`new`?bytecode to?eventually?go the?way of?`jsr`/`ret`, and
> ?`<init>:(?)V` would?become a?method?called by?the?VM, similarly?to
> ?`<clinit>:()V`, except?that `<init>:(?)V` allows?calling `super.<init>:(?)V`.

Hello,
a lot of us in the Valhalla EG would like to deprecate the "new dup init" dance. But if you take a closer look, this is really hard in term of engineering for a small return.

Unlike jsr/ret, the instance construction/initialization protocol requires cooperation of both the call site and the declaration site.
What you are suggesting required to update both sites but because Java allows separate compilation, we will have to deal with all 4 configurations (none are updated, they are all updated, call site only is updated, declaration site only is updated).

If you try to run some examples that are using inheritance like you have 3 classes that inherits one from the other and only the class in the middle is recompiled, it rapidly becomes a nightmare.
And you have update all the consumers of bytecodes, not only the VM but also javac, a debugger, a Java agents, etc. 

So what you are asking is the size of moving from Python 2 to Python 3. It's not going to happen.

regards,
R?mi

> 
> 
> [^1]: This?has?been suggested?in:
> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-July/002342.html
> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-July/002343.html
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/valhalla/pull/934#issuecomment-1751223717


From xgong at openjdk.org  Sat Oct  7 09:21:03 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sat, 7 Oct 2023 09:21:03 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
In-Reply-To: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
Message-ID: <qUVbP-PEPDX6tE1nLbRmqr_z46zqeHeY6LYQlY9WSxM=.72ec69d9-f230-4787-b324-7bd7ae101324@github.com>

On Thu, 28 Sep 2023 18:02:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Patch adds MaxSpecies support for all types of vectors.
> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
> - Disable CDS archiving of VectorPayload classes.
> - Summary of high level flow :-
>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Great job @jatin-bhateja! Thanks! I will go through the details soon.

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1751651537


From xgong at openjdk.org  Sun Oct  8 02:04:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 8 Oct 2023 02:04:29 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
In-Reply-To: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
Message-ID: <eU7_eGABayDyVvnYJjig1DtYpZaoLiee6JZf3U-bmO0=.ab58ab1e-52c2-43a9-8062-a27fc08e662b@github.com>

On Thu, 28 Sep 2023 18:02:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Patch adds MaxSpecies support for all types of vectors.
> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
> - Disable CDS archiving of VectorPayload classes.
> - Summary of high level flow :-
>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

I met a new JVM crash issues on ARM Neon platform with this PR. Log is:

test IntMaxVectorLoadStoreTests.loadArrayMaskIOOBE(int[i * 5], l + speciesl + 1, mask[false]): success
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (valhalla/src/hotspot/share/opto/type.cpp:4177), pid=1739617, tid=1739655
#  assert(!flat_array || can_be_inline_type()) failed: Only inline types can be flat in array
#
# JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-b575ef0fa)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-b575ef0fa, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x18697d0]  TypeInstPtr::TypeInstPtr(TypePtr::PTR, ciKlass*, TypePtr::InterfaceSet const&, bool, ciObject*, Type::Offset, bool, int, TypePtr const*, int)+0x15c


And a regression in `DoubleMaxVectorTests` such as:

test DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(double[cornerCaseValue(i)], mask[i % 2]): failure
java.lang.AssertionError: expected [true] but found [false]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:819)
        at org.testng.Assert.assertEquals(Assert.java:829)
        at DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(DoubleMaxVectorTests.java:2716)
        ...

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1751891648


From xgong at openjdk.org  Sun Oct  8 02:13:32 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Sun, 8 Oct 2023 02:13:32 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
In-Reply-To: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
Message-ID: <xTO-bBsW6H0SXFrY1KtjFcuX14aRwbCV6L4fZll9510=.ac32de81-a268-4820-a1df-9bb692ac26b3@github.com>

On Thu, 28 Sep 2023 18:02:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Patch adds MaxSpecies support for all types of vectors.
> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
> - Disable CDS archiving of VectorPayload classes.
> - Summary of high level flow :-
>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

src/hotspot/share/ci/ciObjectFactory.cpp line 55:

> 53: #include "memory/universe.hpp"
> 54: #include "oops/oop.inline.hpp"
> 55: #include "prims/vectorSupport.hpp"

Not used and revert it?

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

> 141:   static int  max_vector_size(BasicType bt);
> 142:   static int  get_max_multifield_count(const Symbol* payload_name);
> 143:   static bool is_vector_payload(const Symbol* metadata);

`is_vector_payload` is not used and can be removed?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1349609459
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1349609426


From jbhateja at openjdk.org  Mon Oct  9 02:31:19 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Oct 2023 02:31:19 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
In-Reply-To: <eU7_eGABayDyVvnYJjig1DtYpZaoLiee6JZf3U-bmO0=.ab58ab1e-52c2-43a9-8062-a27fc08e662b@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <eU7_eGABayDyVvnYJjig1DtYpZaoLiee6JZf3U-bmO0=.ab58ab1e-52c2-43a9-8062-a27fc08e662b@github.com>
Message-ID: <vhMKpvnQlBGFOavFCjzu4RdYnI1fK2UWhMNmiWTr1sA=.a73d2c3c-21c9-4e47-a3ed-437492e19381@github.com>

On Sun, 8 Oct 2023 01:58:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> I met a new JVM crash issues on ARM Neon platform with this PR. Log is:
> 
> ```
> test IntMaxVectorLoadStoreTests.loadArrayMaskIOOBE(int[i * 5], l + speciesl + 1, mask[false]): success
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (valhalla/src/hotspot/share/opto/type.cpp:4177), pid=1739617, tid=1739655
> #  assert(!flat_array || can_be_inline_type()) failed: Only inline types can be flat in array
> #
> # JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-b575ef0fa)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-b575ef0fa, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # V  [libjvm.so+0x18697d0]  TypeInstPtr::TypeInstPtr(TypePtr::PTR, ciKlass*, TypePtr::InterfaceSet const&, bool, ciObject*, Type::Offset, bool, int, TypePtr const*, int)+0x15c
> ```
> 
> And a regression in `DoubleMaxVectorTests` such as:
> 
> ```
> test DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(double[cornerCaseValue(i)], mask[i % 2]): failure
> java.lang.AssertionError: expected [true] but found [false]
>         at org.testng.Assert.fail(Assert.java:99)
>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>         at org.testng.Assert.assertEquals(Assert.java:122)
>         at org.testng.Assert.assertEquals(Assert.java:819)
>         at org.testng.Assert.assertEquals(Assert.java:829)
>         at DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(DoubleMaxVectorTests.java:2716)
>         ...
> ```

Correct, we do have some assertions which I also observed, initial root causes shows these are due to incorrect graph shape, was planning to address it in follow up patch. Let me know after more analysis.

![image](https://github.com/openjdk/valhalla/assets/59989778/32a8e2d2-78ef-4ab1-9c7a-21e26ef522fa)

> src/hotspot/share/prims/vectorSupport.cpp line 493:
> 
>> 491: int VectorSupport::max_vector_size(BasicType bt) {
>> 492:   if (is_java_primitive(bt)) {
>> 493:     return VM_Version::max_vector_size(bt);
> 
> `VM_Version::max_vector_size(bt)` is a platform specific method, and currently only x86 contains it. So this makes the jdk image build failure on other platforms like aarch64. Could we define a public/common method and implement it on each platform like matcher?

Correct, we need handle it for aarch64.  Matcher routines will not be accessible by C1 only builds. That was a limitation in existing [_VectorSupport_GetMaxLaneCount_](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/prims/vectorSupport.cpp#L583) functionality. Max vector size is tightly bound to targets.

> Could we define a public/common method and implement it on each platform like matcher

Yes, x86 already does that currently, we need to have a target specific handling one way or other, We need need max vector size to estimate bundle size during field parsing and wanted to avoid its dependency on opto compiler.

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1752267166
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1349823885


From jbhateja at openjdk.org  Mon Oct  9 02:46:11 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Oct 2023 02:46:11 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
In-Reply-To: <MrMkaU1drk6KMQtJ8IXNV55DfWgNZg1VIQdR0jVdtPk=.17fa9b65-eb47-406a-b2ec-ed36ab7b35e2@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <MrMkaU1drk6KMQtJ8IXNV55DfWgNZg1VIQdR0jVdtPk=.17fa9b65-eb47-406a-b2ec-ed36ab7b35e2@github.com>
Message-ID: <EZfAGYT_c4WOMCiHt-MrBNcEmfOEk8s1Lsj2wakaceI=.52c48109-14df-49ac-9707-3f7e6bad065c@github.com>

On Sun, 8 Oct 2023 01:03:24 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> An alternative is trying to passing the type info to the `MultiField` annotation, so that the `_class_name` is not needed, and so does to the method `VectorSupport::get_max_multifield_count()`. We can use "max_vector_size(bt)" directly.

Thanks @XiaohongGong , you mean pass explicit vector lane type to multifiled annotation like @multifield(-1,  long.class). Please consider following points 
- We will still need explicit VectorPayload class definitions for mask/shuffule max payloads for different vector types.
- Mask/Shuffle backing storage field type is common for all kinds of vector i.e. byte for shuffle and Boolean for mask.
- We can save on complexity of extending the annotation semantics for max species by doing an efficient vmSymbolID lookup. 
- In future if we refactor shuffle lanes to match the lane types of corresponding vector then additional element type in multifield will be redundant as the backing field type will itself be different for max shuffle payloads.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1349827199


From xgong at openjdk.org  Mon Oct  9 07:57:40 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 9 Oct 2023 07:57:40 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
In-Reply-To: <EZfAGYT_c4WOMCiHt-MrBNcEmfOEk8s1Lsj2wakaceI=.52c48109-14df-49ac-9707-3f7e6bad065c@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <MrMkaU1drk6KMQtJ8IXNV55DfWgNZg1VIQdR0jVdtPk=.17fa9b65-eb47-406a-b2ec-ed36ab7b35e2@github.com>
 <EZfAGYT_c4WOMCiHt-MrBNcEmfOEk8s1Lsj2wakaceI=.52c48109-14df-49ac-9707-3f7e6bad065c@github.com>
Message-ID: <BjGxcOtM-QfgEP4Uxj486wMJJw43FFw5LfIiaR_IjG4=.5b52a0ed-0c5f-4677-97f6-ce538459debe@github.com>

On Mon, 9 Oct 2023 02:43:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 1636:
>> 
>>> 1634:       int bundle_size = parsed_annotations.multifield_arg();
>>> 1635:       if (bundle_size < 0) {
>>> 1636:         bundle_size = VectorSupport::get_max_multifield_count(_class_name);
>> 
>> An alternative is trying to passing the type info to the `MultiField` annotation, so that the `_class_name` is not needed, and so does to the method `VectorSupport::get_max_multifield_count()`. We can use "max_vector_size(bt)" directly.
>
>> An alternative is trying to passing the type info to the `MultiField` annotation, so that the `_class_name` is not needed, and so does to the method `VectorSupport::get_max_multifield_count()`. We can use "max_vector_size(bt)" directly.
> 
> Thanks @XiaohongGong , you mean pass explicit vector lane type to multifiled annotation like @multifield(-1,  long.class). Please consider following points 
> - We will still need explicit VectorPayload class definitions for mask/shuffule max payloads for different vector types.
> - Mask/Shuffle backing storage field type is common for all kinds of vector i.e. byte for shuffle and Boolean for mask.
> - We can save on complexity of extending the annotation semantics for max species by doing an efficient vmSymbolID lookup. 
> - In future if we refactor shuffle lanes to match the lane types of corresponding vector then additional element type in multifield will be redundant as the backing field type will itself be different for max shuffle payloads.

I understand. It's not a problem for mask/shuffle, since we can add the type info for them as well. And I think that's the main reason that we need the type info. Because we can get the type info during class parser for each field of the normal vector classes. Anyway, looking up symbol ID can also work well.

>> src/hotspot/share/prims/vectorSupport.cpp line 493:
>> 
>>> 491: int VectorSupport::max_vector_size(BasicType bt) {
>>> 492:   if (is_java_primitive(bt)) {
>>> 493:     return VM_Version::max_vector_size(bt);
>> 
>> `VM_Version::max_vector_size(bt)` is a platform specific method, and currently only x86 contains it. So this makes the jdk image build failure on other platforms like aarch64. Could we define a public/common method and implement it on each platform like matcher?
>
> Correct, we need handle it for aarch64.  Matcher routines will not be accessible by C1 only builds. That was a limitation in existing [_VectorSupport_GetMaxLaneCount_](https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/prims/vectorSupport.cpp#L583) functionality. Max vector size is tightly bound to targets.
> 
>> Could we define a public/common method and implement it on each platform like matcher
> 
> Yes, x86 already does that currently, we need to have a target specific handling one way or other, We need need max vector size to estimate bundle size during field parsing and wanted to avoid its dependency on opto compiler.

Yeah, I agree that we need a non-c2 specific method to get the max vector size. But it is added for x86 now. And I can help add the aarch64 part if you need. My concern is for other platforms that do not have such a method, the jdk image will build failure.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1349965724
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1349962339


From dsimms at openjdk.org  Mon Oct  9 10:26:12 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 9 Oct 2023 10:26:12 GMT
Subject: [lworld] RFR: 8317658: [lworld] TemplateTable::withfield() does not
 correctly load the ResolvedFieldEntry
Message-ID: <MLsa42UQEinFJBfh6HLlU_5jgC4EhHTKe67TgbXTctA=.50003a55-9411-48e7-ac85-b580fc6bbc09@github.com>

Ensure ResolvedFieldEntry is correctly loaded

More testing might well be in order, but we are more than likely to remove `withfield` . To make up for the testing, using `assert(entry->is_valid())` upon passing to the interpreter runtime is useful for avoiding bugs in future changes to the hand-rolled assembler, that can be error prone when holding a lot of registers (e.g. `putfield`).

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

Commit messages:
 - 8317658: [lworld] TemplateTable::withfield() does not correctly load the ResolvedFieldEntry

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

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


From fparain at openjdk.org  Mon Oct  9 16:10:26 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 9 Oct 2023 16:10:26 GMT
Subject: [lworld] RFR: 8317658: [lworld] TemplateTable::withfield() does
 not correctly load the ResolvedFieldEntry
In-Reply-To: <MLsa42UQEinFJBfh6HLlU_5jgC4EhHTKe67TgbXTctA=.50003a55-9411-48e7-ac85-b580fc6bbc09@github.com>
References: <MLsa42UQEinFJBfh6HLlU_5jgC4EhHTKe67TgbXTctA=.50003a55-9411-48e7-ac85-b580fc6bbc09@github.com>
Message-ID: <XFimVz3WDY_WQ8VqkEyO8E0mXaxqE3nxwx2fAWGNgpc=.66adc299-2e4b-480f-93bd-35b4c497b3f1@github.com>

On Mon, 9 Oct 2023 09:03:17 GMT, David Simms <dsimms at openjdk.org> wrote:

> Ensure ResolvedFieldEntry is correctly loaded
> 
> More testing might well be in order, but we are more than likely to remove `withfield` . To make up for the testing, using `assert(entry->is_valid())` upon passing to the interpreter runtime is useful for avoiding bugs in future changes to the hand-rolled assembler, that can be error prone when holding a lot of registers (e.g. `putfield`).

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/936#pullrequestreview-1664878676


From dsimms at openjdk.org  Mon Oct  9 17:16:30 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 9 Oct 2023 17:16:30 GMT
Subject: [lworld] Integrated: 8317658: [lworld] TemplateTable::withfield() does
 not correctly load the ResolvedFieldEntry
In-Reply-To: <MLsa42UQEinFJBfh6HLlU_5jgC4EhHTKe67TgbXTctA=.50003a55-9411-48e7-ac85-b580fc6bbc09@github.com>
References: <MLsa42UQEinFJBfh6HLlU_5jgC4EhHTKe67TgbXTctA=.50003a55-9411-48e7-ac85-b580fc6bbc09@github.com>
Message-ID: <C5loaj5izasZYNFqBsu6363RHtGlLrpYBpEl5cgJJAg=.201ba286-917d-4f8e-a0d4-a8ff643b8c55@github.com>

On Mon, 9 Oct 2023 09:03:17 GMT, David Simms <dsimms at openjdk.org> wrote:

> Ensure ResolvedFieldEntry is correctly loaded
> 
> More testing might well be in order, but we are more than likely to remove `withfield` . To make up for the testing, using `assert(entry->is_valid())` upon passing to the interpreter runtime is useful for avoiding bugs in future changes to the hand-rolled assembler, that can be error prone when holding a lot of registers (e.g. `putfield`).

This pull request has now been integrated.

Changeset: 3a5d7d9f
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3a5d7d9f3d994b4886120185f3f0a3a37bc771b9
Stats:     32 lines in 5 files changed: 20 ins; 11 del; 1 mod

8317658: [lworld] TemplateTable::withfield() does not correctly load the ResolvedFieldEntry

Reviewed-by: fparain

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

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


From xgong at openjdk.org  Tue Oct 10 08:58:51 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 10 Oct 2023 08:58:51 GMT
Subject: [lworld+vector] RFR: 8317699: [lworld+vector] Fix Vector API tests
 crash with "assert(vbox->is_Phi()) failed: should be phi"
Message-ID: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>

Currently several jtreg tests under `test/jdk/jdk/jdk/incubator/vector` crash with following error:


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

Internal Error (valhalla/src/hotspot/share/opto/vector.cpp:257), pid=2737779, tid=2737796
assert(false) failed: should be phi


It happens when expanding a `VectorBoxNode` which has following inputs:

                        VectorBoxAllocate
                               |
                               |
       VectorBoxAllocate    [2 Proj]
               |             /   |
            [1 Proj]       /     |
               \         /       |
                 \     /        /
                   \ /        /
                 [2 Phi]    /
                     \    /
                       \ |
                     [1 Phi]     InlineType
                         \      /
                           \  /
                         VectorBox

The compiler will visit and expand all the inputs of the `PhiNode`, and mark them visited. If the input has been visited, it just returns without any action. And the compiler assumes the revisited node should be a PhiNode. In above graph, the first `Phi` (i.e. `[1 Phi]`) has the same input `[2 Proj]` with the second `Phi` (i.e. `[2 Phi]`). So `[2 Proj]` will be visited twice. At the second time it is visited, the assertion fails since it is not a Phi. The case is reasonable in java and the assertion can be removed.

Removing the assertion can fix the existing issue and no new issues are involved.

Jdk mainline also has the same issue, but I prefer fixing it here temporarily with following reasons:
 1) Several jtreg tests crash on this branch while pass on jdk mainline. This blocks our testing and further development.
 2) We can have more testing with this fix on this branch. And port it to jdk mainline once we think it's a mature/safe change.

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

Commit messages:
 - 8317699: [lworld+vector] Fix Vector API tests crash with "assert(vbox->is_Phi()) failed: should be phi"

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

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


From jbhateja at openjdk.org  Wed Oct 11 01:43:25 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 11 Oct 2023 01:43:25 GMT
Subject: [lworld+vector] RFR: 8317699: [lworld+vector] Fix Vector API tests
 crash with "assert(vbox->is_Phi()) failed: should be phi"
In-Reply-To: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
References: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
Message-ID: <3RiaLkwUEOP07Cb8vQ8uvDB2IrgJL16ZutngQdaQUaA=.780dff33-e2d6-4654-be9d-fd53bbab5233@github.com>

On Tue, 10 Oct 2023 08:50:32 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently several jtreg tests under `test/jdk/jdk/jdk/incubator/vector` crash with following error:
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
> Internal Error (valhalla/src/hotspot/share/opto/vector.cpp:257), pid=2737779, tid=2737796
> assert(false) failed: should be phi
> 
> 
> It happens when expanding a `VectorBoxNode` which has following inputs:
> 
>                         VectorBoxAllocate
>                                |
>                                |
>        VectorBoxAllocate    [2 Proj]
>                |             /   |
>             [1 Proj]       /     |
>                \         /       |
>                  \     /        /
>                    \ /        /
>                  [2 Phi]    /
>                      \    /
>                        \ |
>                      [1 Phi]     InlineType
>                          \      /
>                            \  /
>                          VectorBox
> 
> The compiler will visit and expand all the inputs of the `PhiNode`, and mark them visited. If the input has been visited, it just returns without any action. And the compiler assumes the revisited node should be a PhiNode. In above graph, the first `Phi` (i.e. `[1 Phi]`) has the same input `[2 Proj]` with the second `Phi` (i.e. `[2 Phi]`). So `[2 Proj]` will be visited twice. At the second time it is visited, the assertion fails since it is not a Phi. The case is reasonable in java and the assertion can be removed.
> 
> Removing the assertion can fix the existing issue and no new issues are involved.
> 
> Jdk mainline also has the same issue, but I prefer fixing it here temporarily with following reasons:
>  1) Several jtreg tests crash on this branch while pass on jdk mainline. This blocks our testing and further development.
>  2) We can have more testing with this fix on this branch. And port it to jdk mainline once we think it's a mature/safe change.

Hi @XiaohongGong , 
VectorBoxAllocate node do not take part in GVN being a descendent of SafePointNode where as VectorNode does hence it may result into above mentioned graph shape.

You mentioned about this being a problem in mainline also, can you kindly share a test reproducer for it, lworld+vector does diverg from mainline w.r.t VectorBoxNode which are now InlineTypeNode but VectorBoxAllocate is still the same. Pushing InlineTypeNode across phi is also done using _merge_through_phi_ routines.

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

PR Comment: https://git.openjdk.org/valhalla/pull/937#issuecomment-1756602854


From xgong at openjdk.org  Wed Oct 11 01:48:18 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 11 Oct 2023 01:48:18 GMT
Subject: [lworld+vector] RFR: 8317699: [lworld+vector] Fix Vector API tests
 crash with "assert(vbox->is_Phi()) failed: should be phi"
In-Reply-To: <3RiaLkwUEOP07Cb8vQ8uvDB2IrgJL16ZutngQdaQUaA=.780dff33-e2d6-4654-be9d-fd53bbab5233@github.com>
References: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
 <3RiaLkwUEOP07Cb8vQ8uvDB2IrgJL16ZutngQdaQUaA=.780dff33-e2d6-4654-be9d-fd53bbab5233@github.com>
Message-ID: <AQJOJHgWzgVwjACcDj38nEY-40u86irmM0YYsSDI5pY=.b83bee46-ed1e-47c3-aaa1-2e2db00ddecb@github.com>

On Wed, 11 Oct 2023 01:40:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> You mentioned about this being a problem in mainline also, can you kindly share a test reproducer for it, lworld+vector does diverg from mainline w.r.t VectorBoxNode which are now InlineTypeNode but VectorBoxAllocate is still the same. Pushing InlineTypeNode across phi is also done using _merge_through_phi_ routines.

Sure, I planed to add the test on jdk mainline once I push this change on that branch. Do you mean I add the test on this branch or push this change to jdk mainline now?

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

PR Comment: https://git.openjdk.org/valhalla/pull/937#issuecomment-1756606599


From jbhateja at openjdk.org  Wed Oct 11 02:44:27 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 11 Oct 2023 02:44:27 GMT
Subject: [lworld+vector] RFR: 8317699: [lworld+vector] Fix Vector API tests
 crash with "assert(vbox->is_Phi()) failed: should be phi"
In-Reply-To: <AQJOJHgWzgVwjACcDj38nEY-40u86irmM0YYsSDI5pY=.b83bee46-ed1e-47c3-aaa1-2e2db00ddecb@github.com>
References: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
 <3RiaLkwUEOP07Cb8vQ8uvDB2IrgJL16ZutngQdaQUaA=.780dff33-e2d6-4654-be9d-fd53bbab5233@github.com>
 <AQJOJHgWzgVwjACcDj38nEY-40u86irmM0YYsSDI5pY=.b83bee46-ed1e-47c3-aaa1-2e2db00ddecb@github.com>
Message-ID: <lT-gtZa6uqLcP50f_lmMlST3iBJkTjC32qtbStE8Cyc=.d3cf738a-11c6-4006-8cce-e1540ad6435d@github.com>

On Wed, 11 Oct 2023 01:45:57 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > You mentioned about this being a problem in mainline also, can you kindly share a test reproducer for it, lworld+vector does diverg from mainline w.r.t VectorBoxNode which are now InlineTypeNode but VectorBoxAllocate is still the same. Pushing InlineTypeNode across phi is also done using _merge_through_phi_ routines.
> 
> Sure, I planed to add the test on jdk mainline once I push this change on that branch.

We do not see assertion failures in Vector API JTREG tests currently, which means above mentioned graph shape involving VectorBoxAllocate IR node only appears with lworld+vector for same test point. Was curious to know the root cause of this.

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

PR Comment: https://git.openjdk.org/valhalla/pull/937#issuecomment-1756660548


From xgong at openjdk.org  Wed Oct 11 03:03:21 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 11 Oct 2023 03:03:21 GMT
Subject: [lworld+vector] RFR: 8317699: [lworld+vector] Fix Vector API tests
 crash with "assert(vbox->is_Phi()) failed: should be phi"
In-Reply-To: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
References: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
Message-ID: <dYnu4aZqUZuUC0dZ8xHeFDn3PH5dNh8QNdhk3TeKDKM=.28dd004e-297e-42b2-b7cd-1a47f43d0963@github.com>

On Tue, 10 Oct 2023 08:50:32 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently several jtreg tests under `test/jdk/jdk/jdk/incubator/vector` crash with following error:
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
> Internal Error (valhalla/src/hotspot/share/opto/vector.cpp:257), pid=2737779, tid=2737796
> assert(false) failed: should be phi
> 
> 
> It happens when expanding a `VectorBoxNode` which has following inputs:
> 
>                         VectorBoxAllocate
>                                |
>                                |
>        VectorBoxAllocate    [2 Proj]
>                |             /   |
>             [1 Proj]       /     |
>                \         /       |
>                  \     /        /
>                    \ /        /
>                  [2 Phi]    /
>                      \    /
>                        \ |
>                      [1 Phi]     InlineType
>                          \      /
>                            \  /
>                          VectorBox
> 
> The compiler will visit and expand all the inputs of the `PhiNode`, and mark them visited. If the input has been visited, it just returns without any action. And the compiler assumes the revisited node should be a PhiNode. In above graph, the first `Phi` (i.e. `[1 Phi]`) has the same input `[2 Proj]` with the second `Phi` (i.e. `[2 Phi]`). So `[2 Proj]` will be visited twice. At the second time it is visited, the assertion fails since it is not a Phi. The case is reasonable in java and the assertion can be removed.
> 
> Removing the assertion can fix the existing issue and no new issues are involved.
> 
> Jdk mainline also has the same issue, but I prefer fixing it here temporarily with following reasons:
>  1) Several jtreg tests crash on this branch while pass on jdk mainline. This blocks our testing and further development.
>  2) We can have more testing with this fix on this branch. And port it to jdk mainline once we think it's a mature/safe change.

> > > You mentioned about this being a problem in mainline also, can you kindly share a test reproducer for it, lworld+vector does diverg from mainline w.r.t VectorBoxNode which are now InlineTypeNode but VectorBoxAllocate is still the same. Pushing InlineTypeNode across phi is also done using _merge_through_phi_ routines.
> > 
> > 
> > Sure, I planed to add the test on jdk mainline once I push this change on that branch.
> 
> We do not see assertion failures in Vector API JTREG tests currently, which means above mentioned graph shape involving VectorBoxAllocate IR node only appears with lworld+vector for same test point. Was curious to know the root cause of this.

The failure case on `lworld+vector` is like `Byte128VectorTests.divByte128VectorTestsBroadcastSmokeTest()`. After I debug and dump the ideal graph, I found it happens when C2 compiler compiles method `ByteVector::lanewise()` https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L1019 which finally calls into https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L881.

As we can see, there is some `if-else` branches inside the java code. And the ideal graph matches this code as well, which just like what I printed in above comment.  I tried to write a similar small case like it, and the issue is reproduced. The main code just like following code which is also reproduceable on jdk mainline:

static final VectorSpecies<Byte> B_SPECIES = ByteVector.SPECIES_128;

private static ByteVector func2(ByteVector v, int i) {
        ByteVector v1 = v;
        if (i % 2 == 0 || i % 3 == 0) {
            if (i % 2 == 0) {
                v1 = v1.lanewise(VectorOperators.AND, (byte)5);
            }

            if (i % 8 == 0) {
                v1 = v;
            }
        }
        return v1;
}

public static ByteVector v2;

public static void main(String[] args) {
        ByteVector v = ByteVector.zero(B_SPECIES);

        for (int i = 0; i < 100000; i++) {
            for (int j = 0; j < LENGTH; j += B_SPECIES.length()) {
                ByteVector av = ByteVector.fromArray(B_SPECIES, ia, j);
                v = func2(av, i);
            }
        }

        v2 = v;
}


I guess the reason why the jtreg tests on jdk mainline cannot reproduce is: we added inlinetype on lworld+vector, and the java default code is more complex, which just makes C2 compiles the relative java code with not too much other optimizations like in jdk mainline. And the issue is exposed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/937#issuecomment-1756674093


From jbhateja at openjdk.org  Wed Oct 11 03:32:22 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 11 Oct 2023 03:32:22 GMT
Subject: [lworld+vector] RFR: 8317699: [lworld+vector] Fix Vector API tests
 crash with "assert(vbox->is_Phi()) failed: should be phi"
In-Reply-To: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
References: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
Message-ID: <jyg6oYJMr-zj3zazIhMmy2R5AznaSuATuQMBthz4l5E=.86b93e04-9aea-4fd0-a0f5-97b605683264@github.com>

On Tue, 10 Oct 2023 08:50:32 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently several jtreg tests under `test/jdk/jdk/jdk/incubator/vector` crash with following error:
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
> Internal Error (valhalla/src/hotspot/share/opto/vector.cpp:257), pid=2737779, tid=2737796
> assert(false) failed: should be phi
> 
> 
> It happens when expanding a `VectorBoxNode` which has following inputs:
> 
>                         VectorBoxAllocate
>                                |
>                                |
>        VectorBoxAllocate    [2 Proj]
>                |             /   |
>             [1 Proj]       /     |
>                \         /       |
>                  \     /        /
>                    \ /        /
>                  [2 Phi]    /
>                      \    /
>                        \ |
>                      [1 Phi]     InlineType
>                          \      /
>                            \  /
>                          VectorBox
> 
> The compiler will visit and expand all the inputs of the `PhiNode`, and mark them visited. If the input has been visited, it just returns without any action. And the compiler assumes the revisited node should be a PhiNode. In above graph, the first `Phi` (i.e. `[1 Phi]`) has the same input `[2 Proj]` with the second `Phi` (i.e. `[2 Phi]`). So `[2 Proj]` will be visited twice. At the second time it is visited, the assertion fails since it is not a Phi. The case is reasonable in java and the assertion can be removed.
> 
> Removing the assertion can fix the existing issue and no new issues are involved.
> 
> Jdk mainline also has the same issue, but I prefer fixing it here temporarily with following reasons:
>  1) Several jtreg tests crash on this branch while pass on jdk mainline. This blocks our testing and further development.
>  2) We can have more testing with this fix on this branch. And port it to jdk mainline once we think it's a mature/safe change.

Marked as reviewed by jbhateja (Committer).

Thanks for the explanation, looks good to me.

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

PR Review: https://git.openjdk.org/valhalla/pull/937#pullrequestreview-1669776816
PR Comment: https://git.openjdk.org/valhalla/pull/937#issuecomment-1756708972


From xgong at openjdk.org  Wed Oct 11 03:32:22 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 11 Oct 2023 03:32:22 GMT
Subject: [lworld+vector] RFR: 8317699: [lworld+vector] Fix Vector API tests
 crash with "assert(vbox->is_Phi()) failed: should be phi"
In-Reply-To: <jyg6oYJMr-zj3zazIhMmy2R5AznaSuATuQMBthz4l5E=.86b93e04-9aea-4fd0-a0f5-97b605683264@github.com>
References: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
 <jyg6oYJMr-zj3zazIhMmy2R5AznaSuATuQMBthz4l5E=.86b93e04-9aea-4fd0-a0f5-97b605683264@github.com>
Message-ID: <3yV_g_--m9qeTeJd1uRNMKxSSvv_yR0TJ3Aw7sExMEE=.d1169b7d-adbf-4612-b13d-b1f9908bf6de@github.com>

On Wed, 11 Oct 2023 03:29:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Currently several jtreg tests under `test/jdk/jdk/jdk/incubator/vector` crash with following error:
>> 
>> 
>> A fatal error has been detected by the Java Runtime Environment:
>> 
>> Internal Error (valhalla/src/hotspot/share/opto/vector.cpp:257), pid=2737779, tid=2737796
>> assert(false) failed: should be phi
>> 
>> 
>> It happens when expanding a `VectorBoxNode` which has following inputs:
>> 
>>                         VectorBoxAllocate
>>                                |
>>                                |
>>        VectorBoxAllocate    [2 Proj]
>>                |             /   |
>>             [1 Proj]       /     |
>>                \         /       |
>>                  \     /        /
>>                    \ /        /
>>                  [2 Phi]    /
>>                      \    /
>>                        \ |
>>                      [1 Phi]     InlineType
>>                          \      /
>>                            \  /
>>                          VectorBox
>> 
>> The compiler will visit and expand all the inputs of the `PhiNode`, and mark them visited. If the input has been visited, it just returns without any action. And the compiler assumes the revisited node should be a PhiNode. In above graph, the first `Phi` (i.e. `[1 Phi]`) has the same input `[2 Proj]` with the second `Phi` (i.e. `[2 Phi]`). So `[2 Proj]` will be visited twice. At the second time it is visited, the assertion fails since it is not a Phi. The case is reasonable in java and the assertion can be removed.
>> 
>> Removing the assertion can fix the existing issue and no new issues are involved.
>> 
>> Jdk mainline also has the same issue, but I prefer fixing it here temporarily with following reasons:
>>  1) Several jtreg tests crash on this branch while pass on jdk mainline. This blocks our testing and further development.
>>  2) We can have more testing with this fix on this branch. And port it to jdk mainline once we think it's a mature/safe change.
>
> Thanks for the explanation, looks good to me.

Thanks for the review @jatin-bhateja !

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

PR Comment: https://git.openjdk.org/valhalla/pull/937#issuecomment-1756709707


From xgong at openjdk.org  Wed Oct 11 04:00:20 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 11 Oct 2023 04:00:20 GMT
Subject: [lworld+vector] Integrated: 8317699: [lworld+vector] Fix Vector API
 tests crash with "assert(vbox->is_Phi()) failed: should be phi"
In-Reply-To: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
References: <i0DORWZKAixTJe5juCEhEH-ENYsIw6VPFicirSmfSw8=.2fcadf68-4813-435c-8e38-29de9b6bf7a8@github.com>
Message-ID: <RAt86KzcJKr3M9PMY9ElXVfX9qjDk-KLjp-kE_ZmbG8=.cab4406c-973f-4aaf-bb9a-716f739762d4@github.com>

On Tue, 10 Oct 2023 08:50:32 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently several jtreg tests under `test/jdk/jdk/jdk/incubator/vector` crash with following error:
> 
> 
> A fatal error has been detected by the Java Runtime Environment:
> 
> Internal Error (valhalla/src/hotspot/share/opto/vector.cpp:257), pid=2737779, tid=2737796
> assert(false) failed: should be phi
> 
> 
> It happens when expanding a `VectorBoxNode` which has following inputs:
> 
>                         VectorBoxAllocate
>                                |
>                                |
>        VectorBoxAllocate    [2 Proj]
>                |             /   |
>             [1 Proj]       /     |
>                \         /       |
>                  \     /        /
>                    \ /        /
>                  [2 Phi]    /
>                      \    /
>                        \ |
>                      [1 Phi]     InlineType
>                          \      /
>                            \  /
>                          VectorBox
> 
> The compiler will visit and expand all the inputs of the `PhiNode`, and mark them visited. If the input has been visited, it just returns without any action. And the compiler assumes the revisited node should be a PhiNode. In above graph, the first `Phi` (i.e. `[1 Phi]`) has the same input `[2 Proj]` with the second `Phi` (i.e. `[2 Phi]`). So `[2 Proj]` will be visited twice. At the second time it is visited, the assertion fails since it is not a Phi. The case is reasonable in java and the assertion can be removed.
> 
> Removing the assertion can fix the existing issue and no new issues are involved.
> 
> Jdk mainline also has the same issue, but I prefer fixing it here temporarily with following reasons:
>  1) Several jtreg tests crash on this branch while pass on jdk mainline. This blocks our testing and further development.
>  2) We can have more testing with this fix on this branch. And port it to jdk mainline once we think it's a mature/safe change.

This pull request has now been integrated.

Changeset: 39c7c934
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/39c7c934ddae1836a888f5c6599b471b97c0cf1c
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8317699: [lworld+vector] Fix Vector API tests crash with "assert(vbox->is_Phi()) failed: should be phi"

Reviewed-by: jbhateja

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

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


From jbhateja at openjdk.org  Wed Oct 11 07:35:07 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 11 Oct 2023 07:35:07 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v2]
In-Reply-To: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
Message-ID: <nAU21gP20z2_EGDUXM04OJZMkpRFGWZcnEntbYi-YfQ=.4c207c49-ab82-4e44-af64-d72bba616aee@github.com>

> - Patch adds MaxSpecies support for all types of vectors.
> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
> - Disable CDS archiving of VectorPayload classes.
> - Summary of high level flow :-
>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'lworld+vector' of http://github.com/openjdk/valhalla into JDK-8311675
 - [lworld+vector] Max Species support.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/931/files
  - new: https://git.openjdk.org/valhalla/pull/931/files/822b024d..d721d71f

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

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

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


From jbhateja at openjdk.org  Sun Oct 15 16:03:50 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 15 Oct 2023 16:03:50 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
Message-ID: <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>

> - Patch adds MaxSpecies support for all types of vectors.
> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
> - Disable CDS archiving of VectorPayload classes.
> - Summary of high level flow :-
>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comments resolutions.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/931/files
  - new: https://git.openjdk.org/valhalla/pull/931/files/d721d71f..993674ec

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

  Stats: 212 lines in 49 files changed: 52 ins; 7 del; 153 mod
  Patch: https://git.openjdk.org/valhalla/pull/931.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/931/head:pull/931

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


From jbhateja at openjdk.org  Sun Oct 15 16:08:36 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 15 Oct 2023 16:08:36 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
In-Reply-To: <eU7_eGABayDyVvnYJjig1DtYpZaoLiee6JZf3U-bmO0=.ab58ab1e-52c2-43a9-8062-a27fc08e662b@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <eU7_eGABayDyVvnYJjig1DtYpZaoLiee6JZf3U-bmO0=.ab58ab1e-52c2-43a9-8062-a27fc08e662b@github.com>
Message-ID: <F9lD9A5XnCUqcxGNlDSdamCSO7lRFYcjoe-z8omdo7I=.fdb4cec1-b243-4e06-8485-2f1dcae3dc93@github.com>

On Sun, 8 Oct 2023 01:58:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> - Patch adds MaxSpecies support for all types of vectors.
>> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
>> - Disable CDS archiving of VectorPayload classes.
>> - Summary of high level flow :-
>>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> I met a new JVM crash issues on ARM Neon platform with this PR. Log is:
> 
> test IntMaxVectorLoadStoreTests.loadArrayMaskIOOBE(int[i * 5], l + speciesl + 1, mask[false]): success
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (valhalla/src/hotspot/share/opto/type.cpp:4177), pid=1739617, tid=1739655
> #  assert(!flat_array || can_be_inline_type()) failed: Only inline types can be flat in array
> #
> # JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-b575ef0fa)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-b575ef0fa, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # V  [libjvm.so+0x18697d0]  TypeInstPtr::TypeInstPtr(TypePtr::PTR, ciKlass*, TypePtr::InterfaceSet const&, bool, ciObject*, Type::Offset, bool, int, TypePtr const*, int)+0x15c
> 
> 
> And a regression in `DoubleMaxVectorTests` such as:
> 
> test DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(double[cornerCaseValue(i)], mask[i % 2]): failure
> java.lang.AssertionError: expected [true] but found [false]
>         at org.testng.Assert.fail(Assert.java:99)
>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>         at org.testng.Assert.assertEquals(Assert.java:122)
>         at org.testng.Assert.assertEquals(Assert.java:819)
>         at org.testng.Assert.assertEquals(Assert.java:829)
>         at DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(DoubleMaxVectorTests.java:2716)
>         ...

Hi @XiaohongGong , Can you kindly do a validation run on AARCH64 with latest patch.

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1763434691


From xgong at openjdk.org  Mon Oct 16 01:58:39 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 16 Oct 2023 01:58:39 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
In-Reply-To: <eU7_eGABayDyVvnYJjig1DtYpZaoLiee6JZf3U-bmO0=.ab58ab1e-52c2-43a9-8062-a27fc08e662b@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <eU7_eGABayDyVvnYJjig1DtYpZaoLiee6JZf3U-bmO0=.ab58ab1e-52c2-43a9-8062-a27fc08e662b@github.com>
Message-ID: <oT_FgNONngSHwB1z5gz2kkUEbwuJKzWERnOz3k_M7fM=.56eb592a-8b92-452d-9335-b324475be257@github.com>

On Sun, 8 Oct 2023 01:58:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> - Patch adds MaxSpecies support for all types of vectors.
>> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
>> - Disable CDS archiving of VectorPayload classes.
>> - Summary of high level flow :-
>>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> I met a new JVM crash issues on ARM Neon platform with this PR. Log is:
> 
> test IntMaxVectorLoadStoreTests.loadArrayMaskIOOBE(int[i * 5], l + speciesl + 1, mask[false]): success
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (valhalla/src/hotspot/share/opto/type.cpp:4177), pid=1739617, tid=1739655
> #  assert(!flat_array || can_be_inline_type()) failed: Only inline types can be flat in array
> #
> # JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-b575ef0fa)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-b575ef0fa, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # V  [libjvm.so+0x18697d0]  TypeInstPtr::TypeInstPtr(TypePtr::PTR, ciKlass*, TypePtr::InterfaceSet const&, bool, ciObject*, Type::Offset, bool, int, TypePtr const*, int)+0x15c
> 
> 
> And a regression in `DoubleMaxVectorTests` such as:
> 
> test DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(double[cornerCaseValue(i)], mask[i % 2]): failure
> java.lang.AssertionError: expected [true] but found [false]
>         at org.testng.Assert.fail(Assert.java:99)
>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>         at org.testng.Assert.assertEquals(Assert.java:122)
>         at org.testng.Assert.assertEquals(Assert.java:819)
>         at org.testng.Assert.assertEquals(Assert.java:829)
>         at DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(DoubleMaxVectorTests.java:2716)
>         ...

> Hi @XiaohongGong , Can you kindly do a validation run on AARCH64 with latest patch.

Sure, I will start the test once you change the aarch64 part. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1763608324


From xgong at openjdk.org  Mon Oct 16 01:58:44 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 16 Oct 2023 01:58:44 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
Message-ID: <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>

On Sun, 15 Oct 2023 16:03:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Patch adds MaxSpecies support for all types of vectors.
>> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
>> - Disable CDS archiving of VectorPayload classes.
>> - Summary of high level flow :-
>>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 663:

> 661: int VM_Version::max_vector_size(BasicType bt) {
> 662:   return MaxVectorSize / type2aelembytes(bt);
> 663: }

Please change to use the code in https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/cpu/aarch64/aarch64.ad#L2344 like what you have changed in x86 systems, together with the `Matcher::max_vector_size()`. Thanks a lot!

src/hotspot/cpu/x86/vm_version_x86.cpp line 3257:

> 3255:   default:
> 3256:     assert(false, "Unexpected basic type");
> 3257:   }

If the return value is 0, what is the actual number of the multifields in payload? It seems not reasonable for `0`. WDYT?

src/hotspot/share/oops/inlineKlass.cpp line 158:

> 156:   if (VectorSupport::is_vector_payload_mf(this) || VectorSupport::is_vector(this)) {
> 157:     return false;
> 158:   }

Why do you close the array flatten for vectors?

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

> 463:   assert(payload_name, "");
> 464:   vmSymbolID sid = vmSymbols::find_sid(payload_name);
> 465:   int size = VM_Version::max_vector_size(T_BYTE);

It seems we'd better check whether the return value `size` is `0`. If so, a max with 64-bit size is needed like what we have done in java code. See https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java#L267

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 143:

> 141:                 species.maskType(), species.elementType(), vspecies().laneCount,
> 142:                 this, species,
> 143:                 (m, s) -> VectorMask.fromLong(s, m.toLong()).check(s));

Any issues with the original `maskFactory()` ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360016602
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360010718
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360001591
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360015893
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360002100


From jbhateja at openjdk.org  Mon Oct 16 06:28:18 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Oct 2023 06:28:18 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
 <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
Message-ID: <a9MRuQVUb0cGOr6vdkvXwOBF0r2LXf7UONXkZcLaL6U=.b2d4f7c9-7074-4f79-9f87-340fd203af54@github.com>

On Mon, 16 Oct 2023 01:07:55 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/share/oops/inlineKlass.cpp line 158:
> 
>> 156:   if (VectorSupport::is_vector_payload_mf(this) || VectorSupport::is_vector(this)) {
>> 157:     return false;
>> 158:   }
> 
> Why do you close the array flatten for vectors?

Array of vector may be heterogeneous in nature where each element points to a vector of different shape, thus array flatten do not make much sense to vectors. In additional during type resolution flat_array flag is set for imbalanced Phi (having different type of inputs e.g. VectorPayload64 and VectorPayload128) even though Phi's type is lower common ancestor type of participating inputs i.e., VectorPayload which itself is not an inlinetype, this leads to assertion failures in downstream flow.

https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/type.cpp#L4636

Instead of making a wider change in type resolution, where we flat_array setting also take into account exact type of PhiNode, I prefer to restrict array flatten for vectors.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360164551


From jbhateja at openjdk.org  Mon Oct 16 06:34:26 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Oct 2023 06:34:26 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
 <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
Message-ID: <wMYVratsDCVJi71YOUVRZBUk8flbyGJxyXwsLcrQ7Jc=.406fab81-c3bc-471e-a5d9-5c29905f71e5@github.com>

On Mon, 16 Oct 2023 01:09:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 143:
> 
>> 141:                 species.maskType(), species.elementType(), vspecies().laneCount,
>> 142:                 this, species,
>> 143:                 (m, s) -> VectorMask.fromLong(s, m.toLong()).check(s));
> 
> Any issues with the original `maskFactory()` ?

We cannot typecast value object with another value type, thus directly passing payload (m.getBits()) to maskFactory will cause compilation failures.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360171364


From jbhateja at openjdk.org  Mon Oct 16 07:18:59 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Oct 2023 07:18:59 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
 <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
Message-ID: <89A16YyuxWsA4cgPnYUppRm90HFqyiCzRj7zPqwwUIk=.bb531ebb-24c1-4dd8-ba23-388d8d7ac936@github.com>

On Mon, 16 Oct 2023 01:37:47 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 3257:
> 
>> 3255:   default:
>> 3256:     assert(false, "Unexpected basic type");
>> 3257:   }
> 
> If the return value is 0, what is the actual number of the multifields in payload? It seems not reasonable for `0`. WDYT?

For x86 this leaf level routine is directly imported from Matcher.  _Matcher::max_vector_size_ will query it to get maximum vector size supported by a target. Agree that it needs to be tuned.

BTW I also see a discrepancy b/w lane count and max vector size for MaxSpecies in existing implementation.


LPROMPT>cat test_max.java 

import jdk.incubator.vector.*;

public class test_max {
   public static void main(String [] args) {
      System.out.println(ByteVector.SPECIES_MAX);
      System.out.println(ByteVector.broadcast(ByteVector.SPECIES_MAX, 1));
   }
} 
LPROMPT>java -XX:MaxVectorSize=0 --add-modules=jdk.incubator.vector -XX:+PrintFlagsFinal -cp . test_max.java  | grep -e "MaxVectorSize"  -e "Species" -e "["
OpenJDK 64-Bit Server VM warning: MaxVectorSize must be at least 4 on this platform
[Global flags]
     intx MaxVectorSize                            = 4                                      {C2 product} {command line}
WARNING: Using incubator modules: jdk.incubator.vector
warning: using incubating module(s): jdk.incubator.vector
1 warning
Species[byte, 8, S_Max_BIT]
[1, 1, 1, 1, 1, 1, 1, 1]
LPROMPT>

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360212953


From xgong at openjdk.org  Mon Oct 16 07:25:17 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 16 Oct 2023 07:25:17 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <89A16YyuxWsA4cgPnYUppRm90HFqyiCzRj7zPqwwUIk=.bb531ebb-24c1-4dd8-ba23-388d8d7ac936@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
 <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
 <89A16YyuxWsA4cgPnYUppRm90HFqyiCzRj7zPqwwUIk=.bb531ebb-24c1-4dd8-ba23-388d8d7ac936@github.com>
Message-ID: <ji073U2ULHCgNPBp6eq5Ns9TkA9mj3VIZxmZmgIHIEc=.ee64eeaf-4827-4a49-9663-d704b1740081@github.com>

On Mon, 16 Oct 2023 07:15:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 3257:
>> 
>>> 3255:   default:
>>> 3256:     assert(false, "Unexpected basic type");
>>> 3257:   }
>> 
>> If the return value is 0, what is the actual number of the multifields in payload? It seems not reasonable for `0`. WDYT?
>
> For x86 this leaf level routine is directly imported from Matcher.  _Matcher::max_vector_size_ will query it to get maximum vector size supported by a target. Agree that it needs to be tuned.
> 
> BTW I also see a discrepancy b/w lane count and max vector size for MaxSpecies in existing implementation.
> 
> 
> LPROMPT>cat test_max.java 
> 
> import jdk.incubator.vector.*;
> 
> public class test_max {
>    public static void main(String [] args) {
>       System.out.println(ByteVector.SPECIES_MAX);
>       System.out.println(ByteVector.broadcast(ByteVector.SPECIES_MAX, 1));
>    }
> } 
> LPROMPT>java -XX:MaxVectorSize=0 --add-modules=jdk.incubator.vector -XX:+PrintFlagsFinal -cp . test_max.java  | grep -e "MaxVectorSize"  -e "Species" -e "["
> OpenJDK 64-Bit Server VM warning: MaxVectorSize must be at least 4 on this platform
> [Global flags]
>      intx MaxVectorSize                            = 4                                      {C2 product} {command line}
> WARNING: Using incubator modules: jdk.incubator.vector
> warning: using incubating module(s): jdk.incubator.vector
> 1 warning
> Species[byte, 8, S_Max_BIT]
> [1, 1, 1, 1, 1, 1, 1, 1]
> LPROMPT>

Yes, it seems werid. I think it is because the min operation with 64-bit shape in java code. Please see my following comments.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360219456


From xgong at openjdk.org  Mon Oct 16 07:43:10 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 16 Oct 2023 07:43:10 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <a9MRuQVUb0cGOr6vdkvXwOBF0r2LXf7UONXkZcLaL6U=.b2d4f7c9-7074-4f79-9f87-340fd203af54@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
 <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
 <a9MRuQVUb0cGOr6vdkvXwOBF0r2LXf7UONXkZcLaL6U=.b2d4f7c9-7074-4f79-9f87-340fd203af54@github.com>
Message-ID: <4tfC39VxgrfNJJdbU-AqDoXD0VBsu7Md2eIVD72KGW8=.73fd6abe-8ddf-4a55-88fa-57dfb6f922f3@github.com>

On Mon, 16 Oct 2023 06:21:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/oops/inlineKlass.cpp line 158:
>> 
>>> 156:   if (VectorSupport::is_vector_payload_mf(this) || VectorSupport::is_vector(this)) {
>>> 157:     return false;
>>> 158:   }
>> 
>> Why do you close the array flatten for vectors?
>
> Array of vector may be heterogeneous in nature where each element points to a vector of different shape, thus array flatten do not make much sense to vectors. In additional during type resolution flat_array flag is set for imbalanced Phi (having different type of inputs e.g. VectorPayload64 and VectorPayload128) even though Phi's type is lower common ancestor type of participating inputs i.e., VectorPayload which itself is not an inlinetype, this leads to assertion failures in downstream flow.
> 
> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/type.cpp#L4636
> 
> Instead of making a wider change in type resolution, where we flat_array setting also take into account exact type of PhiNode, I prefer to restrict array flatten for vectors.

Thanks for the explanation! Seems it also causes the jvm crash in `VectorXXXConversionTests`, but I didn't figure out the root cause yet.  Is it possible supporting the flat array for vector objects with some fixes in future? We may lose the performance with this change, right?

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java line 143:
>> 
>>> 141:                 species.maskType(), species.elementType(), vspecies().laneCount,
>>> 142:                 this, species,
>>> 143:                 (m, s) -> VectorMask.fromLong(s, m.toLong()).check(s));
>> 
>> Any issues with the original `maskFactory()` ?
>
> We cannot typecast value object with another value type, thus directly passing payload (m.getBits()) to maskFactory will cause compilation failures.

Sounds reasonable! But I'm curious why we didn't meet this issue before?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360232286
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360222221


From jbhateja at openjdk.org  Mon Oct 16 08:14:18 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Oct 2023 08:14:18 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <4tfC39VxgrfNJJdbU-AqDoXD0VBsu7Md2eIVD72KGW8=.73fd6abe-8ddf-4a55-88fa-57dfb6f922f3@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
 <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
 <a9MRuQVUb0cGOr6vdkvXwOBF0r2LXf7UONXkZcLaL6U=.b2d4f7c9-7074-4f79-9f87-340fd203af54@github.com>
 <4tfC39VxgrfNJJdbU-AqDoXD0VBsu7Md2eIVD72KGW8=.73fd6abe-8ddf-4a55-88fa-57dfb6f922f3@github.com>
Message-ID: <iPYBzW_Uh-qXk1LIyWL1IMYEb3gJH4i9oywoy6Ec1ZA=.b29e09eb-22ee-4013-a754-40b4fe22904d@github.com>

On Mon, 16 Oct 2023 07:33:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Array of vector may be heterogeneous in nature where each element points to a vector of different shape, thus array flatten do not make much sense to vectors. In additional during type resolution flat_array flag is set for imbalanced Phi (having different type of inputs e.g. VectorPayload64 and VectorPayload128) even though Phi's type is lower common ancestor type of participating inputs i.e., VectorPayload which itself is not an inlinetype, this leads to assertion failures in downstream flow.
>> 
>> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/type.cpp#L4636
>> 
>> Instead of making a wider change in type resolution, where we flat_array setting also take into account exact type of PhiNode, I prefer to restrict array flatten for vectors.
>
> Thanks for the explanation! Seems it also causes the jvm crash in `VectorXXXConversionTests`, but I didn't figure out the root cause yet.  Is it possible supporting the flat array for vector objects with some fixes in future? We may lose the performance with this change, right?

Since we never expose concrete vector types to users hence its only possible to create an array of abstract vector references which can be heterogeneous. This is different from an array of value types which are implicitly final classes and may be flattened into a compact layout since such an array will be homogeneous in nature.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1360285556


From jbhateja at openjdk.org  Mon Oct 16 18:25:00 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Oct 2023 18:25:00 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
Message-ID: <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>

> - Patch adds MaxSpecies support for all types of vectors.
> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
> - Disable CDS archiving of VectorPayload classes.
> - Summary of high level flow :-
>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comments resolutions.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/931/files
  - new: https://git.openjdk.org/valhalla/pull/931/files/993674ec..945eb0fb

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

  Stats: 102 lines in 11 files changed: 25 ins; 62 del; 15 mod
  Patch: https://git.openjdk.org/valhalla/pull/931.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/931/head:pull/931

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


From xgong at openjdk.org  Tue Oct 17 00:56:50 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 00:56:50 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
Message-ID: <1PJiJwWrUbR2i_ZpWaWlMWKdg5doswMhOjz4i3BDGpo=.c89cf5f9-5254-4540-a3bd-3676e61a3768@github.com>

On Mon, 16 Oct 2023 18:25:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Patch adds MaxSpecies support for all types of vectors.
>> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
>> - Disable CDS archiving of VectorPayload classes.
>> - Summary of high level flow :-
>>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 663:

> 661: int VM_Version::max_vector_size(BasicType bt) {
> 662:  // The MaxVectorSize should have been set by detecting SVE max vector register size.
> 663:   int size = MIN2((UseSVE > 0) ? 256 : 16, (int)MaxVectorSize);

Style:

// The MaxVectorSize ...
int size = MIN2((UseSVE > 0) ? 256 : 16, (int)MaxVectorSize);

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1361394614


From xgong at openjdk.org  Tue Oct 17 01:11:37 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 01:11:37 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
Message-ID: <NK3bRi4WFAh9SUGGFgBNirk7T7Fjbo_k_DRqReJA314=.792947c7-60a2-4626-9253-bd985e685868@github.com>

On Mon, 16 Oct 2023 18:25:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Patch adds MaxSpecies support for all types of vectors.
>> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
>> - Disable CDS archiving of VectorPayload classes.
>> - Summary of high level flow :-
>>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

Generally LGTM! Just some minor code style.

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

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/931#pullrequestreview-1681159391


From xgong at openjdk.org  Tue Oct 17 01:25:39 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 01:25:39 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <xTO-bBsW6H0SXFrY1KtjFcuX14aRwbCV6L4fZll9510=.ac32de81-a268-4820-a1df-9bb692ac26b3@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <xTO-bBsW6H0SXFrY1KtjFcuX14aRwbCV6L4fZll9510=.ac32de81-a268-4820-a1df-9bb692ac26b3@github.com>
Message-ID: <2FYnAV2AAYOWICter2uAzVhrdkq-uZEcDjzlShGngHg=.94e8adab-0d51-41af-a32e-a40b0f3b8f33@github.com>

On Sun, 8 Oct 2023 02:10:35 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/share/ci/ciObjectFactory.cpp line 55:
> 
>> 53: #include "memory/universe.hpp"
>> 54: #include "oops/oop.inline.hpp"
>> 55: #include "prims/vectorSupport.hpp"
> 
> Not used and revert it?

This is not reverted, is it?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1361407321


From xgong at openjdk.org  Tue Oct 17 01:28:48 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 01:28:48 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <iPYBzW_Uh-qXk1LIyWL1IMYEb3gJH4i9oywoy6Ec1ZA=.b29e09eb-22ee-4013-a754-40b4fe22904d@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
 <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
 <a9MRuQVUb0cGOr6vdkvXwOBF0r2LXf7UONXkZcLaL6U=.b2d4f7c9-7074-4f79-9f87-340fd203af54@github.com>
 <4tfC39VxgrfNJJdbU-AqDoXD0VBsu7Md2eIVD72KGW8=.73fd6abe-8ddf-4a55-88fa-57dfb6f922f3@github.com>
 <iPYBzW_Uh-qXk1LIyWL1IMYEb3gJH4i9oywoy6Ec1ZA=.b29e09eb-22ee-4013-a754-40b4fe22904d@github.com>
Message-ID: <-fFur9Z-yNjt1iS2IoH9p_rCAlAptsCUjcmb3g2nYbM=.68df3131-98df-485f-959b-61e2ac2ad416@github.com>

On Mon, 16 Oct 2023 08:11:10 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thanks for the explanation! Seems it also causes the jvm crash in `VectorXXXConversionTests`, but I didn't figure out the root cause yet.  Is it possible supporting the flat array for vector objects with some fixes in future? We may lose the performance with this change, right?
>
> Since we never expose concrete vector types to users hence its only possible to create an array of abstract vector references which can be heterogeneous. This is different from an array of value types which are implicitly final classes and may be flattened into a compact layout since such an array will be homogeneous in nature.

Yeah, I understand. Maybe we could find other more general ways to forbit such kind of array flatten like vector objects, instead of hard coding the `vector/vector_payload` classes. We can revisit this in future. WDYT?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1361408537


From xgong at openjdk.org  Tue Oct 17 01:32:48 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 01:32:48 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
Message-ID: <bUf8lkjETd47zCEB3c4P3jcobPF48GCLEmn6ln0BgvM=.4e3f62af-fb66-4a79-acc8-1b8040132a4a@github.com>

On Mon, 16 Oct 2023 18:25:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Patch adds MaxSpecies support for all types of vectors.
>> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
>> - Disable CDS archiving of VectorPayload classes.
>> - Summary of high level flow :-
>>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/cpu/x86/vm_version_x86.cpp line 3232:

> 3230:     size = (VM_Version::supports_avx512bw()) ? 64 : 32;
> 3231:   // Use flag to limit vector size.
> 3232:   size = MIN2(size,(int)MaxVectorSize);

Since `MaxVectorSize` is a C2 specific version, what the behavior if c2 is disabled? Do you think we need consider `#if COMPILER2` here?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1361410557


From jbhateja at openjdk.org  Tue Oct 17 02:01:39 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Oct 2023 02:01:39 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <NK3bRi4WFAh9SUGGFgBNirk7T7Fjbo_k_DRqReJA314=.792947c7-60a2-4626-9253-bd985e685868@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
 <NK3bRi4WFAh9SUGGFgBNirk7T7Fjbo_k_DRqReJA314=.792947c7-60a2-4626-9253-bd985e685868@github.com>
Message-ID: <OLFhRBSuOdkT6UVi6VYPdHm3d9j5DXs-KXS-1gA_oDU=.12bf9029-7f55-48ea-a2b8-603b348ec897@github.com>

On Tue, 17 Oct 2023 01:08:35 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Generally LGTM! Just some minor code style.

Hi @XiaohongGong ,

Just to confirm do you still see the failing regressions on AARCH64 ?

> src/hotspot/cpu/x86/vm_version_x86.cpp line 3232:
> 
>> 3230:     size = (VM_Version::supports_avx512bw()) ? 64 : 32;
>> 3231:   // Use flag to limit vector size.
>> 3232:   size = MIN2(size,(int)MaxVectorSize);
> 
> Since `MaxVectorSize` is a C2 specific version, what the behavior if c2 is disabled? Do you think we need consider `#if COMPILER2` here?

We do have a dependency on C2 one way or other,  I think we should preserve the existing behaviour which will return a -1 value.

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1765532980
PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1361424845


From xgong at openjdk.org  Tue Oct 17 02:01:39 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 02:01:39 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <OLFhRBSuOdkT6UVi6VYPdHm3d9j5DXs-KXS-1gA_oDU=.12bf9029-7f55-48ea-a2b8-603b348ec897@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
 <NK3bRi4WFAh9SUGGFgBNirk7T7Fjbo_k_DRqReJA314=.792947c7-60a2-4626-9253-bd985e685868@github.com>
 <OLFhRBSuOdkT6UVi6VYPdHm3d9j5DXs-KXS-1gA_oDU=.12bf9029-7f55-48ea-a2b8-603b348ec897@github.com>
Message-ID: <8hIabEQbMokFoLy-coMUTXHABZ-Xad5biNjk3ta1LTo=.b9669230-5ab3-484e-9967-4032b7dca4c2@github.com>

On Tue, 17 Oct 2023 01:56:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Generally LGTM! Just some minor code style.
> 
> Hi @XiaohongGong ,
> 
> Just to confirm do you still see the failing regressions on AARCH64 ?

Yes, `DoubeMaxVectorTests.java` still has regression like:

test DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(double[cornerCaseValue(i)], mask[i % 2]): failure
java.lang.AssertionError: expected [true] but found [false]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:819)
        at org.testng.Assert.assertEquals(Assert.java:829)
        at DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(DoubleMaxVectorTests.java:2716)

All other tests pass except this one.

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1765535410


From jbhateja at openjdk.org  Tue Oct 17 02:10:39 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Oct 2023 02:10:39 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <8hIabEQbMokFoLy-coMUTXHABZ-Xad5biNjk3ta1LTo=.b9669230-5ab3-484e-9967-4032b7dca4c2@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
 <NK3bRi4WFAh9SUGGFgBNirk7T7Fjbo_k_DRqReJA314=.792947c7-60a2-4626-9253-bd985e685868@github.com>
 <OLFhRBSuOdkT6UVi6VYPdHm3d9j5DXs-KXS-1gA_oDU=.12bf9029-7f55-48ea-a2b8-603b348ec897@github.com>
 <8hIabEQbMokFoLy-coMUTXHABZ-Xad5biNjk3ta1LTo=.b9669230-5ab3-484e-9967-4032b7dca4c2@github.com>
Message-ID: <wFRwZTdIvdCWaTmeroop2Ky_4bumGJe4QG9Z21C5leQ=.de462edd-e78d-4ff5-b18e-6205c9c8b7d5@github.com>

On Tue, 17 Oct 2023 01:59:38 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > > Generally LGTM! Just some minor code style.
> > 
> > 
> > Hi @XiaohongGong ,
> > Just to confirm do you still see the failing regressions on AARCH64 ?
> 
> Yes, `DoubeMaxVectorTests.java` still has regression like:
> 
> ```
> test DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(double[cornerCaseValue(i)], mask[i % 2]): failure
> java.lang.AssertionError: expected [true] but found [false]
>         at org.testng.Assert.fail(Assert.java:99)
>         at org.testng.Assert.failNotEquals(Assert.java:1037)
>         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
>         at org.testng.Assert.assertEquals(Assert.java:122)
>         at org.testng.Assert.assertEquals(Assert.java:819)
>         at org.testng.Assert.assertEquals(Assert.java:829)
>         at DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(DoubleMaxVectorTests.java:2716)
> ```
> 
> All other tests pass except this one.

May I request to to root cause and share your observations.

Best Regards

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1765540624


From xgong at openjdk.org  Tue Oct 17 02:17:53 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 02:17:53 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
Message-ID: <7orZcUuiKiNUtwqYAplC5bMabn1o0ku7UAee3Yzw7_s=.4bcfcca1-79a7-4ef0-b2f1-2c8570c68464@github.com>

On Mon, 16 Oct 2023 18:25:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Patch adds MaxSpecies support for all types of vectors.
>> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
>> - Disable CDS archiving of VectorPayload classes.
>> - Summary of high level flow :-
>>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/share/ci/ciEnv.cpp line 1776:

> 1774: bool ciEnv::is_multifield_scalarized(BasicType bt, int vec_length) {
> 1775: #if COMPILER2
> 1776:   CompilerThread* ct = CompilerThread::current();

Could you please change `#if COMPILER2` to `#ifdef COMPILER2` ? This makes the jdk build error with `--configure-args --with-jvm-features=-compiler2`

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1361432201


From xgong at openjdk.org  Tue Oct 17 02:32:51 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 02:32:51 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <OLFhRBSuOdkT6UVi6VYPdHm3d9j5DXs-KXS-1gA_oDU=.12bf9029-7f55-48ea-a2b8-603b348ec897@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
 <NK3bRi4WFAh9SUGGFgBNirk7T7Fjbo_k_DRqReJA314=.792947c7-60a2-4626-9253-bd985e685868@github.com>
 <OLFhRBSuOdkT6UVi6VYPdHm3d9j5DXs-KXS-1gA_oDU=.12bf9029-7f55-48ea-a2b8-603b348ec897@github.com>
Message-ID: <upFCFTTD120zbnHb2k9EKWDHVrWtaj3XY98bWlI96QE=.0a072b07-de72-411b-8034-510081faacc3@github.com>

On Tue, 17 Oct 2023 01:58:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 3232:
>> 
>>> 3230:     size = (VM_Version::supports_avx512bw()) ? 64 : 32;
>>> 3231:   // Use flag to limit vector size.
>>> 3232:   size = MIN2(size,(int)MaxVectorSize);
>> 
>> Since `MaxVectorSize` is a C2 specific version, what the behavior if c2 is disabled? Do you think we need consider `#if COMPILER2` here?
>
> We do have a dependency on C2 one way or other,  I think we should preserve the existing behaviour which will return a -1 value.

This makes jdk build failure with `--configure-args --with-jvm-features=-compiler2 --configure-args --with-jvm-variants=client`. So maybe we have to separate with `#ifdef COMPILER2` and return `-1` for another path.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1361439332


From xgong at openjdk.org  Tue Oct 17 02:58:56 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 17 Oct 2023 02:58:56 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <wFRwZTdIvdCWaTmeroop2Ky_4bumGJe4QG9Z21C5leQ=.de462edd-e78d-4ff5-b18e-6205c9c8b7d5@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
 <NK3bRi4WFAh9SUGGFgBNirk7T7Fjbo_k_DRqReJA314=.792947c7-60a2-4626-9253-bd985e685868@github.com>
 <OLFhRBSuOdkT6UVi6VYPdHm3d9j5DXs-KXS-1gA_oDU=.12bf9029-7f55-48ea-a2b8-603b348ec897@github.com>
 <8hIabEQbMokFoLy-coMUTXHABZ-Xad5biNjk3ta1LTo=.b9669230-5ab3-484e-9967-4032b7dca4c2@github.com>
 <wFRwZTdIvdCWaTmeroop2Ky_4bumGJe4QG9Z21C5leQ=.de462edd-e78d-4ff5-b18e-6205c9c8b7d5@github.com>
Message-ID: <pe84w0l8q2bx8TvjDKDvbCA2YJxiL5Z_dCA_6u_navA=.673a6e5a-14b2-4951-bd0a-810cf2535bc1@github.com>

On Tue, 17 Oct 2023 02:06:26 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > > Generally LGTM! Just some minor code style.
> > > 
> > > 
> > > Hi @XiaohongGong ,
> > > Just to confirm do you still see the failing regressions on AARCH64 ?
> > 
> > 
> > Yes, `DoubeMaxVectorTests.java` still has regression like:
> > ```
> > test DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(double[cornerCaseValue(i)], mask[i % 2]): failure
> > java.lang.AssertionError: expected [true] but found [false]
> >         at org.testng.Assert.fail(Assert.java:99)
> >         at org.testng.Assert.failNotEquals(Assert.java:1037)
> >         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
> >         at org.testng.Assert.assertEquals(Assert.java:122)
> >         at org.testng.Assert.assertEquals(Assert.java:819)
> >         at org.testng.Assert.assertEquals(Assert.java:829)
> >         at DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(DoubleMaxVectorTests.java:2716)
> > ```
> > 
> > 
> > All other tests pass except this one.
> 
> May I request to to root cause and share your observations.
> 
> Best Regards

Not sure whether this is the same reason with the regressions with `-XX:+DeoptimizeALot`. But we can integrate this patch first and revisit this issue together with `-XX:+DeoptimizeALot` issues.

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1765581724


From rcastanedalo at openjdk.org  Tue Oct 17 10:40:00 2023
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 17 Oct 2023 10:40:00 GMT
Subject: [lworld] RFR: 8316742: [lworld] Intrinsify Unsafe::isFlattenedArray()
Message-ID: <ZvWGA1TYvMeOT6ysCM4nbsfy29hzYf2c4aC3WGt22iY=.7cc2b212-59ef-4e02-8a75-8316574afb40@github.com>

This changeset introduces a compiler intrinsic for `jdk.internal.misc.Unsafe::isFlattenedArray(Class<?> arrayClass)`. The intrinsic reuses C2's `FlatArrayCheckNode`, and exploits the assumptions made by the native implementation (`arrayClass` is non-null and non-primitive) to avoid unnecessary null checks. Reusing `FlatArrayCheckNode` in this different context requires small generalizations of its macro expansion logic.

Additionally, the changeset removes a no-longer-needed check in `java.lang.invoke.VarHandles::makeArrayElementHandle(Class<?> arrayClass)` and re-enables the `compiler.gcbarriers::TestZGCBarrierElision` tests (whose failures were caused by the introduction of calls to `isFlattenedArray` inhibiting barrier optimizations).

Local experiments with the included micro-benchmarks show that the changeset:
- speeds up direct calls to `isFlattenedArray` by between 24x and 48x depending on whether the tested class is known to C2,
- speeds up `java.lang.invoke.VarHandle.set(Object... args)` by an order of magnitude, and
- preserves the performance of `java.lang.invoke.MethodHandles.arrayElementVarHandle(Class<?> arrayClass)` despite the simplification of the underlying `java.lang.invoke.VarHandles::makeArrayElementHandle(Class<?> arrayClass)` method.

Complete results are attached [here](https://github.com/openjdk/valhalla/files/12927498/results.ods).


#### Testing
- tier1-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, macosx-aarch64; release and debug mode)

**Acknowledgments:** thanks to Tobias Hartmann for discussions on earlier versions of this changeset.

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

Commit messages:
 - Refine comment, again
 - Refine comment
 - List new intrinsic consistently with definition order
 - Simplify microbenchmarks
 - Remove redundant check
 - Move implementation of isFlattenedArray into its own function again
 - Remove unnecessary array check, relax assertion
 - Update microbenchmarks
 - Add microbenchmarks
 - Add basic test cases
 - ... and 7 more: https://git.openjdk.org/valhalla/compare/3a5d7d9f...30b88700

Changes: https://git.openjdk.org/valhalla/pull/938/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=938&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316742
  Stats: 170 lines in 11 files changed: 162 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/938.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/938/head:pull/938

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


From jbhateja at openjdk.org  Wed Oct 18 00:35:45 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Oct 2023 00:35:45 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v5]
In-Reply-To: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
Message-ID: <pvzJmTkERceNa18fLiAbfTbEibkKcaMEQs88pXydyZI=.b9e1d009-405b-4b32-ba3b-726650e57a12@github.com>

> - Patch adds MaxSpecies support for all types of vectors.
> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
> - Disable CDS archiving of VectorPayload classes.
> - Summary of high level flow :-
>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Review comments resolutions

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/931/files
  - new: https://git.openjdk.org/valhalla/pull/931/files/945eb0fb..ffa108cd

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

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

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


From jbhateja at openjdk.org  Wed Oct 18 00:40:04 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Oct 2023 00:40:04 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v4]
In-Reply-To: <pe84w0l8q2bx8TvjDKDvbCA2YJxiL5Z_dCA_6u_navA=.673a6e5a-14b2-4951-bd0a-810cf2535bc1@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <_kSzDO5dlfmY4Cm-LBa5_yArxFz_CJOQs6-lFrX18Xs=.31bb2d9f-6a00-42c8-a5dd-d6938fca6dcc@github.com>
 <NK3bRi4WFAh9SUGGFgBNirk7T7Fjbo_k_DRqReJA314=.792947c7-60a2-4626-9253-bd985e685868@github.com>
 <OLFhRBSuOdkT6UVi6VYPdHm3d9j5DXs-KXS-1gA_oDU=.12bf9029-7f55-48ea-a2b8-603b348ec897@github.com>
 <8hIabEQbMokFoLy-coMUTXHABZ-Xad5biNjk3ta1LTo=.b9669230-5ab3-484e-9967-4032b7dca4c2@github.com>
 <wFRwZTdIvdCWaTmeroop2Ky_4bumGJe4QG9Z21C5leQ=.de462edd-e78d-4ff5-b18e-6205c9c8b7d5@github.com>
 <pe84w0l8q2bx8TvjDKDvbCA2YJxiL5Z_dCA_6u_navA=.673a6e5a-14b2-4951-bd0a-810cf2535bc1@github.com>
Message-ID: <H8_LxPbbfucAklBkH6JCkbAMW5vyBLVsq28MCqfyPKw=.d58abdb5-d9ab-416c-9a67-f85a817e7d69@github.com>

On Tue, 17 Oct 2023 02:56:16 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > > > > Generally LGTM! Just some minor code style.
> > > > 
> > > > 
> > > > Hi @XiaohongGong ,
> > > > Just to confirm do you still see the failing regressions on AARCH64 ?
> > > 
> > > 
> > > Yes, `DoubeMaxVectorTests.java` still has regression like:
> > > ```
> > > test DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(double[cornerCaseValue(i)], mask[i % 2]): failure
> > > java.lang.AssertionError: expected [true] but found [false]
> > >         at org.testng.Assert.fail(Assert.java:99)
> > >         at org.testng.Assert.failNotEquals(Assert.java:1037)
> > >         at org.testng.Assert.assertEqualsImpl(Assert.java:140)
> > >         at org.testng.Assert.assertEquals(Assert.java:122)
> > >         at org.testng.Assert.assertEquals(Assert.java:819)
> > >         at org.testng.Assert.assertEquals(Assert.java:829)
> > >         at DoubleMaxVectorTests.IS_FINITEMaskedDoubleMaxVectorTests(DoubleMaxVectorTests.java:2716)
> > > ```
> > > 
> > > 
> > > All other tests pass except this one.
> > 
> > 
> > May I request to to root cause and share your observations.
> > Best Regards
> 
> Not sure whether this is the same reason with the regressions with `-XX:+DeoptimizeALot`. But we can integrate this patch first and revisit this issue together with `-XX:+DeoptimizeALot` issues.

Yes, it looks unrelated to this patch.

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

PR Comment: https://git.openjdk.org/valhalla/pull/931#issuecomment-1767406601


From jbhateja at openjdk.org  Wed Oct 18 01:03:18 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Oct 2023 01:03:18 GMT
Subject: [lworld+vector] RFR: 8311675: [lworld+vector] Max Species support.
 [v3]
In-Reply-To: <-fFur9Z-yNjt1iS2IoH9p_rCAlAptsCUjcmb3g2nYbM=.68df3131-98df-485f-959b-61e2ac2ad416@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
 <UUed6m8B161nsmhnYCgyhSa9ItaknyI3EXLrUb6Rcr8=.2c7a0c93-9e8f-49cd-9e3b-917d5d1423c1@github.com>
 <xNeqjj86NCrLbbyi35Pen5_HJ6CzJls0v9GA5033D78=.db13b4ad-6f42-4ead-8d8d-0b1fdc5c5427@github.com>
 <a9MRuQVUb0cGOr6vdkvXwOBF0r2LXf7UONXkZcLaL6U=.b2d4f7c9-7074-4f79-9f87-340fd203af54@github.com>
 <4tfC39VxgrfNJJdbU-AqDoXD0VBsu7Md2eIVD72KGW8=.73fd6abe-8ddf-4a55-88fa-57dfb6f922f3@github.com>
 <iPYBzW_Uh-qXk1LIyWL1IMYEb3gJH4i9oywoy6Ec1ZA=.b29e09eb-22ee-4013-a754-40b4fe22904d@github.com>
 <-fFur9Z-yNjt1iS2IoH9p_rCAlAptsCUjcmb3g2nYbM=.68df3131-98df-485f-959b-61e2ac2ad416@github.com>
Message-ID: <KpINray2Cb2F-jZ-4O9m2beevAzvhRGmapCInEefb-E=.d5743342-01aa-4e49-bc70-2d4245677454@github.com>

On Tue, 17 Oct 2023 01:25:48 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Since we never expose concrete vector types to users hence its only possible to create an array of abstract vector references which can be heterogeneous. This is different from an array of value types which are implicitly final classes and may be flattened into a compact layout since such an array will be homogeneous in nature.
>
> Yeah, I understand. Maybe we could find other more general ways to forbit such kind of array flatten like vector objects, instead of hard coding the `vector/vector_payload` classes here. We can revisit this in future. WDYT?

> Thanks for the explanation! Seems it also causes the jvm crash in `VectorXXXConversionTests`, but I didn't figure out the root cause yet. 

In this case PhiNode generated by PredictedCallGenerator based on the type profile was imbalanced i.e. its inputs had different concrete payload types, thus type of PhiNode got resolved to lowest common ancestor type i.e. an abstract vector payload type, in the downstream flow following assertion failed because flat_array flag for the type was set even though the type was a non-inline type.

https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/type.cpp#L4177

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/931#discussion_r1362969857


From jbhateja at openjdk.org  Wed Oct 18 04:46:09 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Oct 2023 04:46:09 GMT
Subject: [lworld+vector] Integrated: 8311675: [lworld+vector] Max Species
 support.
In-Reply-To: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
References: <4eU1cg9HwjcdJnOQJMV0qhVhZLh0vvHzsO4zJj-CcUU=.cf7c8b21-4a63-4b9e-ba30-8bb10dba2fa9@github.com>
Message-ID: <pxRH7fqXI071eCWtPeM3vYThUMBVo9caVZtJnty33B4=.331fbd41-293a-4c52-91b8-2e5ad5cda6c7@github.com>

On Thu, 28 Sep 2023 18:02:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Patch adds MaxSpecies support for all types of vectors.
> - New factory methods and VectorPayload classes for various kinds of vector, shuffle and mask payloads.
> - Disable CDS archiving of VectorPayload classes.
> - Summary of high level flow :-
>   1/ Max species payloads encapsulate @multifield annotated field accepting -1 value as bundle size parameter.
>   2/ For Vector payload bundle size is determined using maximum vector size supported by the target. 
>   3/ For Shuffles and Masks payloads multifield bundle size is a function of maximum vector size and vector lane size.
>   4/ Based on the dynamic bundle size parser creates a separate FieldInfo structure for each base and synthetic multifield and rest of the flow remains the same. 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 5b2fa0aa
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5b2fa0aabed89f1755ae02145f56ead3182b9f09
Stats:     6793 lines in 73 files changed: 6002 ins; 346 del; 445 mod

8311675: [lworld+vector] Max Species support.

Reviewed-by: xgong

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

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


From jbhateja at openjdk.org  Wed Oct 18 06:19:31 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Oct 2023 06:19:31 GMT
Subject: [lworld+fp16] Integrated: [lworld+fp16] Merge lworld
Message-ID: <gl9HpM0wUXBQCsGj5zdP1uJq6EnSiYQ_R3Wv0zY6M-k=.8aeb706f-5c3b-487e-933e-70addedba9a9@github.com>

Merge latest lworld into lworld+fp16.

Thanks,
Jatin

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

Commit messages:
 - Merge lworld

Changes: https://git.openjdk.org/valhalla/pull/939/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=939&range=00
  Stats: 82889 lines in 2183 files changed: 43612 ins; 26226 del; 13051 mod
  Patch: https://git.openjdk.org/valhalla/pull/939.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/939/head:pull/939

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


From jbhateja at openjdk.org  Wed Oct 18 06:19:33 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 18 Oct 2023 06:19:33 GMT
Subject: [lworld+fp16] Integrated: [lworld+fp16] Merge lworld
In-Reply-To: <gl9HpM0wUXBQCsGj5zdP1uJq6EnSiYQ_R3Wv0zY6M-k=.8aeb706f-5c3b-487e-933e-70addedba9a9@github.com>
References: <gl9HpM0wUXBQCsGj5zdP1uJq6EnSiYQ_R3Wv0zY6M-k=.8aeb706f-5c3b-487e-933e-70addedba9a9@github.com>
Message-ID: <kLzx-eWhS4h7frc8GoayD9eeodLnUChWiqB5tSob9so=.57f95d03-a40d-4642-a014-27519f4b4117@github.com>

On Wed, 18 Oct 2023 05:59:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge latest lworld into lworld+fp16.
> 
> Thanks,
> Jatin

This pull request has now been integrated.

Changeset: 6f1ecb88
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6f1ecb88a6f59a10b3b60d24dce02d16735010e3
Stats:     82889 lines in 2183 files changed: 43612 ins; 26226 del; 13051 mod

[lworld+fp16] Merge lworld

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

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


From thartmann at openjdk.org  Wed Oct 18 08:25:53 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 18 Oct 2023 08:25:53 GMT
Subject: [lworld] RFR: 8316742: [lworld] Intrinsify
 Unsafe::isFlattenedArray()
In-Reply-To: <ZvWGA1TYvMeOT6ysCM4nbsfy29hzYf2c4aC3WGt22iY=.7cc2b212-59ef-4e02-8a75-8316574afb40@github.com>
References: <ZvWGA1TYvMeOT6ysCM4nbsfy29hzYf2c4aC3WGt22iY=.7cc2b212-59ef-4e02-8a75-8316574afb40@github.com>
Message-ID: <SeyhzZHdiG9hKL7crcq5WeLid7StB7yHKac29oJzSi8=.8c245625-e24f-4e61-bd50-1527c5596d7e@github.com>

On Tue, 17 Oct 2023 10:15:39 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This changeset introduces a compiler intrinsic for `jdk.internal.misc.Unsafe::isFlattenedArray(Class<?> arrayClass)`. The intrinsic reuses C2's `FlatArrayCheckNode`, and exploits the assumptions made by the native implementation (`arrayClass` is non-null and non-primitive) to avoid unnecessary null checks. Reusing `FlatArrayCheckNode` in this different context requires small generalizations of its macro expansion logic.
> 
> Additionally, the changeset removes a no-longer-needed check in `java.lang.invoke.VarHandles::makeArrayElementHandle(Class<?> arrayClass)` and re-enables the `compiler.gcbarriers::TestZGCBarrierElision` tests (whose failures were caused by the introduction of calls to `isFlattenedArray` inhibiting barrier optimizations).
> 
> Local experiments with the included micro-benchmarks show that the changeset:
> - speeds up direct calls to `isFlattenedArray` by between 24x and 48x depending on whether the tested class is known to C2,
> - speeds up `java.lang.invoke.VarHandle.set(Object... args)` by an order of magnitude, and
> - preserves the performance of `java.lang.invoke.MethodHandles.arrayElementVarHandle(Class<?> arrayClass)` despite the simplification of the underlying `java.lang.invoke.VarHandles::makeArrayElementHandle(Class<?> arrayClass)` method.
> 
> Complete results are attached [here](https://github.com/openjdk/valhalla/files/12927498/results.ods).
> 
> 
> #### Testing
> - tier1-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, macosx-aarch64; release and debug mode)
> 
> **Acknowledgments:** thanks to Tobias Hartmann for discussions on earlier versions of this changeset.

Looks great, thanks for working on this Roberto!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/938#pullrequestreview-1684406517


From rcastanedalo at openjdk.org  Wed Oct 18 08:57:39 2023
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 18 Oct 2023 08:57:39 GMT
Subject: [lworld] RFR: 8316742: [lworld] Intrinsify
 Unsafe::isFlattenedArray()
In-Reply-To: <ZvWGA1TYvMeOT6ysCM4nbsfy29hzYf2c4aC3WGt22iY=.7cc2b212-59ef-4e02-8a75-8316574afb40@github.com>
References: <ZvWGA1TYvMeOT6ysCM4nbsfy29hzYf2c4aC3WGt22iY=.7cc2b212-59ef-4e02-8a75-8316574afb40@github.com>
Message-ID: <gWHdFsN2vQyihOFzecjKKFWxZ2_UcvGmS21uXkoi5XQ=.ce4b1568-2f3a-4fd7-8d3a-8325f6597a45@github.com>

On Tue, 17 Oct 2023 10:15:39 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This changeset introduces a compiler intrinsic for `jdk.internal.misc.Unsafe::isFlattenedArray(Class<?> arrayClass)`. The intrinsic reuses C2's `FlatArrayCheckNode`, and exploits the assumptions made by the native implementation (`arrayClass` is non-null and non-primitive) to avoid unnecessary null checks. Reusing `FlatArrayCheckNode` in this different context requires small generalizations of its macro expansion logic.
> 
> Additionally, the changeset removes a no-longer-needed check in `java.lang.invoke.VarHandles::makeArrayElementHandle(Class<?> arrayClass)` and re-enables the `compiler.gcbarriers::TestZGCBarrierElision` tests (whose failures were caused by the introduction of calls to `isFlattenedArray` inhibiting barrier optimizations).
> 
> Local experiments with the included micro-benchmarks show that the changeset:
> - speeds up direct calls to `isFlattenedArray` by between 24x and 48x depending on whether the tested class is known to C2,
> - speeds up `java.lang.invoke.VarHandle.set(Object... args)` by an order of magnitude, and
> - preserves the performance of `java.lang.invoke.MethodHandles.arrayElementVarHandle(Class<?> arrayClass)` despite the simplification of the underlying `java.lang.invoke.VarHandles::makeArrayElementHandle(Class<?> arrayClass)` method.
> 
> Complete results are attached [here](https://github.com/openjdk/valhalla/files/12927498/results.ods).
> 
> 
> #### Testing
> - tier1-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, macosx-aarch64; release and debug mode)
> 
> **Acknowledgments:** thanks to Tobias Hartmann for discussions on earlier versions of this changeset.

Thanks for reviewing, Tobias! Please sponsor.

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

PR Comment: https://git.openjdk.org/valhalla/pull/938#issuecomment-1767993710


From rcastanedalo at openjdk.org  Wed Oct 18 09:23:27 2023
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 18 Oct 2023 09:23:27 GMT
Subject: [lworld] Integrated: 8316742: [lworld] Intrinsify
 Unsafe::isFlattenedArray()
In-Reply-To: <ZvWGA1TYvMeOT6ysCM4nbsfy29hzYf2c4aC3WGt22iY=.7cc2b212-59ef-4e02-8a75-8316574afb40@github.com>
References: <ZvWGA1TYvMeOT6ysCM4nbsfy29hzYf2c4aC3WGt22iY=.7cc2b212-59ef-4e02-8a75-8316574afb40@github.com>
Message-ID: <NLRPXt8IYLyIXPdIX1do3Cp206-DYFIJIJY0gtFAM5U=.cefc7402-cf3f-4cf1-85cb-95fbfd83b46b@github.com>

On Tue, 17 Oct 2023 10:15:39 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This changeset introduces a compiler intrinsic for `jdk.internal.misc.Unsafe::isFlattenedArray(Class<?> arrayClass)`. The intrinsic reuses C2's `FlatArrayCheckNode`, and exploits the assumptions made by the native implementation (`arrayClass` is non-null and non-primitive) to avoid unnecessary null checks. Reusing `FlatArrayCheckNode` in this different context requires small generalizations of its macro expansion logic.
> 
> Additionally, the changeset removes a no-longer-needed check in `java.lang.invoke.VarHandles::makeArrayElementHandle(Class<?> arrayClass)` and re-enables the `compiler.gcbarriers::TestZGCBarrierElision` tests (whose failures were caused by the introduction of calls to `isFlattenedArray` inhibiting barrier optimizations).
> 
> Local experiments with the included micro-benchmarks show that the changeset:
> - speeds up direct calls to `isFlattenedArray` by between 24x and 48x depending on whether the tested class is known to C2,
> - speeds up `java.lang.invoke.VarHandle.set(Object... args)` by an order of magnitude, and
> - preserves the performance of `java.lang.invoke.MethodHandles.arrayElementVarHandle(Class<?> arrayClass)` despite the simplification of the underlying `java.lang.invoke.VarHandles::makeArrayElementHandle(Class<?> arrayClass)` method.
> 
> Complete results are attached [here](https://github.com/openjdk/valhalla/files/12927498/results.ods).
> 
> 
> #### Testing
> - tier1-5 (windows-x64, linux-x64, linux-aarch64, macosx-x64, macosx-aarch64; release and debug mode)
> 
> **Acknowledgments:** thanks to Tobias Hartmann for discussions on earlier versions of this changeset.

This pull request has now been integrated.

Changeset: 985474d2
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/985474d2e685b4037bd867c20f41ae03637aaeb6
Stats:     170 lines in 11 files changed: 162 ins; 4 del; 4 mod

8316742: [lworld] Intrinsify Unsafe::isFlattenedArray()

Reviewed-by: thartmann

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

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


From archie.cobbs at gmail.com  Wed Oct 18 19:12:21 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 18 Oct 2023 14:12:21 -0500
Subject: JDK-8317277 - Java language implementation of value classes and
 objects
Message-ID: <CANSoFxsKszJecd0dOgJV8An7+U17Dxt5_a0uzMHHhtpDofeFag@mail.gmail.com>

Hopefully this is the right place to comment on this ticket:
https://bugs.openjdk.org/browse/JDK-8317277

The one permitted use of the current class instance, implicitly or
> explicitly, is to write to instance fields of the class, either of the form
> 'f = expr' or 'this.f = expr'.
>
> (This deviates from the usual "pre-construction context" rules; TBD
> whether we're expanding the set of permitted actions in a pre-construction
> context (thus permitting field writes before a super() call in *any*
> constructor), or whether we're introducing a slightly different context
> that covers the space between the end of the 'super()' call and the end of
> the constructor execution.)


Allowing assignment of instance fields was discussed as an option for JEP
447, but we said no mainly to take the conservative route i.e., not try to
change too much at once.

If JEP 447 is going to allow pre-construction assignment of instance fields
in value classes and we don't also extend that to identity classes, then it
seems like we'd be creating a worst-of-both-worlds scenario: added
specification & compiler complexity to provide a desirable new feature, but
making it available only some of the time. The result will be developers
having to maintain a more complex mental model in their heads regarding
what rules apply when, and being frustrated by the seeming arbitrariness of
the distinction.

So my vote would be that we allow the assignment of instance fields in
identity classes as well. In theory that could happen in either JEP but
probably JEP 447 makes more sense.

Also, I have a couple of totally unrelated questions about value classes...

1. If v is a value object, what does System.identityHashCode(v) return?
2. If V is a value class, is {Weak,Soft,Phantom}Reference<V> supported?

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20231018/bbfb0f7f/attachment.htm>

From forax at univ-mlv.fr  Wed Oct 18 20:59:34 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 18 Oct 2023 22:59:34 +0200 (CEST)
Subject: JDK-8317277 - Java language implementation of value classes and
 objects
In-Reply-To: <CANSoFxsKszJecd0dOgJV8An7+U17Dxt5_a0uzMHHhtpDofeFag@mail.gmail.com>
References: <CANSoFxsKszJecd0dOgJV8An7+U17Dxt5_a0uzMHHhtpDofeFag@mail.gmail.com>
Message-ID: <828048091.28449378.1697662774876.JavaMail.zimbra@univ-eiffel.fr>

> From: "Archie Cobbs" <archie.cobbs at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Wednesday, October 18, 2023 9:12:21 PM
> Subject: JDK-8317277 - Java language implementation of value classes and objects

... 

> Also, I have a couple of totally unrelated questions about value classes...

> 1. If v is a value object, what does System.identityHashCode(v) return?

A combination of some field values of the object. 
It has to be fast so the VM should not use all fields if there are a lot of them or if some values are value class (or field type that can potentially store value class) because it will make the computation recursive. 

> 2. If V is a value class, is {Weak,Soft,Phantom}Reference<V> supported?

Nope. There is maybe no address/no pointer so no weak reference. 

> -Archie

> --
> Archie L. Cobbs

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

From archie.cobbs at gmail.com  Wed Oct 18 21:33:45 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 18 Oct 2023 16:33:45 -0500
Subject: JDK-8317277 - Java language implementation of value classes and
 objects
In-Reply-To: <828048091.28449378.1697662774876.JavaMail.zimbra@univ-eiffel.fr>
References: <CANSoFxsKszJecd0dOgJV8An7+U17Dxt5_a0uzMHHhtpDofeFag@mail.gmail.com>
 <828048091.28449378.1697662774876.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CANSoFxuv0_7u6BiAGdN2boODTL4q-H=bYQzNr4kY-zexf8wUVg@mail.gmail.com>

On Wed, Oct 18, 2023 at 3:59?PM Remi Forax <forax at univ-mlv.fr> wrote:

>
> 1. If v is a value object, what does System.identityHashCode(v) return?
>
>
> A combination of some field values of the object.
> It has to be fast so the VM should not use all fields if there are a lot
> of them or if some values are value class (or field type that can
> potentially store value class) because it will make the computation
> recursive.
>

Hmm, that doesn't seem right.

Isn't it hashCode()'s job to produce a value based on the object's fields?
The whole point of System.identityHashCode() is to NOT do that, at least as
of today.

I'd expect System.identityHashCode() to return 0 for all value classes or
throw an exception.

After all, value classes are not supposed to have an identity, right?


> 2. If V is a value class, is {Weak,Soft,Phantom}Reference<V> supported?
>
>
> Nope. There is maybe no address/no pointer so no weak reference.
>

OK. How is this going to be enforced?

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20231018/af395fae/attachment.htm>

From davidalayachew at gmail.com  Wed Oct 18 23:18:59 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 18 Oct 2023 19:18:59 -0400
Subject: JDK-8317277 - Java language implementation of value classes and
 objects
In-Reply-To: <CANSoFxuv0_7u6BiAGdN2boODTL4q-H=bYQzNr4kY-zexf8wUVg@mail.gmail.com>
References: <CANSoFxsKszJecd0dOgJV8An7+U17Dxt5_a0uzMHHhtpDofeFag@mail.gmail.com>
 <828048091.28449378.1697662774876.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxuv0_7u6BiAGdN2boODTL4q-H=bYQzNr4kY-zexf8wUVg@mail.gmail.com>
Message-ID: <CAA9v-_O4wkJTvtWBh6G8QXSfsNgc05=hmdym-YS94+KHsZ8w4g@mail.gmail.com>

Potentially silly question in regards to the identityHashCode.

Is it possible for an identityHashCode to produce a negative value?

I tried the following, and it is still running. I don't have any window
functions though, so I can't make arbitrary strings, just one character
ones.

$ jshell
|  Welcome to JShell -- Version 21
|  For an introduction type: /help intro

jshell> new java.util.Random()
   ...> .ints()
   ...> .filter(Character::isValidCodePoint)
   ...> .mapToObj(Character::toChars)
   ...> .map(String::new)
   ...> .mapToInt(System::identityHashCode)
   ...> .filter(a -> a < 0)
   ...> .findFirst()

If the answer is, no negatives, then I think this would be best. I don't
know if it would be "all value objects are -1", or something else.


On Wed, Oct 18, 2023 at 5:35?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Wed, Oct 18, 2023 at 3:59?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>>
>> 1. If v is a value object, what does System.identityHashCode(v) return?
>>
>>
>> A combination of some field values of the object.
>> It has to be fast so the VM should not use all fields if there are a lot
>> of them or if some values are value class (or field type that can
>> potentially store value class) because it will make the computation
>> recursive.
>>
>
> Hmm, that doesn't seem right.
>
> Isn't it hashCode()'s job to produce a value based on the object's
> fields? The whole point of System.identityHashCode() is to NOT do that,
> at least as of today.
>
> I'd expect System.identityHashCode() to return 0 for all value classes or
> throw an exception.
>
> After all, value classes are not supposed to have an identity, right?
>
>
>> 2. If V is a value class, is {Weak,Soft,Phantom}Reference<V> supported?
>>
>>
>> Nope. There is maybe no address/no pointer so no weak reference.
>>
>
> OK. How is this going to be enforced?
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20231018/9949b01e/attachment.htm>

From davidalayachew at gmail.com  Wed Oct 18 23:21:13 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 18 Oct 2023 19:21:13 -0400
Subject: JDK-8317277 - Java language implementation of value classes and
 objects
In-Reply-To: <CAA9v-_O4wkJTvtWBh6G8QXSfsNgc05=hmdym-YS94+KHsZ8w4g@mail.gmail.com>
References: <CANSoFxsKszJecd0dOgJV8An7+U17Dxt5_a0uzMHHhtpDofeFag@mail.gmail.com>
 <828048091.28449378.1697662774876.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxuv0_7u6BiAGdN2boODTL4q-H=bYQzNr4kY-zexf8wUVg@mail.gmail.com>
 <CAA9v-_O4wkJTvtWBh6G8QXSfsNgc05=hmdym-YS94+KHsZ8w4g@mail.gmail.com>
Message-ID: <CAA9v-_Nry3-jY5Gges2X6Va4JtXRVQ68yL-sdUESwA2pAHdSLw@mail.gmail.com>

To respond to your actual point though, I think it would be great for
identity classes to get this too.

On Wed, Oct 18, 2023 at 7:18?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Potentially silly question in regards to the identityHashCode.
>
> Is it possible for an identityHashCode to produce a negative value?
>
> I tried the following, and it is still running. I don't have any window
> functions though, so I can't make arbitrary strings, just one character
> ones.
>
> $ jshell
> |  Welcome to JShell -- Version 21
> |  For an introduction type: /help intro
>
> jshell> new java.util.Random()
>    ...> .ints()
>    ...> .filter(Character::isValidCodePoint)
>    ...> .mapToObj(Character::toChars)
>    ...> .map(String::new)
>    ...> .mapToInt(System::identityHashCode)
>    ...> .filter(a -> a < 0)
>    ...> .findFirst()
>
> If the answer is, no negatives, then I think this would be best. I don't
> know if it would be "all value objects are -1", or something else.
>
>
> On Wed, Oct 18, 2023 at 5:35?PM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> On Wed, Oct 18, 2023 at 3:59?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>>
>>> 1. If v is a value object, what does System.identityHashCode(v) return?
>>>
>>>
>>> A combination of some field values of the object.
>>> It has to be fast so the VM should not use all fields if there are a lot
>>> of them or if some values are value class (or field type that can
>>> potentially store value class) because it will make the computation
>>> recursive.
>>>
>>
>> Hmm, that doesn't seem right.
>>
>> Isn't it hashCode()'s job to produce a value based on the object's
>> fields? The whole point of System.identityHashCode() is to NOT do that,
>> at least as of today.
>>
>> I'd expect System.identityHashCode() to return 0 for all value classes
>> or throw an exception.
>>
>> After all, value classes are not supposed to have an identity, right?
>>
>>
>>> 2. If V is a value class, is {Weak,Soft,Phantom}Reference<V> supported?
>>>
>>>
>>> Nope. There is maybe no address/no pointer so no weak reference.
>>>
>>
>> OK. How is this going to be enforced?
>>
>> -Archie
>>
>> --
>> Archie L. Cobbs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20231018/ceba96b2/attachment.htm>

From vromero at openjdk.org  Fri Oct 20 18:59:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 20 Oct 2023 18:59:32 GMT
Subject: RFR: 8318117: [lw5] create a switch for null-restricted types
Message-ID: <5zlyw4CTxp6ANHz8mgY2NTO0KChwOVM4iNpOhL1S4AE=.2ca1f65b-db3c-4c8f-9b47-4344b1e79945@github.com>

switch for opt-in for null restricted types features

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

Commit messages:
 - removing white space
 - 8318117: [lw5] create a switch for null-restricted types

Changes: https://git.openjdk.org/valhalla/pull/940/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=940&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318117
  Stats: 382 lines in 48 files changed: 116 ins; 47 del; 219 mod
  Patch: https://git.openjdk.org/valhalla/pull/940.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/940/head:pull/940

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


From vromero at openjdk.org  Fri Oct 20 19:21:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 20 Oct 2023 19:21:06 GMT
Subject: Integrated: 8318117: [lw5] create a switch for null-restricted types
In-Reply-To: <5zlyw4CTxp6ANHz8mgY2NTO0KChwOVM4iNpOhL1S4AE=.2ca1f65b-db3c-4c8f-9b47-4344b1e79945@github.com>
References: <5zlyw4CTxp6ANHz8mgY2NTO0KChwOVM4iNpOhL1S4AE=.2ca1f65b-db3c-4c8f-9b47-4344b1e79945@github.com>
Message-ID: <ejWeiqk4SUJMVxVl146KheCftTop76BBhSXQAtL999Y=.935899ad-f0fa-47ad-b64f-4d069cec572b@github.com>

On Fri, 20 Oct 2023 18:28:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> switch for opt-in for null restricted types features

This pull request has now been integrated.

Changeset: 8a098a88
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8a098a888adfd8146340a651349014b8c82a8a2e
Stats:     382 lines in 48 files changed: 116 ins; 47 del; 219 mod

8318117: [lw5] create a switch for null-restricted types

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

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


From vromero at openjdk.org  Fri Oct 20 20:23:16 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 20 Oct 2023 20:23:16 GMT
Subject: Integrated: Merge lworld
Message-ID: <UXt2zXXWaqR16iv02qdSELpiB5EB1U_t6J7O8XYNW6c=.6cb6b537-cd2f-418b-86bb-9e979d0c2d63@github.com>

Merge branch 'lworld' into lw5_merge_lworld
# Conflicts:
#	test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.java

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - 8316742: [lworld] Intrinsify Unsafe::isFlattenedArray()
 - 8317658: [lworld] TemplateTable::withfield() does not correctly load the ResolvedFieldEntry
 - Merge jdk
 - 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base
 - 8313765: Invalid CEN header (invalid zip64 extra data field size)
 - 8310275: Bug in assignment operator of ReservedMemoryRegion
 - 8314144: gc/g1/ihop/TestIHOPStatic.java fails due to extra concurrent mark with -Xcomp
 - 8314209: Wrong @since tag for RandomGenerator::equiDoubles
 - 8314211: Add NativeLibraryUnload event
 - ... and 150 more: https://git.openjdk.org/valhalla/compare/8a098a88...9d963e2a

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

Changes: https://git.openjdk.org/valhalla/pull/941/files
  Stats: 22500 lines in 939 files changed: 10735 ins; 4761 del; 7004 mod
  Patch: https://git.openjdk.org/valhalla/pull/941.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/941/head:pull/941

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


From vromero at openjdk.org  Fri Oct 20 20:23:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 20 Oct 2023 20:23:17 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <UXt2zXXWaqR16iv02qdSELpiB5EB1U_t6J7O8XYNW6c=.6cb6b537-cd2f-418b-86bb-9e979d0c2d63@github.com>
References: <UXt2zXXWaqR16iv02qdSELpiB5EB1U_t6J7O8XYNW6c=.6cb6b537-cd2f-418b-86bb-9e979d0c2d63@github.com>
Message-ID: <CRfQIMUhW8O8fxZWwGivEsHRHI1Au3d3Loiawz8ge8M=.ef30ee66-9ecb-482e-b7d3-5d4cf324fab4@github.com>

On Fri, 20 Oct 2023 20:18:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld
> # Conflicts:
> #	test/langtools/lib/annotations/annotations/classfile/ClassfileInspector.java

This pull request has now been integrated.

Changeset: 7e70c26d
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7e70c26d5dd73b083b8253316665d9b16027d15e
Stats:     22500 lines in 939 files changed: 10735 ins; 4761 del; 7004 mod

Merge lworld

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

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


From liangchenblue at gmail.com  Sat Oct 21 06:37:19 2023
From: liangchenblue at gmail.com (-)
Date: Sat, 21 Oct 2023 14:37:19 +0800
Subject: Ensuring atomicity of long values
Message-ID: <CABe8uE1Wg=ur47DwV=zu8FeA2hokdLu+RyfD8UjTnwJwFC5oxA@mail.gmail.com>

Hello valhalla community,
While looking at the new non-atomic model that allows flattening in the
heap, I wonder if we can represent null-restricted 64-bit atomic data where
the most and the least significant bits shouldn't tear.

An example would be a modifier collection, where some modifier bits are
dependent on others, while 0 (the default) is a valid value. One such
dependency present in JDK itself is that ABSTRACT modifier must be set if
INTERFACE modifier is, and at most one of PUBLIC, PRIVATE, or PROTECTED
modifiers can be set. Such constraints can happen across the 32-bit
boundary, and thus primitive long is not a suitable choice for
its non-atomicity.

How should I declare a value class that ensures atomicity of the
null-restricted long value it contains? And how can a correct declaration
consistently benefit from the 64-bit atomic operations offered on modern
architectures?

Truly curious,
Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20231021/b8bf3233/attachment.htm>

From forax at univ-mlv.fr  Sat Oct 21 08:46:22 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 21 Oct 2023 10:46:22 +0200 (CEST)
Subject: Ensuring atomicity of long values
In-Reply-To: <CABe8uE1Wg=ur47DwV=zu8FeA2hokdLu+RyfD8UjTnwJwFC5oxA@mail.gmail.com>
References: <CABe8uE1Wg=ur47DwV=zu8FeA2hokdLu+RyfD8UjTnwJwFC5oxA@mail.gmail.com>
Message-ID: <767063148.31055536.1697877982716.JavaMail.zimbra@univ-eiffel.fr>

> From: "-" <liangchenblue at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Saturday, October 21, 2023 8:37:19 AM
> Subject: Ensuring atomicity of long values

> Hello valhalla community,
> While looking at the new non-atomic model that allows flattening in the heap, I
> wonder if we can represent null-restricted 64-bit atomic data where the most
> and the least significant bits shouldn't tear.

> An example would be a modifier collection, where some modifier bits are
> dependent on others, while 0 (the default) is a valid value. One such
> dependency present in JDK itself is that ABSTRACT modifier must be set if
> INTERFACE modifier is, and at most one of PUBLIC, PRIVATE, or PROTECTED
> modifiers can be set. Such constraints can happen across the 32-bit boundary,
> and thus primitive long is not a suitable choice for its non-atomicity.

> How should I declare a value class that ensures atomicity of the null-restricted
> long value it contains? And how can a correct declaration consistently benefit
> from the 64-bit atomic operations offered on modern architectures?

By default, a null restricted value class does not allow tearing by default so wrapping a long should be enough (I hope). 

class LongWrapper { 
long value; 
implicit LongWrapper(); 
LongWrapper(long value) { this.value = value; } 
} 

class Foo { 
LongWrapper! w; // this is a non-tearing long 
} 

>From the spec POV, there is no garantee that an instance will not be a pointer instead of the direct value but given that Java only works on platforms (even 32 bits) that are able to write 64 bits atomically (otherwise you can not implement the VarHandle API), practically, it should be ok. 

> Truly curious,
> Chen Liang

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

From liangchenblue at gmail.com  Sat Oct 21 09:10:07 2023
From: liangchenblue at gmail.com (-)
Date: Sat, 21 Oct 2023 17:10:07 +0800
Subject: Ensuring atomicity of long values
In-Reply-To: <767063148.31055536.1697877982716.JavaMail.zimbra@univ-eiffel.fr>
References: <CABe8uE1Wg=ur47DwV=zu8FeA2hokdLu+RyfD8UjTnwJwFC5oxA@mail.gmail.com>
 <767063148.31055536.1697877982716.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CABe8uE0XaPdVPCu6d-Rj9CmR7aAW_-QCJ4k2D+d-jW7SHZaaew@mail.gmail.com>

Thank you for your quick response!

On Sat, Oct 21, 2023 at 4:46?PM Remi Forax <forax at univ-mlv.fr> wrote:

>
> By default, a null restricted value class does not allow tearing by
> default so wrapping a long should be enough (I hope).
>
News of relief.

On a side note, if a non-atomic class allows tearing, then Long and Double
wrappers cannot be migrated to be non-atomic (as you imply in your recent
"Not yet again!" against LooselyConsistentValue interface):
Compare a non-final long field and a non-final Long field. The long field
can be read with tearing, but Long, an object reference, cannot. Say we
write 1L<<32 and 1 to the field from 2 threads racily, then long read can
yield 0, 1, 1L<<32, 1L<<32 | 1, but Long read can only yield null, 1,
1L<<32 (as the final long field is published and visible when the Long
object is visible)

>
>   class LongWrapper {
>     long value;
>     implicit LongWrapper();
>     LongWrapper(long value) { this.value = value; }
>   }
>
> class Foo {
>   LongWrapper! w;  // this is a non-tearing long
> }
>
> From the spec POV, there is no garantee that an instance will not be a
> pointer instead of the direct value but given that Java only works on
> platforms (even 32 bits) that are able to write 64 bits atomically
> (otherwise you can not implement the VarHandle API), practically, it should
> be ok.
>
Agreed. Even if VarHandle and 64-bit atomic read/writes aren't used, JVM
can always fall back to traditional final field handling and heap object
layouts, which is still functionally correct.

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

From forax at univ-mlv.fr  Sat Oct 21 09:29:01 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 21 Oct 2023 11:29:01 +0200 (CEST)
Subject: Ensuring atomicity of long values
In-Reply-To: <CABe8uE0XaPdVPCu6d-Rj9CmR7aAW_-QCJ4k2D+d-jW7SHZaaew@mail.gmail.com>
References: <CABe8uE1Wg=ur47DwV=zu8FeA2hokdLu+RyfD8UjTnwJwFC5oxA@mail.gmail.com>
 <767063148.31055536.1697877982716.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE0XaPdVPCu6d-Rj9CmR7aAW_-QCJ4k2D+d-jW7SHZaaew@mail.gmail.com>
Message-ID: <2107566220.31067391.1697880541590.JavaMail.zimbra@univ-eiffel.fr>

> From: "-" <liangchenblue at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Saturday, October 21, 2023 11:10:07 AM
> Subject: Re: Ensuring atomicity of long values

> Thank you for your quick response!

> On Sat, Oct 21, 2023 at 4:46 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> By default, a null restricted value class does not allow tearing by default so
>> wrapping a long should be enough (I hope).

> News of relief.

:) 

> On a side note, if a non-atomic class allows tearing, then Long and Double
> wrappers cannot be migrated to be non-atomic (as you imply in your recent "Not
> yet again!" against LooselyConsistentValue interface):
> Compare a non-final long field and a non-final Long field. The long field can be
> read with tearing, but Long, an object reference, cannot. Say we write 1L<<32
> and 1 to the field from 2 threads racily, then long read can yield 0, 1,
> 1L<<32, 1L<<32 | 1, but Long read can only yield null, 1, 1L<<32 (as the final
> long field is published and visible when the Long object is visible)

Long will never tear, but Long! (note, there is a bang here) will tear. Long! and long have exactly the same semantics with respect to tearing. 
>From the spec POV, if you want flattenes on heap you need both a value class with an implicit constructor AND using ! at use site (where the field is declared). 
After, a specific VM can do heroics and discover that the actual CPU supports atomic 128 bits read/write using vector instructions and decide to store a Long (no bang) as a 128 bits values, 64 for the value and 1 for null or not. But this is a tradeoff, using more memory may backfire. 

>> class LongWrapper {
>> long value;
>> implicit LongWrapper();
>> LongWrapper(long value) { this.value = value; }
>> }

>> class Foo {
>> LongWrapper! w; // this is a non-tearing long
>> }

>> From the spec POV, there is no garantee that an instance will not be a pointer
>> instead of the direct value but given that Java only works on platforms (even
>> 32 bits) that are able to write 64 bits atomically (otherwise you can not
>> implement the VarHandle API), practically, it should be ok.

> Agreed. Even if VarHandle and 64-bit atomic read/writes aren't used, JVM can
> always fall back to traditional final field handling and heap object layouts,
> which is still functionally correct.

Yes. 
In Java, a developer does not control where his code run. So the semantics has to be the same for a wide range of hardware. 

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

From john.r.rose at oracle.com  Sat Oct 21 18:49:06 2023
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 21 Oct 2023 11:49:06 -0700
Subject: Ensuring atomicity of long values
In-Reply-To: <2107566220.31067391.1697880541590.JavaMail.zimbra@univ-eiffel.fr>
References: <CABe8uE1Wg=ur47DwV=zu8FeA2hokdLu+RyfD8UjTnwJwFC5oxA@mail.gmail.com>
 <767063148.31055536.1697877982716.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE0XaPdVPCu6d-Rj9CmR7aAW_-QCJ4k2D+d-jW7SHZaaew@mail.gmail.com>
 <2107566220.31067391.1697880541590.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <611CA70F-719F-4EC9-9920-78BE8DECE716@oracle.com>

On 21 Oct 2023, at 2:29, forax at univ-mlv.fr wrote:

> Long will never tear, but Long! (note, there is a bang here) will tear. Long! and long have exactly the same semantics with respect to tearing.
> From the spec POV, if you want flattenes on heap you need both a value class with an implicit constructor AND using ! at use site (where the field is declared).

Hmm, Long! also will never tear, until/unless the JDK author of Long
marks the class (somehow) as permitting non-atomic updates.  By default,
updates of both V and V! are free from races.  Only after opt-in
does V! (never V) begin to allow races.  I can?t say with certainty
what the JDK policy will be for making Long tearable, in the end.

It seems safer NOT to declare Long! tearable.  So Long! would be
a little safer than long on platforms which tear long.  But it
is also unclear whether having Long! differ from long this way
is a good thing or not.  So? I can?t say.  Maybe Brian or Dan
has worked out the whole equation for this particular question.

There is a spectrum or journey of opting in: first value class
(discarding identity), then allow zeroes by implicit constructor
(discarding 100% explicit construction), then non-atomicity
(discarding protection against construction by races).  Each
step is a tradeoff: Give something up, get something better.

> After, a specific VM can do heroics and discover that the actual CPU supports atomic 128 bits read/write using vector instructions and decide to store a Long (no bang) as a 128 bits values, 64 for the value and 1 for null or not. But this is a tradeoff, using more memory may backfire.

Ah yes, the 128-bit heroics.  Those will be best when the object payload
uses most or all of those 128 bits.  There are also possible 64.1-bit
heroics which steal the single bit from some condition on the object.
Those are in the realm of STM, and work best if the extra bit only
rarely needs setting.  That line of thought arises from the design
of lazy fields.  Then there are also possible 63-bit heroics involving
unions between immediate and pointer, as we had in the old days of Lisp.

There are old prototypes of 64-N-bit thingies on HotSpot (sort of
like NaN-tagged doubles, but which steal encodings from 64-bit long).
Like the NaN tags, they seem to promise interesting 64-N-bit heroics
for value types, and with a configurable N.

It will be fun to try all out these heroics, someday, on 65-bit types,
and see if they help any use-cases.

A ?heroic? which gets by in less than 64 bits seems paradoxical,
but sometimes is applicable if you really don?t expect the values
to inhabit the entire 2^64 bit range, and/or are willing to take
a performance hit on a few values, perhaps because they are rare.
That?s the essential tradeoff of Lisp and Smalltalk small ints.

If you think that is far fetched, ask yourself when there ever
was a Java application which created the full range of possible
java.lang.Long values.  None ever did, because it would require
a peta-scale heap, which Java can?t run on and may never.

To be clear, these are all just the possibilities; nobody is
working on them yet.  We?ve got plenty of more basic heroics
to carry out now, in the Valhalla project.  But the above
considerations suggest to me that our current set of heroics
are just the beginning.  Like it was in the beginning of Java,
when ?it is an interpretive language? and ?its GC is slower
than hand-managed malloc? were sometimes considered wise
reasons to stay with C.  That cost model was exploded by
HotSpot and other second-generation JVMs.

Maybe there will be a wise principle at first that ?Valhalla
values take up more heap space than primitives?.  That shouldn?t
be true if you declare them properly, but there might be cases
where you want to preserve safety or abstraction beyond what
primitives do, and pay for it (at first) with a little heap.
But given a good semantic foundation, such cost models can
go out of date, as the platform adds better and better
optimizations under the covers.  That?s what I hope for Valhalla.



From forax at univ-mlv.fr  Sun Oct 22 00:00:13 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 22 Oct 2023 02:00:13 +0200 (CEST)
Subject: Ensuring atomicity of long values
In-Reply-To: <611CA70F-719F-4EC9-9920-78BE8DECE716@oracle.com>
References: <CABe8uE1Wg=ur47DwV=zu8FeA2hokdLu+RyfD8UjTnwJwFC5oxA@mail.gmail.com>
 <767063148.31055536.1697877982716.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE0XaPdVPCu6d-Rj9CmR7aAW_-QCJ4k2D+d-jW7SHZaaew@mail.gmail.com>
 <2107566220.31067391.1697880541590.JavaMail.zimbra@univ-eiffel.fr>
 <611CA70F-719F-4EC9-9920-78BE8DECE716@oracle.com>
Message-ID: <567819878.31315520.1697932813094.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "-" <liangchenblue at gmail.com>, "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Saturday, October 21, 2023 8:49:06 PM
> Subject: Re: Ensuring atomicity of long values

> On 21 Oct 2023, at 2:29, forax at univ-mlv.fr wrote:
> 
>> Long will never tear, but Long! (note, there is a bang here) will tear. Long!
>> and long have exactly the same semantics with respect to tearing.
>> From the spec POV, if you want flattenes on heap you need both a value class
>> with an implicit constructor AND using ! at use site (where the field is
>> declared).
> 
> Hmm, Long! also will never tear, until/unless the JDK author of Long
> marks the class (somehow) as permitting non-atomic updates.  By default,
> updates of both V and V! are free from races.  Only after opt-in
> does V! (never V) begin to allow races.  I can?t say with certainty
> what the JDK policy will be for making Long tearable, in the end.
> 
> It seems safer NOT to declare Long! tearable.  So Long! would be
> a little safer than long on platforms which tear long.  But it
> is also unclear whether having Long! differ from long this way
> is a good thing or not.  So? I can?t say.  Maybe Brian or Dan
> has worked out the whole equation for this particular question.

That's a good question.
In practice on 64 bits platforms, there is no difference. I recall that the cost of forcing 64 bits writes was prohibitive on lego mindstorm NXT (a 32bits ARM), but it was 15 years ago.
I suppose we need more recent data :)

> 
> There is a spectrum or journey of opting in: first value class
> (discarding identity), then allow zeroes by implicit constructor
> (discarding 100% explicit construction), then non-atomicity
> (discarding protection against construction by races).  Each
> step is a tradeoff: Give something up, get something better.
> 
>> After, a specific VM can do heroics and discover that the actual CPU supports
>> atomic 128 bits read/write using vector instructions and decide to store a Long
>> (no bang) as a 128 bits values, 64 for the value and 1 for null or not. But
>> this is a tradeoff, using more memory may backfire.
> 
> Ah yes, the 128-bit heroics.  Those will be best when the object payload
> uses most or all of those 128 bits.  There are also possible 64.1-bit
> heroics which steal the single bit from some condition on the object.
> Those are in the realm of STM, and work best if the extra bit only
> rarely needs setting.  That line of thought arises from the design
> of lazy fields.  Then there are also possible 63-bit heroics involving
> unions between immediate and pointer, as we had in the old days of Lisp.
> 
> There are old prototypes of 64-N-bit thingies on HotSpot (sort of
> like NaN-tagged doubles, but which steal encodings from 64-bit long).
> Like the NaN tags, they seem to promise interesting 64-N-bit heroics
> for value types, and with a configurable N.
> 
> It will be fun to try all out these heroics, someday, on 65-bit types,
> and see if they help any use-cases.
> 
> A ?heroic? which gets by in less than 64 bits seems paradoxical,
> but sometimes is applicable if you really don?t expect the values
> to inhabit the entire 2^64 bit range, and/or are willing to take
> a performance hit on a few values, perhaps because they are rare.
> That?s the essential tradeoff of Lisp and Smalltalk small ints.
> 
> If you think that is far fetched, ask yourself when there ever
> was a Java application which created the full range of possible
> java.lang.Long values.  None ever did, because it would require
> a peta-scale heap, which Java can?t run on and may never.
> 
> To be clear, these are all just the possibilities; nobody is
> working on them yet.  We?ve got plenty of more basic heroics
> to carry out now, in the Valhalla project.  But the above
> considerations suggest to me that our current set of heroics
> are just the beginning.  Like it was in the beginning of Java,
> when ?it is an interpretive language? and ?its GC is slower
> than hand-managed malloc? were sometimes considered wise
> reasons to stay with C.  That cost model was exploded by
> HotSpot and other second-generation JVMs.
> 
> Maybe there will be a wise principle at first that ?Valhalla
> values take up more heap space than primitives?.  That shouldn?t
> be true if you declare them properly, but there might be cases
> where you want to preserve safety or abstraction beyond what
> primitives do, and pay for it (at first) with a little heap.
> But given a good semantic foundation, such cost models can
> go out of date, as the platform adds better and better
> optimizations under the covers.  That?s what I hope for Valhalla.

Dear Santa, I want deoptimizations of the layout instead of heroics. A way to mark that all instances of a class need to be evacuated and enlarged because a final nullable value type field actually is required to store null (or a special long value as you said). The marking + evacuation has to be done concurrently with the rest of the application like modern concurrent GCs do.

This same mechanism can be reused to speculatively avoid to store the identity hashCode of an instance of an identity class until the identity hashCode is actually requested.
Same thing with avoiding to store a reference to a lock (written in Java) in all objects until synchronized is called on an instance of a class.

regards,
R?mi


From vromero at openjdk.org  Thu Oct 26 15:31:56 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 26 Oct 2023 15:31:56 GMT
Subject: RFR: 8318903: [lw5] null-restricted storage API points
Message-ID: <_uv7au7DtSGHx81AXLsGo9K5I04CI-Ptv0VIY0gxJdw=.a9785da9-eb09-4309-aba1-fbf7b7fae167@github.com>

internal null-restricted storage API points

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

Commit messages:
 - 8318903: [lw5] null-restricted storage API points

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

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


From thartmann at openjdk.org  Tue Oct 31 18:18:13 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 31 Oct 2023 18:18:13 GMT
Subject: [lworld] RFR: 8315745: [lworld] "Meet Not Symmetric" failures
Message-ID: <JlKdpyZ8hRu0K8zhNcUL-XazjHvmsVNIsa8CgfvolTc=.c2d7bbf1-07bb-4c3e-a4b4-d31bd4509205@github.com>

The following two independent issues showed up with stress testing.


=== Meet Not Symmetric ===
t   =                   not flat:not null free:narrowoop: java/lang/Object:BotPTR *[int:0..max-2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *
this=                   flat:not flat:not null free:top[int:0..max-2] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+bot):null_free *,iid=top (inline_depth=1)
mt=(t meet this)=       not flat:not null free:narrowoop: java/lang/Object:BotPTR *[int:0..max-2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *
t_dual=                 stable:flat:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:exact:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop)
this_dual=              stable:bottom[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):NotNull * (inline_depth=-1)
mt_dual=                stable:flat:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:exact:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop)
mt_dual meet t_dual=    stable:flat:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:exact:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop)
mt_dual meet this_dual= stable:bottom[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):NotNull * (inline_depth=-1)


The problem is that `mt_dual meet this_dual != this_dual` with `mt_dual->_field_offset == TOP` and `this_dual->_field_offset == TOP` because the `_field_offset` of the result is `BOTTOM`. The fix is to adjust the code in `TypeAryPtr::xmeet_helper` to not set the field offset from `TOP` to `BOTTOM`.


=== Meet Not Symmetric ===
t   =                   stable:flat:not null free:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop) (speculative=stable:flat:not null free:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop))
this=                   stable:flat:not flat:not null free:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop) (speculative=stable:flat:not null free:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop))
mt=(t meet this)=       stable:flat:not null free:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop)
t_dual=                 not flat:narrowoop: java/lang/Object:BotPTR *[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull * (speculative=not flat:narrowoop: java/lang/Object:BotPTR *[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull *)
this_dual=              narrowoop: java/lang/Object:BotPTR *[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull * (speculative=not flat:narrowoop: java/lang/Object:BotPTR *[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull *)
mt_dual=                not flat:narrowoop: java/lang/Object:BotPTR *[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull *
mt_dual meet t_dual=    not flat:narrowoop: java/lang/Object:BotPTR *[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull *
mt_dual meet this_dual= narrowoop: java/lang/Object:BotPTR *[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull * (speculative=not flat:narrowoop: java/lang/Object:BotPTR *[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull *)


The problem is that `mt_dual meet t_dual != this_dual` because the speculative type is lost. The problem is already that for `t` the speculative type is equivalent to the non-speculative type. Since we keep the speculative part if it contains information about flat-/nullability (see [JDK-8222221](https://bugs.openjdk.org/browse/JDK-8222221)), we need to make sure it's removed if it's not better than the non-speculative type anymore and this check was missing in `TypeAryPtr::cast_to_not_flat`.

Best regards,
Tobias

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

Commit messages:
 - 8315745: [lworld] "Meet Not Symmetric" failures

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

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