From dsimms at openjdk.org  Wed Aug  2 08:57:27 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 2 Aug 2023 08:57:27 GMT
Subject: [lworld] Integrated: Adjust testing for 8313607 (InlineOops GenZ on
 aarch64)
Message-ID: <4l9S0gXwZH2msPySSQNg8jyNZt3GSD1SfMEuCu1Q7UQ=.d8f67785-438e-4fc7-9d52-289ce48f219e@github.com>

Problem list InlineOops on aarch64

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

Commit messages:
 - Adjust testing for 8313607

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

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


From dsimms at openjdk.org  Wed Aug  2 08:57:28 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 2 Aug 2023 08:57:28 GMT
Subject: [lworld] Integrated: Adjust testing for 8313607 (InlineOops GenZ on
 aarch64)
In-Reply-To: <4l9S0gXwZH2msPySSQNg8jyNZt3GSD1SfMEuCu1Q7UQ=.d8f67785-438e-4fc7-9d52-289ce48f219e@github.com>
References: <4l9S0gXwZH2msPySSQNg8jyNZt3GSD1SfMEuCu1Q7UQ=.d8f67785-438e-4fc7-9d52-289ce48f219e@github.com>
Message-ID: <_gOcNFE8C68mI3AMnqXRn3ejHYDN--_sEjF9GoSv2X4=.0cc77e88-31f8-40be-9083-9325b98b67f6@github.com>

On Wed, 2 Aug 2023 08:50:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Problem list InlineOops on aarch64

This pull request has now been integrated.

Changeset: 8bacdd4b
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8bacdd4b843c5220f54424c26add507eb729e704
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

Adjust testing for 8313607 (InlineOops GenZ on aarch64)

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

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


From dsimms at openjdk.org  Thu Aug  3 05:59:19 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 3 Aug 2023 05:59:19 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <iX8yUZdMjrXrMrPxsJDbcJ31OucuEIzjaylhiVYB37M=.4df257bf-de3a-42bb-be5b-6f57a040b3df@github.com>

Merge jdk-22+2

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

Commit messages:
 - Version flick
 - Merge tag 'jdk-22+2' into lworld_merge_jdk_22_2
 - 8309899: Rename PtrQueueSet::buffer_size()
 - 8309808: BytecodeTracer prints wrong BSM for invokedynamic
 - 8309958: Incorrect @since tag format in Container.java
 - 8309956: Shenandoah: Strengthen the mark word check in string dedup
 - 8309746: Reconfigure check should include make/conf/version-numbers.conf
 - 8308585: AC_REQUIRE: `PLATFORM_EXTRACT_TARGET_AND_BUILD' was expanded before it was required
 - 8309928: JFR: View issues
 - 8309959: JFR: Display N/A for missing data amount
 - ... and 79 more: https://git.openjdk.org/valhalla/compare/8bacdd4b...9b1526ca

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

Changes: https://git.openjdk.org/valhalla/pull/894/files
  Stats: 20109 lines in 584 files changed: 10467 ins; 7800 del; 1842 mod
  Patch: https://git.openjdk.org/valhalla/pull/894.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/894/head:pull/894

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


From dsimms at openjdk.org  Thu Aug  3 06:36:47 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 3 Aug 2023 06:36:47 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <iX8yUZdMjrXrMrPxsJDbcJ31OucuEIzjaylhiVYB37M=.4df257bf-de3a-42bb-be5b-6f57a040b3df@github.com>
References: <iX8yUZdMjrXrMrPxsJDbcJ31OucuEIzjaylhiVYB37M=.4df257bf-de3a-42bb-be5b-6f57a040b3df@github.com>
Message-ID: <Vz_n-hzJde1V79oZfVUFJrLoegO_ppBG_7ttS5VTP0M=.a57ae4f3-d61b-45a0-a430-f87184365c03@github.com>

> Merge jdk-22+2

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Another classfile version adjust

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/894/files
  - new: https://git.openjdk.org/valhalla/pull/894/files/9b1526ca..89171f7b

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

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

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


From dsimms at openjdk.org  Thu Aug  3 07:44:39 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 3 Aug 2023 07:44:39 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <iX8yUZdMjrXrMrPxsJDbcJ31OucuEIzjaylhiVYB37M=.4df257bf-de3a-42bb-be5b-6f57a040b3df@github.com>
References: <iX8yUZdMjrXrMrPxsJDbcJ31OucuEIzjaylhiVYB37M=.4df257bf-de3a-42bb-be5b-6f57a040b3df@github.com>
Message-ID: <ebc5Bhb4POTPPfTIRLhsP-c8mA6VcmjIC4kHLo5UG9g=.10b958bb-4680-4d54-bea0-ecb756ddaf8b@github.com>

On Thu, 3 Aug 2023 05:50:06 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+2

This pull request has now been integrated.

Changeset: a262109c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a262109c2cdf945dc003cdd0507575d2a83a1742
Stats:     20110 lines in 585 files changed: 10467 ins; 7800 del; 1843 mod

Merge jdk

Merge jdk-22+2

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

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


From dsimms at openjdk.org  Thu Aug  3 09:33:36 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 3 Aug 2023 09:33:36 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <VFdcm30juqxUSwfvQcRGyHOeeQLSd9rS4EhfTVjQF2M=.71500053-abfe-4f6c-b229-396ed3e8fb01@github.com>

Merge tag 'jdk-22+3' into lworld_merge_jdk_22_3
Added tag jdk-22+3 for changeset 3be50da6

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

Commit messages:
 - Merge tag 'jdk-22+3' into lworld_merge_jdk_22_3
 - 8310512: Cleanup indentation in jfc files
 - 8310575: no `@since` for StandardDoclet
 - 8310384: Add hooks for custom image creation
 - 8309883: no `@since` info in com.sun.tools.javac package-info.java, Main.java
 - 8310332: Fix -Wconversion warnings in MethodData
 - 8310379: Relax prerequisites for java.base-jmod target
 - 8310335: JFR: Modernize collections and switch statements
 - 8264899: C1: -XX:AbortVMOnException does not work if all methods in the call stack are compiled with C1 and there are no exception handlers
 - 8309296: jdk/jfr/event/runtime/TestAgentEvent.java fails due to "missing" dynamic JavaAgent
 - ... and 81 more: https://git.openjdk.org/valhalla/compare/a262109c...44685a73

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

Changes: https://git.openjdk.org/valhalla/pull/895/files
  Stats: 14336 lines in 611 files changed: 7917 ins; 3075 del; 3344 mod
  Patch: https://git.openjdk.org/valhalla/pull/895.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/895/head:pull/895

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


From dsimms at openjdk.org  Fri Aug  4 06:13:04 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Aug 2023 06:13:04 GMT
Subject: [lworld] RFR: 8313607: [lworld]
 runtime/valhalla/inlinetypes/InlineOops.java GenZ assertion on aarch64
Message-ID: <aFwwbSiAFLhzf8q0nkuYNj-ffNnTk0mIjnKT3ft0Pyg=.9a53c1de-981e-43f4-872e-bb7c04976ab8@github.com>

Use different temp reg not related to src.index()

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

Commit messages:
 - Use different temp reg not related to src.index()

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

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


From dsimms at openjdk.org  Fri Aug  4 06:13:04 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Aug 2023 06:13:04 GMT
Subject: [lworld] RFR: 8313607: [lworld]
 runtime/valhalla/inlinetypes/InlineOops.java GenZ assertion on aarch64
In-Reply-To: <aFwwbSiAFLhzf8q0nkuYNj-ffNnTk0mIjnKT3ft0Pyg=.9a53c1de-981e-43f4-872e-bb7c04976ab8@github.com>
References: <aFwwbSiAFLhzf8q0nkuYNj-ffNnTk0mIjnKT3ft0Pyg=.9a53c1de-981e-43f4-872e-bb7c04976ab8@github.com>
Message-ID: <hqF8-KorWVSkwtJLwAN4ZTf7pn2faO9D3UslQhnNFhA=.da84b049-d859-4a2a-ac26-c63627fd85d5@github.com>

On Fri, 4 Aug 2023 06:06:31 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use different temp reg not related to src.index()

Trivial

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

PR Comment: https://git.openjdk.org/valhalla/pull/896#issuecomment-1665062360


From dsimms at openjdk.org  Fri Aug  4 06:32:59 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Aug 2023 06:32:59 GMT
Subject: [lworld] Integrated: 8313607: [lworld]
 runtime/valhalla/inlinetypes/InlineOops.java GenZ assertion on aarch64
In-Reply-To: <aFwwbSiAFLhzf8q0nkuYNj-ffNnTk0mIjnKT3ft0Pyg=.9a53c1de-981e-43f4-872e-bb7c04976ab8@github.com>
References: <aFwwbSiAFLhzf8q0nkuYNj-ffNnTk0mIjnKT3ft0Pyg=.9a53c1de-981e-43f4-872e-bb7c04976ab8@github.com>
Message-ID: <amHSUweoyYiTqscowOp5DA7XdAL-7FcIi7V7Mlj0aSM=.8667dd4d-d6c3-43b9-95fd-5afa2be8e4a0@github.com>

On Fri, 4 Aug 2023 06:06:31 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use different temp reg not related to src.index()

This pull request has now been integrated.

Changeset: 8af773c0
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8af773c0f2f36fb1a4455530c0022a24bb89b2bc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8313607: [lworld] runtime/valhalla/inlinetypes/InlineOops.java GenZ assertion on aarch64

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

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


From dsimms at openjdk.org  Fri Aug  4 06:34:24 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Aug 2023 06:34:24 GMT
Subject: [lworld] Integrated: Adjust testing for ZGenerational compiler
 failures
Message-ID: <gP6X1rIGh9kNYIudJgXNq5gtKnKgVpTeOP__fkfw85o=.7cf7453d-72d6-4bca-8b25-d3683fcdd241@github.com>

* compiler/gcbarriers/TestZGCBarrierElision.java 8313737 generic-all
* compiler/valhalla/inlinetypes/TestArrays.java 8313667 generic-all

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

Commit messages:
 - Adjust testing for ZGenerational compiler failures

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

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


From dsimms at openjdk.org  Fri Aug  4 06:34:24 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Aug 2023 06:34:24 GMT
Subject: [lworld] Integrated: Adjust testing for ZGenerational compiler
 failures
In-Reply-To: <gP6X1rIGh9kNYIudJgXNq5gtKnKgVpTeOP__fkfw85o=.7cf7453d-72d6-4bca-8b25-d3683fcdd241@github.com>
References: <gP6X1rIGh9kNYIudJgXNq5gtKnKgVpTeOP__fkfw85o=.7cf7453d-72d6-4bca-8b25-d3683fcdd241@github.com>
Message-ID: <KGisOX8FIIElsserh15NA1wcLhja1mPpqrRmSSrEUG4=.289195e4-adcf-4666-8a34-6365b44f2b46@github.com>

On Fri, 4 Aug 2023 06:24:41 GMT, David Simms <dsimms at openjdk.org> wrote:

> * compiler/gcbarriers/TestZGCBarrierElision.java 8313737 generic-all
> * compiler/valhalla/inlinetypes/TestArrays.java 8313667 generic-all

This pull request has now been integrated.

Changeset: b3592589
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b35925899c99b73a90c935da74482661e0aecc58
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

Adjust testing for ZGenerational compiler failures

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

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


From dsimms at openjdk.org  Fri Aug  4 07:59:11 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Aug 2023 07:59:11 GMT
Subject: [lworld] Integrated: Adjust testing, refine ProblemList with test ids
Message-ID: <MaaSmczpYzIxIbwW5omPLCMytcFjNGD179jyF--k4n0=.81aa36b2-ccdc-4eab-86f7-66963f22c529@github.com>

Added "@test id=" to further refine problem listed failures

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

Commit messages:
 - Adjust testing, refine ProblemList with test ids

Changes: https://git.openjdk.org/valhalla/pull/898/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=898&range=00
  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/898.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/898/head:pull/898

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


From dsimms at openjdk.org  Fri Aug  4 07:59:11 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Aug 2023 07:59:11 GMT
Subject: [lworld] Integrated: Adjust testing, refine ProblemList with test ids
In-Reply-To: <MaaSmczpYzIxIbwW5omPLCMytcFjNGD179jyF--k4n0=.81aa36b2-ccdc-4eab-86f7-66963f22c529@github.com>
References: <MaaSmczpYzIxIbwW5omPLCMytcFjNGD179jyF--k4n0=.81aa36b2-ccdc-4eab-86f7-66963f22c529@github.com>
Message-ID: <wx-ZOxt6e_PRN-Dib1DALYtcElMS5DgtbsJREMoABsw=.961ca289-b89c-4d0a-a56d-466e098fc424@github.com>

On Fri, 4 Aug 2023 07:50:28 GMT, David Simms <dsimms at openjdk.org> wrote:

> Added "@test id=" to further refine problem listed failures

This pull request has now been integrated.

Changeset: ce916e16
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ce916e16248be54f8d604bae6248ed51aaef12ad
Stats:     10 lines in 3 files changed: 0 ins; 0 del; 10 mod

Adjust testing, refine ProblemList with test ids

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

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


From dsimms at openjdk.org  Fri Aug  4 11:02:01 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 4 Aug 2023 11:02:01 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <VFdcm30juqxUSwfvQcRGyHOeeQLSd9rS4EhfTVjQF2M=.71500053-abfe-4f6c-b229-396ed3e8fb01@github.com>
References: <VFdcm30juqxUSwfvQcRGyHOeeQLSd9rS4EhfTVjQF2M=.71500053-abfe-4f6c-b229-396ed3e8fb01@github.com>
Message-ID: <N1LV-WPFMXOOhVtHw8WFz14uOOQhkKJhRfm8MbfIc_o=.9a53eb9e-6297-46ae-a46a-24df7930d4da@github.com>

On Thu, 3 Aug 2023 09:23:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-22+3' into lworld_merge_jdk_22_3
> Added tag jdk-22+3 for changeset 3be50da6

This pull request has now been integrated.

Changeset: 054524e3
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/054524e323138d0b4d2dfaed0cca8e1b77f6bce4
Stats:     14336 lines in 611 files changed: 7917 ins; 3075 del; 3344 mod

Merge jdk

Merge jdk-22+3

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

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


From vromero at openjdk.org  Fri Aug  4 17:24:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Aug 2023 17:24:06 GMT
Subject: RFR: [lw5] experiment: reusing primitive class tests to generate Q
 descriptors
Message-ID: <KGummdllQDb62oOmITjTYr2y6RosLVhyLSyEQ1F_e2w=.82b38301-2ae5-4b9d-a765-6b94615d8fdd@github.com>

this change add more tests to the experimental code that generates Q descriptors with lw5 syntax

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

Commit messages:
 - reusing more primitive classes tests

Changes: https://git.openjdk.org/valhalla/pull/899/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=899&range=00
  Stats: 997 lines in 44 files changed: 58 ins; 759 del; 180 mod
  Patch: https://git.openjdk.org/valhalla/pull/899.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/899/head:pull/899

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


From vromero at openjdk.org  Fri Aug  4 17:41:57 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Aug 2023 17:41:57 GMT
Subject: Integrated: [lw5] experiment: reusing primitive class tests to
 generate Q descriptors
In-Reply-To: <KGummdllQDb62oOmITjTYr2y6RosLVhyLSyEQ1F_e2w=.82b38301-2ae5-4b9d-a765-6b94615d8fdd@github.com>
References: <KGummdllQDb62oOmITjTYr2y6RosLVhyLSyEQ1F_e2w=.82b38301-2ae5-4b9d-a765-6b94615d8fdd@github.com>
Message-ID: <JWF1m2RB2kJyPVzWgmZIVEeY-TJdvvf4ClkorAbeqRo=.bbaa1594-d066-4101-8fea-ef511708a6cf@github.com>

On Fri, 4 Aug 2023 17:16:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this change add more tests to the experimental code that generates Q descriptors with lw5 syntax

This pull request has now been integrated.

Changeset: 300a88e1
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/300a88e1a5d7576e1f587141a9285c93cf3a72d8
Stats:     997 lines in 44 files changed: 58 ins; 759 del; 180 mod

[lw5] experiment: reusing primitive class tests to generate Q descriptors

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

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


From vromero at openjdk.org  Mon Aug  7 22:01:04 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Aug 2023 22:01:04 GMT
Subject: RFR: [lw5] fixing bugs on experimental code to generate Q-descriptors, 
 plus code refactoring
Message-ID: <E8Gc3mgBgp8sVE-SD6dKUJnEwYCXwCu1hglYO-Z2VEk=.6d629ffe-f7a6-4e6f-811d-721f089febbf@github.com>

This fix is fixing some bugs introduced by the experimental code to generate Q-descriptors. Some changes are also reusing some of the experimental code for the benefit of LW5.

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

Commit messages:
 - [lw5] fixing bugs introduced by experimental code

Changes: https://git.openjdk.org/valhalla/pull/900/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=900&range=00
  Stats: 39 lines in 8 files changed: 14 ins; 3 del; 22 mod
  Patch: https://git.openjdk.org/valhalla/pull/900.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/900/head:pull/900

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


From vromero at openjdk.org  Mon Aug  7 22:51:55 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Aug 2023 22:51:55 GMT
Subject: Integrated: [lw5] fixing bugs on experimental code to generate
 Q-descriptors, plus code refactoring
In-Reply-To: <E8Gc3mgBgp8sVE-SD6dKUJnEwYCXwCu1hglYO-Z2VEk=.6d629ffe-f7a6-4e6f-811d-721f089febbf@github.com>
References: <E8Gc3mgBgp8sVE-SD6dKUJnEwYCXwCu1hglYO-Z2VEk=.6d629ffe-f7a6-4e6f-811d-721f089febbf@github.com>
Message-ID: <a-wxZQdrQeTivo0ozU7H8UpDl2ES_M2Qs7QwT_liwHk=.61c45855-3f74-4753-8cb9-5f9e42bbcaf5@github.com>

On Mon, 7 Aug 2023 21:54:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This fix is fixing some bugs introduced by the experimental code to generate Q-descriptors. Some changes are also reusing some of the experimental code for the benefit of LW5.

This pull request has now been integrated.

Changeset: 0390afd9
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0390afd950ba796af97bcf81756aba5b349b3580
Stats:     39 lines in 8 files changed: 14 ins; 3 del; 22 mod

[lw5] fixing bugs on experimental code to generate Q-descriptors, plus code refactoring

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

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


From vromero at openjdk.org  Wed Aug  9 16:52:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Aug 2023 16:52:35 GMT
Subject: Integrated: [lw5] regression test cleanup, relocation
In-Reply-To: <0UkSx2oulOFYaZB6T7JrLKmv4ONOxUCSunYE27s79eY=.f39f6e3e-d2b9-47f2-b5c6-40c12535725c@github.com>
References: <0UkSx2oulOFYaZB6T7JrLKmv4ONOxUCSunYE27s79eY=.f39f6e3e-d2b9-47f2-b5c6-40c12535725c@github.com>
Message-ID: <cInmbhwiZfA8mRn-eaum5-IyDAYf5VnrvwbqLYPXOqc=.2cc520de-62c3-460c-ab1e-64d4ab3e417f@github.com>

On Wed, 9 Aug 2023 16:25:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> cleaning up nullability related test, plus renaming them

This pull request has now been integrated.

Changeset: 05f62bbd
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/05f62bbd302407de1189c3d2893180690237eed6
Stats:     452 lines in 4 files changed: 197 ins; 251 del; 4 mod

[lw5] regression test cleanup, relocation

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

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


From vromero at openjdk.org  Wed Aug  9 16:52:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Aug 2023 16:52:32 GMT
Subject: Integrated: [lw5] regression test cleanup, relocation
Message-ID: <0UkSx2oulOFYaZB6T7JrLKmv4ONOxUCSunYE27s79eY=.f39f6e3e-d2b9-47f2-b5c6-40c12535725c@github.com>

cleaning up nullability related test, plus renaming them

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

Commit messages:
 - regression test refactoring, cleanup

Changes: https://git.openjdk.org/valhalla/pull/901/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=901&range=00
  Stats: 452 lines in 4 files changed: 197 ins; 251 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/901.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/901/head:pull/901

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


From vromero at openjdk.org  Wed Aug  9 18:53:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Aug 2023 18:53:29 GMT
Subject: Integrated: Merge lworld
Message-ID: <nYpY6WO2UrUszl_chrAOTCrGgjDAfq8pz21fio5Ff0U=.d57c9e13-22a8-4644-a8c4-45a535248066@github.com>

Merge branch 'lworld' into lw5

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

Commit messages:
 - Merge branch 'lworld' into merge.with.lworld
 - Merge jdk
 - 8310512: Cleanup indentation in jfc files
 - 8310575: no `@since` for StandardDoclet
 - 8310384: Add hooks for custom image creation
 - 8309883: no `@since` info in com.sun.tools.javac package-info.java, Main.java
 - 8310332: Fix -Wconversion warnings in MethodData
 - 8310379: Relax prerequisites for java.base-jmod target
 - 8310335: JFR: Modernize collections and switch statements
 - 8264899: C1: -XX:AbortVMOnException does not work if all methods in the call stack are compiled with C1 and there are no exception handlers
 - ... and 174 more: https://git.openjdk.org/valhalla/compare/05f62bbd...200b3e79

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

Changes: https://git.openjdk.org/valhalla/pull/902/files
  Stats: 34428 lines in 1156 files changed: 18379 ins; 10866 del; 5183 mod
  Patch: https://git.openjdk.org/valhalla/pull/902.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/902/head:pull/902

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


From vromero at openjdk.org  Wed Aug  9 18:54:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 9 Aug 2023 18:54:29 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <nYpY6WO2UrUszl_chrAOTCrGgjDAfq8pz21fio5Ff0U=.d57c9e13-22a8-4644-a8c4-45a535248066@github.com>
References: <nYpY6WO2UrUszl_chrAOTCrGgjDAfq8pz21fio5Ff0U=.d57c9e13-22a8-4644-a8c4-45a535248066@github.com>
Message-ID: <7d2dn9FzUFyQj2de66xw3ZaR4mlMlOD9Wva0RRhbCJs=.5e773e2f-69b9-4cbd-8f87-66e26b8f374b@github.com>

On Wed, 9 Aug 2023 18:33:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5

This pull request has now been integrated.

Changeset: 3fdef5ef
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3fdef5ef74c702e951f2b00f3700a01a2010bcc5
Stats:     34428 lines in 1156 files changed: 18379 ins; 10866 del; 5183 mod

Merge lworld

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

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


From xgong at openjdk.org  Thu Aug 10 03:45:31 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 10 Aug 2023 03:45:31 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
Message-ID: <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>

On Tue, 25 Jul 2023 09:56:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

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

Hi, could anyone please take a look at this PR? Thanks a lot in advance!

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1672499252


From jbhateja at openjdk.org  Thu Aug 10 11:56:33 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 10 Aug 2023 11:56:33 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
Message-ID: <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>

On Thu, 10 Aug 2023 03:30:50 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Hi, could anyone please take a look at this PR? Thanks a lot in advance!

This should also be looked in light of atomicity constraint during updates which does not apply to Q descriptor value field.  But aggressive flattening can adversely affect caching behavior.  Just going slightly off the topic, in context of Vector APIs (lworld+vector) all the payloads are final primitive class fields and will always be flattened in their respective boxes.  

Best Regards.

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1673069371


From vromero at openjdk.org  Fri Aug 11 22:31:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Aug 2023 22:31:29 GMT
Subject: RFR: 8314165: [lw5] check for illegal circularity at class loading
 time
Message-ID: <0EY034vjfqa7tQbdwZjlcJd5h71ujgLflALF5UyxGpg=.997376ba-ffcd-42a2-a12e-0232db912a6c@github.com>

This PR is implementing this assertion of JEP 401:


At class load time, an error occurs if an ACC_DEFAULT class has an illegal circularity in its instance field types


which is in section: `class file representation & interpretation`

So for example if a Java compiler were able to create a class file for class:

value class Test {
    Test! test; // illegal circularity
    public implicit Test();
}

then javac should issue an error while loading such a class

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

Commit messages:
 - 8314165: [lw5] check for illegal circularity at class loading time

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

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


From vromero at openjdk.org  Fri Aug 11 22:50:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Aug 2023 22:50:28 GMT
Subject: RFR: 8314165: [lw5] check for illegal circularity at class loading
 time [v2]
In-Reply-To: <0EY034vjfqa7tQbdwZjlcJd5h71ujgLflALF5UyxGpg=.997376ba-ffcd-42a2-a12e-0232db912a6c@github.com>
References: <0EY034vjfqa7tQbdwZjlcJd5h71ujgLflALF5UyxGpg=.997376ba-ffcd-42a2-a12e-0232db912a6c@github.com>
Message-ID: <rtsQb8LCla44-sNC7l4BsN_j0HwD9E3IqGPnVyS1ro4=.7c84cae3-f4fa-406b-b3b6-931e05e69e5c@github.com>

> This PR is implementing this assertion of JEP 401:
> 
> 
> At class load time, an error occurs if an ACC_DEFAULT class has an illegal circularity in its instance field types
> 
> 
> which is in section: `class file representation & interpretation`
> 
> So for example if a Java compiler were able to create a class file for class:
> 
> value class Test {
>     Test! test; // illegal circularity
>     public implicit Test();
> }
> 
> then javac should issue an error while loading such a class

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

  more fine tunning

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/903/files
  - new: https://git.openjdk.org/valhalla/pull/903/files/c957eb63..a36a42ec

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

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

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


From vromero at openjdk.org  Fri Aug 11 22:54:58 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Aug 2023 22:54:58 GMT
Subject: Integrated: 8314165: [lw5] check for illegal circularity at class
 loading time
In-Reply-To: <0EY034vjfqa7tQbdwZjlcJd5h71ujgLflALF5UyxGpg=.997376ba-ffcd-42a2-a12e-0232db912a6c@github.com>
References: <0EY034vjfqa7tQbdwZjlcJd5h71ujgLflALF5UyxGpg=.997376ba-ffcd-42a2-a12e-0232db912a6c@github.com>
Message-ID: <1frpm_xdK_gNsTRJUnq7xSrYgWCXBZjEpkCPNprgVf8=.41772fb1-596d-4d4a-b68b-8a3f042771a9@github.com>

On Fri, 11 Aug 2023 22:07:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This PR is implementing this assertion of JEP 401:
> 
> 
> At class load time, an error occurs if an ACC_DEFAULT class has an illegal circularity in its instance field types
> 
> 
> which is in section: `class file representation & interpretation`
> 
> So for example if a Java compiler were able to create a class file for class:
> 
> value class Test {
>     Test! test; // illegal circularity
>     public implicit Test();
> }
> 
> then javac should issue an error while loading such a class

This pull request has now been integrated.

Changeset: ad095102
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ad0951021553c5df042c4ffdea710fb8c9f82643
Stats:     157 lines in 6 files changed: 150 ins; 0 del; 7 mod

8314165: [lw5] check for illegal circularity at class loading time

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

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


From vromero at openjdk.org  Sat Aug 12 01:51:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 12 Aug 2023 01:51:28 GMT
Subject: Integrated: 8314181: [lw5] the check for illegal circularity should
 only be done if value classes are available
Message-ID: <g-x59lskFTg2l3eoE_ilKKgARpV6y3TWA7ecr3fk7ys=.8084dd95-fd7f-45de-af8a-7625b4823df2@github.com>

fixing minor missing check from the fix for JDK-8314165

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

Commit messages:
 - 8314181: [lw5] the check for illegal circularity should only be done if value classes are available

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

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


From vromero at openjdk.org  Sat Aug 12 01:52:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 12 Aug 2023 01:52:28 GMT
Subject: Integrated: 8314181: [lw5] the check for illegal circularity should
 only be done if value classes are available
In-Reply-To: <g-x59lskFTg2l3eoE_ilKKgARpV6y3TWA7ecr3fk7ys=.8084dd95-fd7f-45de-af8a-7625b4823df2@github.com>
References: <g-x59lskFTg2l3eoE_ilKKgARpV6y3TWA7ecr3fk7ys=.8084dd95-fd7f-45de-af8a-7625b4823df2@github.com>
Message-ID: <3xbnkfbUVrF5eAC5NeE4MpAilqVbewZdUqSe9FBhKU8=.7769b3e8-2738-45ae-bbf9-250a38861d14@github.com>

On Sat, 12 Aug 2023 01:27:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing minor missing check from the fix for JDK-8314165

This pull request has now been integrated.

Changeset: 0f340086
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0f340086014338993a45ec166c88a3a3a09404dd
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8314181: [lw5] the check for illegal circularity should only be done if value classes are available

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

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


From dsimms at openjdk.org  Mon Aug 14 13:22:29 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Aug 2023 13:22:29 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <NrL6n7jUdRBWjUfrZFgphi64tpimolwVU1WSjgPU8Lk=.70e50819-185f-464a-b3bb-d0157554372b@github.com>

Merge jdk-22+4 and jdk-22+5

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

Commit messages:
 - Logical merge fixes for compilation
 - Merge tag 'jdk-22+5' into lworld_merge_jdk_22_4
 - 8307526: [JFR] Better handling of tampered JFR repository
 - 8311035: CDS should not use dump time JVM narrow Klass encoding to pre-compute Klass ids
 - 8310999: Add @since info in jdk.jsobject files
 - 8311023: assert(false) failed: EA: missing memory path
 - 8311290: Improve java.lang.ref.Cleaner rendered documentation
 - 8311180: Remove unused unneeded definitions from globalDefinitions
 - 8311077: Fix -Wconversion warnings in jvmti code
 - 8310645: CancelledResponse.java does not use HTTP/2 when testing the  HttpClient
 - ... and 159 more: https://git.openjdk.org/valhalla/compare/054524e3...51fb8cc7

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

Changes: https://git.openjdk.org/valhalla/pull/905/files
  Stats: 17832 lines in 854 files changed: 8653 ins; 4428 del; 4751 mod
  Patch: https://git.openjdk.org/valhalla/pull/905.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/905/head:pull/905

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


From dsimms at openjdk.org  Mon Aug 14 13:43:29 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Aug 2023 13:43:29 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <NrL6n7jUdRBWjUfrZFgphi64tpimolwVU1WSjgPU8Lk=.70e50819-185f-464a-b3bb-d0157554372b@github.com>
References: <NrL6n7jUdRBWjUfrZFgphi64tpimolwVU1WSjgPU8Lk=.70e50819-185f-464a-b3bb-d0157554372b@github.com>
Message-ID: <ObepN0I6qXzXRkOs4NK4-8CCa2TRVXKzASu2qcOPUvA=.00d59ba3-8116-42a9-a41d-a42169d655f3@github.com>

On Mon, 14 Aug 2023 12:28:47 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+4 and jdk-22+5

This pull request has now been integrated.

Changeset: 064cd392
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/064cd392384821f6332ce5b8e9bc84153b59117a
Stats:     17832 lines in 854 files changed: 8653 ins; 4428 del; 4751 mod

Merge jdk

Merge jdk-22+4 and jdk-22+5

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

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


From dsimms at openjdk.org  Tue Aug 15 10:13:16 2023
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Aug 2023 10:13:16 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <71eHwxkjvWVh0IqDJkdtZrXqsa58IUNfFoqX1p3AaWw=.a34ec17f-3810-42cf-9f8a-ff7cf7051119@github.com>

Merge jdk-22+6

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

Commit messages:
 - Logical merge issue, compilation
 - Merge tag 'jdk-22+6' into lworld_merge_jdk_22_6
 - 8311805: Clean up ScrollPane: drop redundant initialiser, mark scroller final
 - 8310066: Improve test coverage for JVMTI GetThreadState on carrier and mounted vthread
 - 6960866: [Fmt-Ch] ChoiceFormat claims impossible and unimplemented functionality
 - 8311645: Memory leak in jspawnhelper spawnChild after JDK-8307990
 - 8311606: Change read_icc_profile() to static function in java.desktop/share/native/libjavajpeg/imageioJPEG.c
 - 8311178: JMH tests don't scale well when sharing output buffers
 - 8310047: Add UTF-32 based Charsets into StandardCharsets
 - 8303279: C2: crash in SubTypeCheckNode::sub() at IGVN split if
 - ... and 33 more: https://git.openjdk.org/valhalla/compare/064cd392...10695b7f

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

Changes: https://git.openjdk.org/valhalla/pull/906/files
  Stats: 45180 lines in 167 files changed: 2997 ins; 41549 del; 634 mod
  Patch: https://git.openjdk.org/valhalla/pull/906.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/906/head:pull/906

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


From jbhateja at openjdk.org  Tue Aug 15 11:10:10 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 15 Aug 2023 11:10:10 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening.
Message-ID: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>

-  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
 - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.

Kindly review.

Tier1 regressions are clean.

Best Regards,
Jatin Bhateja

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

Commit messages:
 - 8314190: [lworld] Missing InlineTypeNode re-materialization during type sharpening.

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

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


From dsimms at openjdk.org  Tue Aug 15 14:47:44 2023
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Aug 2023 14:47:44 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <71eHwxkjvWVh0IqDJkdtZrXqsa58IUNfFoqX1p3AaWw=.a34ec17f-3810-42cf-9f8a-ff7cf7051119@github.com>
References: <71eHwxkjvWVh0IqDJkdtZrXqsa58IUNfFoqX1p3AaWw=.a34ec17f-3810-42cf-9f8a-ff7cf7051119@github.com>
Message-ID: <m7J1RG5rkZ3eGWF1xk5Frh-gkOlDaUaPS0ByQUUlWCA=.5b6a9666-53ba-44b9-bae7-134d3d4253bf@github.com>

On Tue, 15 Aug 2023 10:04:48 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+6

This pull request has now been integrated.

Changeset: cf95308c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cf95308c529a0fe4a3f4cb9ddda38335ce37cf4b
Stats:     45180 lines in 167 files changed: 2997 ins; 41549 del; 634 mod

Merge jdk

Merge jdk-22+6

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

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


From jbhateja at openjdk.org  Wed Aug 16 06:29:13 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Aug 2023 06:29:13 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16
 scalar operations. [v2]
In-Reply-To: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
References: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
Message-ID: <aCpGCgX7kBaPrzwpHPPOqubwYAwhmEYWRelHRDuNoAg=.2f734eea-14b4-4354-a0ff-455f92e685ab@github.com>

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

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

  Cleanup Float16 class definition.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/848/files
  - new: https://git.openjdk.org/valhalla/pull/848/files/98d8ea1f..3629c434

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

  Stats: 1076 lines in 1 file changed: 7 ins; 1059 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/848.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/848/head:pull/848

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


From jbhateja at openjdk.org  Wed Aug 16 06:51:34 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Aug 2023 06:51:34 GMT
Subject: [lworld+fp16] Integrated: Merge lworld
Message-ID: <HLc9fO_EMOibR79V5cb7G_KtYIUOwdKSJdMSjzJ0NdM=.102f48ec-0c29-48c2-88cf-6b44da56844d@github.com>

Merge lworld into lworld+fp16

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

Commit messages:


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

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

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


From jbhateja at openjdk.org  Wed Aug 16 06:51:40 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Aug 2023 06:51:40 GMT
Subject: [lworld+fp16] Integrated: Merge lworld
In-Reply-To: <HLc9fO_EMOibR79V5cb7G_KtYIUOwdKSJdMSjzJ0NdM=.102f48ec-0c29-48c2-88cf-6b44da56844d@github.com>
References: <HLc9fO_EMOibR79V5cb7G_KtYIUOwdKSJdMSjzJ0NdM=.102f48ec-0c29-48c2-88cf-6b44da56844d@github.com>
Message-ID: <M1dS22cPSzMacUj8loTfY_NWkF0YLM9TmLoMaOcKDKI=.bb1247c8-e369-41aa-8d31-85f446dd1f4f@github.com>

On Wed, 16 Aug 2023 06:42:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge lworld into lworld+fp16

This pull request has now been integrated.

Changeset: 4dca15bf
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4dca15bf6edc357c3611b7501d0698de09af6fc4
Stats:     1143613 lines in 11956 files changed: 758837 ins; 270461 del; 114315 mod

Merge lworld

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

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


From jbhateja at openjdk.org  Wed Aug 16 07:25:01 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Aug 2023 07:25:01 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16
 scalar operations. [v3]
In-Reply-To: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
References: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
Message-ID: <MphCOFGZ27J44lT6-mnVWYVHt_o7sj0EJ3PYJis3cxc=.3f6d9124-18d7-449d-adf7-ba7cd06f2ec1@github.com>

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

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 three additional commits since the last revision:

 - Merge branch 'lworld+fp16' of http://github.com/openjdk/valhalla into JDK-8308363
 - Cleanup Float16 class definition.
 - 8308363: Initial compiler support for FP16 scalar operations.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/848/files
  - new: https://git.openjdk.org/valhalla/pull/848/files/3629c434..5cd42f3b

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

  Stats: 1143617 lines in 11956 files changed: 758838 ins; 270462 del; 114317 mod
  Patch: https://git.openjdk.org/valhalla/pull/848.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/848/head:pull/848

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


From thartmann at openjdk.org  Wed Aug 16 13:40:34 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 16 Aug 2023 13:40:34 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening.
In-Reply-To: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
Message-ID: <zNNAKIj_Faw5EhKYmTSjKeprfp7AvPQDrJLeYMYFsIQ=.330ebca2-7345-414a-92a0-5661d08faf22@github.com>

On Tue, 15 Aug 2023 11:02:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> -  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
>  - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.
> 
> Kindly review.
> 
> Tier1 regressions are clean.
> 
> Best Regards,
> Jatin Bhateja

Thanks for fixing this, Jatin. Could you add a corresponding IR framework test?

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

PR Comment: https://git.openjdk.org/valhalla/pull/907#issuecomment-1680623096


From thartmann at openjdk.org  Wed Aug 16 14:35:29 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 16 Aug 2023 14:35:29 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening.
In-Reply-To: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
Message-ID: <yiKZcsS_-97vmWOlmZ_W7B20QNF1K5sjmKcj49wjNZg=.0848c423-49e0-4616-bc18-61929e1e5ed0@github.com>

On Tue, 15 Aug 2023 11:02:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> -  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
>  - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.
> 
> Kindly review.
> 
> Tier1 regressions are clean.
> 
> Best Regards,
> Jatin Bhateja

src/hotspot/share/opto/parse2.cpp line 2441:

> 2439:             record_for_igvn(ccast);
> 2440:             if (tboth->is_inlinetypeptr()) {
> 2441:               assert(tboth->exact_klass(true)->is_inlinetype(), "");

I don't think that assert is needed since `as_inline_klass` would already assert. And couldn't you use `tboth->inline_klass()`?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/907#discussion_r1296010680


From xgong at openjdk.org  Thu Aug 17 01:53:46 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 17 Aug 2023 01:53:46 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
 <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
Message-ID: <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>

On Thu, 10 Aug 2023 11:47:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Just going slightly off the topic, in context of Vector APIs (lworld+vector) all the payloads are final primitive class fields and will always be flattened in their respective boxes.

Sorry for my late reply!  And yes, the payloads in Vector APIs are always be flattened for current vector size. What my concern is the larger vector size like in Arm SVE after we support the SPECIES_MAX vectors, and the expected behavior/difference if people set a smaller max flat size with `InlineFieldMaxFlatSize`.

Thanks,
Xiaohong

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1681491120


From jbhateja at openjdk.org  Thu Aug 17 05:18:47 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Aug 2023 05:18:47 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
 <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
 <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>
Message-ID: <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>

On Thu, 17 Aug 2023 01:51:08 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Just going slightly off the topic, in context of Vector APIs (lworld+vector) all the payloads are final primitive class fields and will always be flattened in their respective boxes.
> 
> Sorry for my late reply! And yes, the payloads in Vector APIs are always be flattened for current vector size. What my concern is the larger vector size like in Arm SVE after we support the SPECIES_MAX vectors, and the expected behavior/difference if people set a smaller max flat size with `InlineFieldMaxFlatSize`.
> 
> Thanks, Xiaohong

That's correct!, my above comment was in context of existing handling where final fields of [null-restricted value types](https://openjdk.org/jeps/401) are always flattened irrespective of InlineFieldMaxFlatSize.  Are you inclined to re-instantiate the old behavior ?

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1681627002


From thartmann at openjdk.org  Thu Aug 17 10:07:49 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 17 Aug 2023 10:07:49 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
Message-ID: <9fttedXhi3ToSaVeEycUfxeQunONk36m_WpEO6D2r-Y=.2063295b-5fa4-4365-98fa-e8a8a1a53af8@github.com>

On Tue, 25 Jul 2023 09:56:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

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

Thanks for investigating this issue. I've run some quick testing and there are new failures:

`compiler/valhalla/inlinetypes/TestC1.java` with `-XX:TieredStopAtLevel=1`:


# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/workspace/open/src/hotspot/share/c1/c1_LIRGenerator.cpp:1778), pid=336001, tid=336015
#  assert(field->type()->as_inline_klass()->is_initialized()) failed: Must be
#
# JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2, compiled mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x7dc168]  LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808

Current CompileTask:
C1:   7349 3404    b  1       compiler.valhalla.inlinetypes.TestC1::test7_verifier (47 bytes)

Stack: [0x00007f16d9b00000,0x00007f16d9c00000],  sp=0x00007f16d9bfd810,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x7dc168]  LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808  (c1_LIRGenerator.cpp:1778)
V  [libjvm.so+0x7de2ee]  LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x52e  (c1_LIRGenerator.cpp:2365)
V  [libjvm.so+0x7c2433]  LIRGenerator::do_root(Instruction*)+0x63  (c1_LIRGenerator.cpp:378)
V  [libjvm.so+0x7c799e]  non-virtual thunk to LIRGenerator::block_do(BlockBegin*)+0x5e  (c1_LIRGenerator.cpp:375)
V  [libjvm.so+0x78a891]  BlockList::iterate_forward(BlockClosure*)+0x41  (c1_Instruction.cpp:1026)
V  [libjvm.so+0x74a94e]  Compilation::emit_lir()+0x50e  (c1_Compilation.cpp:258)
V  [libjvm.so+0x74d30f]  Compilation::compile_java_method()+0x32f  (c1_Compilation.cpp:404)
V  [libjvm.so+0x74dc29]  Compilation::compile_method()+0x179  (c1_Compilation.cpp:473)
V  [libjvm.so+0x74e41a]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x35a  (c1_Compilation.cpp:606)
V  [libjvm.so+0x74ff2e]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xde  (c1_Compiler.cpp:254)
V  [libjvm.so+0xa37780]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00  (compileBroker.cpp:2265)
V  [libjvm.so+0xa385a8]  CompileBroker::compiler_thread_loop()+0x5b8  (compileBroker.cpp:1944)
V  [libjvm.so+0xef4fec]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:720)
V  [libjvm.so+0x17f23ca]  Thread::call_run()+0xba  (thread.cpp:217)
V  [libjvm.so+0x14dbdcc]  thread_native_entry(Thread*)+0x11c  (os_linux.cpp:779)


`compiler/valhalla/inlinetypes/TestBasicFunctionality.java` with `-DWarmup=0 -DVerifyIR=false`


# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/workspace/open/src/hotspot/share/opto/inlinetypenode.cpp:884), pid=3588916, tid=3588932
#  assert(!null_free || vt->is_allocated(&gvn)) failed: inline type should be allocated
#
# JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xe57aa7]  InlineTypeNode::make_from_oop_impl(GraphKit*, Node*, ciInlineKlass*, bool, GrowableArray<ciType*>&)+0x417

Current CompileTask:
C2:  40242  965    b  4       compiler.valhalla.inlinetypes.TestBasicFunctionality::test37 (2 bytes)

Stack: [0x00007f0d778ff000,0x00007f0d779ff000],  sp=0x00007f0d779fb8e0,  free space=1010k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xe57aa7]  InlineTypeNode::make_from_oop_impl(GraphKit*, Node*, ciInlineKlass*, bool, GrowableArray<ciType*>&)+0x417  (inlinetypenode.cpp:884)
V  [libjvm.so+0xe58e54]  InlineTypeNode::initialize_fields(GraphKit*, MultiNode*, unsigned int&, bool, bool, Node*, GrowableArray<ciType*>&)+0xa24  (inlinetypenode.cpp:1146)
V  [libjvm.so+0xe59603]  InlineTypeNode::make_from_multi(GraphKit*, MultiNode*, ciInlineKlass*, unsigned int&, bool, bool)+0x103  (inlinetypenode.cpp:920)
V  [libjvm.so+0x15227ee]  Compile::build_start_state(StartNode*, TypeFunc const*)+0x7ee  (parse1.cpp:878)
V  [libjvm.so+0xa2b956]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1706  (compile.cpp:792)
V  [libjvm.so+0x876b4e]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x10e  (c2compiler.cpp:115)
V  [libjvm.so+0xa37780]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00  (compileBroker.cpp:2265)
V  [libjvm.so+0xa385a8]  CompileBroker::compiler_thread_loop()+0x5b8  (compileBroker.cpp:1944)
V  [libjvm.so+0xef4fec]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:720)
V  [libjvm.so+0x17f23ca]  Thread::call_run()+0xba  (thread.cpp:217)
V  [libjvm.so+0x14dbdcc]  thread_native_entry(Thread*)+0x11c  (os_linux.cpp:779)

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1682003716


From jbhateja at openjdk.org  Thu Aug 17 11:17:29 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Aug 2023 11:17:29 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening. [v2]
In-Reply-To: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
Message-ID: <o2jA0HDwT7QsPNrkxPh5UdfH3RJzE1_osMvLguSdoGw=.ccde95e3-e9a5-4be2-807a-0098519ca43b@github.com>

> -  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
>  - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.
> 
> Kindly review.
> 
> Tier1 regressions are clean.
> 
> Best Regards,
> Jatin Bhateja

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

  Adding an IR test and review comment resolution.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/907/files
  - new: https://git.openjdk.org/valhalla/pull/907/files/c69d885f..560d8b69

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

  Stats: 95 lines in 3 files changed: 94 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/907.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/907/head:pull/907

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


From jbhateja at openjdk.org  Thu Aug 17 11:17:30 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Aug 2023 11:17:30 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening.
In-Reply-To: <zNNAKIj_Faw5EhKYmTSjKeprfp7AvPQDrJLeYMYFsIQ=.330ebca2-7345-414a-92a0-5661d08faf22@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
 <zNNAKIj_Faw5EhKYmTSjKeprfp7AvPQDrJLeYMYFsIQ=.330ebca2-7345-414a-92a0-5661d08faf22@github.com>
Message-ID: <nfUWHLS8skrC7_IgubvwdpCW0pKgGcc1Mmp0HKojMMk=.3467db1b-570a-4a0a-8c2d-b56bbe005d68@github.com>

On Wed, 16 Aug 2023 13:37:46 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> -  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
>>  - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.
>> 
>> Kindly review.
>> 
>> Tier1 regressions are clean.
>> 
>> Best Regards,
>> Jatin Bhateja
>
> Thanks for fixing this, Jatin. Could you add a corresponding IR framework test?

Hi @TobiHartmann , comments addressed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/907#issuecomment-1682098486


From xgong at openjdk.org  Fri Aug 18 07:54:56 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 18 Aug 2023 07:54:56 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <9fttedXhi3ToSaVeEycUfxeQunONk36m_WpEO6D2r-Y=.2063295b-5fa4-4365-98fa-e8a8a1a53af8@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <9fttedXhi3ToSaVeEycUfxeQunONk36m_WpEO6D2r-Y=.2063295b-5fa4-4365-98fa-e8a8a1a53af8@github.com>
Message-ID: <9qFvQyG1zsztFfzvlGPc4N2B7Q3AqXlnVnXWr-AI_0g=.daa2b0d1-f7c1-461e-aed2-5f7d49e0365c@github.com>

On Thu, 17 Aug 2023 10:04:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Not flatten L-descriptor value object field even it is final
>
> Thanks for investigating this issue. I've run some quick testing and there are new failures:
> 
> `compiler/valhalla/inlinetypes/TestC1.java` with `-XX:TieredStopAtLevel=1`:
> 
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/workspace/open/src/hotspot/share/c1/c1_LIRGenerator.cpp:1778), pid=336001, tid=336015
> #  assert(field->type()->as_inline_klass()->is_initialized()) failed: Must be
> #
> # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2, compiled mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x7dc168]  LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808
> 
> Current CompileTask:
> C1:   7349 3404    b  1       compiler.valhalla.inlinetypes.TestC1::test7_verifier (47 bytes)
> 
> Stack: [0x00007f16d9b00000,0x00007f16d9c00000],  sp=0x00007f16d9bfd810,  free space=1014k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x7dc168]  LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808  (c1_LIRGenerator.cpp:1778)
> V  [libjvm.so+0x7de2ee]  LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x52e  (c1_LIRGenerator.cpp:2365)
> V  [libjvm.so+0x7c2433]  LIRGenerator::do_root(Instruction*)+0x63  (c1_LIRGenerator.cpp:378)
> V  [libjvm.so+0x7c799e]  non-virtual thunk to LIRGenerator::block_do(BlockBegin*)+0x5e  (c1_LIRGenerator.cpp:375)
> V  [libjvm.so+0x78a891]  BlockList::iterate_forward(BlockClosure*)+0x41  (c1_Instruction.cpp:1026)
> V  [libjvm.so+0x74a94e]  Compilation::emit_lir()+0x50e  (c1_Compilation.cpp:258)
> V  [libjvm.so+0x74d30f]  Compilation::compile_java_method()+0x32f  (c1_Compilation.cpp:404)
> V  [libjvm.so+0x74dc29]  Compilation::compile_method()+0x179  (c1_Compilation.cpp:473)
> V  [libjvm.so+0x74e41a]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x35a  (c1_Compilation.cpp:606)
> V  [libjvm.so+0x74ff2e]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xde  (c1_Compiler.cpp:254)
> V  [libjvm.so+0xa37780]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00  (compileBroker.cpp:2265)
> V  [libjvm.so+0xa385a8]  CompileBroker::compiler_thread_loop()+0x5b8  (compileBroker.cpp:1944)
> V  [li...

Thanks for looking at this PR @TobiHartmann ! I think there maybe some potential issues exposed after this change, since almost all value objects cannot be flattened anymore with `-XX:InlineFieldMaxFlatSize=0`, which may need the buffer allocated. 

> Thanks for investigating this issue. I've run some quick testing and there are new failures:
> 
> `compiler/valhalla/inlinetypes/TestC1.java` with `-XX:TieredStopAtLevel=1`:
> 
> ```
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/workspace/open/src/hotspot/share/c1/c1_LIRGenerator.cpp:1778), pid=336001, tid=336015
> #  assert(field->type()->as_inline_klass()->is_initialized()) failed: Must be
> #
> # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2, compiled mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x7dc168]  LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808
> 
> Current CompileTask:
> C1:   7349 3404    b  1       compiler.valhalla.inlinetypes.TestC1::test7_verifier (47 bytes)
> 
> Stack: [0x00007f16d9b00000,0x00007f16d9c00000],  sp=0x00007f16d9bfd810,  free space=1014k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x7dc168]  LIRGenerator::access_sub_element(LIRItem&, LIRItem&, LIR_Opr&, ciField*, int)+0x808  (c1_LIRGenerator.cpp:1778)
> V  [libjvm.so+0x7de2ee]  LIRGenerator::do_LoadIndexed(LoadIndexed*)+0x52e  (c1_LIRGenerator.cpp:2365)
> V  [libjvm.so+0x7c2433]  LIRGenerator::do_root(Instruction*)+0x63  (c1_LIRGenerator.cpp:378)
> V  [libjvm.so+0x7c799e]  non-virtual thunk to LIRGenerator::block_do(BlockBegin*)+0x5e  (c1_LIRGenerator.cpp:375)
> V  [libjvm.so+0x78a891]  BlockList::iterate_forward(BlockClosure*)+0x41  (c1_Instruction.cpp:1026)
> V  [libjvm.so+0x74a94e]  Compilation::emit_lir()+0x50e  (c1_Compilation.cpp:258)
> V  [libjvm.so+0x74d30f]  Compilation::compile_java_method()+0x32f  (c1_Compilation.cpp:404)
> V  [libjvm.so+0x74dc29]  Compilation::compile_method()+0x179  (c1_Compilation.cpp:473)
> V  [libjvm.so+0x74e41a]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x35a  (c1_Compilation.cpp:606)
> V  [libjvm.so+0x74ff2e]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xde  (c1_Compiler.cpp:254)
> V  [libjvm.so+0xa37780]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00  (compileBroker.cpp:2265)
> V  [libjvm.so+0xa385a8]  CompileBroker::compiler_thread_loop()+0x5b8  (compileBroker.cpp:1944)
> V  [libjvm.so+0xef4fec]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:720)
> V  [libjvm.so+0x17f23ca]  Thread::call_run()+0xba  (thread.cpp:217)
> V  [libjvm.so+0x14dbdcc]  thread_native_entry(Thread*)+0x11c  (os_linux.cpp:779)
> ```

Could you please show more env/options information on this issue? I cannot reproduce it even with `-XX:InlineFieldMaxFlatSize=0 -XX:TieredStopAtLevel=1` on our internal Arm NEON machine.  Since this PR will change the flat state of value objects, I'm not sure whether there is some affects on the value class loading/initialization policy?

> `compiler/valhalla/inlinetypes/TestBasicFunctionality.java` with `-DWarmup=0 -DVerifyIR=false`
> 
> ```
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/workspace/open/src/hotspot/share/opto/inlinetypenode.cpp:884), pid=3588916, tid=3588932> #  assert(!null_free || vt->is_allocated(&gvn)) failed: inline type should be allocated
> #
> # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-08-16-1408411.tobias.hartmann.valhalla2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0xe57aa7]  InlineTypeNode::make_from_oop_impl(GraphKit*, Node*, ciInlineKlass*, bool, GrowableArray<ciType*>&)+0x417
> 
> Current CompileTask:
> C2:  40242  965    b  4       compiler.valhalla.inlinetypes.TestBasicFunctionality::test37 (2 bytes)
> 
> Stack: [0x00007f0d778ff000,0x00007f0d779ff000],  sp=0x00007f0d779fb8e0,  free space=1010k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xe57aa7]  InlineTypeNode::make_from_oop_impl(GraphKit*, Node*, ciInlineKlass*, bool, GrowableArray<ciType*>&)+0x417  (inlinetypenode.cpp:884)
> V  [libjvm.so+0xe58e54]  InlineTypeNode::initialize_fields(GraphKit*, MultiNode*, unsigned int&, bool, bool, Node*, GrowableArray<ciType*>&)+0xa24  (inlinetypenode.cpp:1146)
> V  [libjvm.so+0xe59603]  InlineTypeNode::make_from_multi(GraphKit*, MultiNode*, ciInlineKlass*, unsigned int&, bool, bool)+0x103  (inlinetypenode.cpp:920)
> V  [libjvm.so+0x15227ee]  Compile::build_start_state(StartNode*, TypeFunc const*)+0x7ee  (parse1.cpp:878)
> V  [libjvm.so+0xa2b956]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1706  (compile.cpp:792)
> V  [libjvm.so+0x876b4e]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x10e  (c2compiler.cpp:115)
> V  [libjvm.so+0xa37780]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa00  (compileBroker.cpp:2265)
> V  [libjvm.so+0xa385a8]  CompileBroker::compiler_thread_loop()+0x5b8  (compileBroker.cpp:1944)
> V  [libjvm.so+0xef4fec]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:720)
> V  [libjvm.so+0x17f23ca]  Thread::call_run()+0xba  (thread.cpp:217)
> V  [libjvm.so+0x14dbdcc]  thread_native_entry(Thread*)+0x11c  (os_linux.cpp:779)
> ```

I also met the same crash on `lworld+vector` branch with this change when I was running Vector API tests. Actually I don't quite understand what this assertion mean? Why the `null_free` value type must be allocated in this routine? I need more investigation on it. And it will be helpful if anyone could give some guide/advice on this part. Thanks in advance!

Best Regards,
Xiaohong

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1683510063


From xgong at openjdk.org  Fri Aug 18 07:54:56 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Fri, 18 Aug 2023 07:54:56 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
 <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
 <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>
 <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>
Message-ID: <qpDyBhRfCyJc9LFJEQ1mvO4llycuJqgvrGbBTBLbbQQ=.18d0a66a-8804-42a4-8767-fe1a3fbbfafb@github.com>

On Thu, 17 Aug 2023 05:15:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Are you inclined to re-instantiate the old behavior ?

May I ask what the "old behavior" do you mean? Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1683511966


From thartmann at openjdk.org  Fri Aug 18 08:24:50 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 18 Aug 2023 08:24:50 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening. [v2]
In-Reply-To: <o2jA0HDwT7QsPNrkxPh5UdfH3RJzE1_osMvLguSdoGw=.ccde95e3-e9a5-4be2-807a-0098519ca43b@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
 <o2jA0HDwT7QsPNrkxPh5UdfH3RJzE1_osMvLguSdoGw=.ccde95e3-e9a5-4be2-807a-0098519ca43b@github.com>
Message-ID: <SHkGEDaKZasynyVFDokF6vHlB8MzrjGGxm9O9nTfb68=.4e2d7002-d3d0-4b28-a2e8-000602852e16@github.com>

On Thu, 17 Aug 2023 11:17:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> -  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
>>  - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.
>> 
>> Kindly review.
>> 
>> Tier1 regressions are clean.
>> 
>> Best Regards,
>> Jatin Bhateja
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding an IR test and review comment resolution.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestValueRematDuringTypeSharpening.java line 81:

> 79:        for (int i = 0; i < 10000; i++) {
> 80:            res += test((i % 1000) == 1 ? new dummyValue1(i) : new dummyValue2(i));
> 81:        }

I think you should leave warmup to the IR framework. If more iterations are needed, you can control that via the `@Warmup` annotation. And here, just do:

test(new dummyValue1(0));
test(new dummyValue2(2));

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/907#discussion_r1298160981


From jbhateja at openjdk.org  Fri Aug 18 18:56:32 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Aug 2023 18:56:32 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16
 scalar operations. [v4]
In-Reply-To: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
References: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
Message-ID: <6ZtznppSDRnEjZObGHyEyFdvbfXr1TQvklL45bwFmPg=.bf3fc04d-e2d3-4a1a-9c91-925d7fbfcb5c@github.com>

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

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

  Addressing offline review comments from Sandhya, new IR test addition.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/848/files
  - new: https://git.openjdk.org/valhalla/pull/848/files/5cd42f3b..6989b465

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

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

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


From jbhateja at openjdk.org  Fri Aug 18 20:13:28 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Aug 2023 20:13:28 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening. [v3]
In-Reply-To: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
Message-ID: <eBYLpvJbhhMF54gmaJEy3pSlLCN8KHOV2IYOEetpTVA=.81bdecd7-5c5d-4ca8-8cae-d91147e8b848@github.com>

> -  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
>  - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.
> 
> Kindly review.
> 
> Tier1 regressions are clean.
> 
> Best Regards,
> Jatin Bhateja

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/907/files
  - new: https://git.openjdk.org/valhalla/pull/907/files/560d8b69..bfa0a1f2

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

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

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


From jbhateja at openjdk.org  Fri Aug 18 20:13:31 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Aug 2023 20:13:31 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening. [v2]
In-Reply-To: <SHkGEDaKZasynyVFDokF6vHlB8MzrjGGxm9O9nTfb68=.4e2d7002-d3d0-4b28-a2e8-000602852e16@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
 <o2jA0HDwT7QsPNrkxPh5UdfH3RJzE1_osMvLguSdoGw=.ccde95e3-e9a5-4be2-807a-0098519ca43b@github.com>
 <SHkGEDaKZasynyVFDokF6vHlB8MzrjGGxm9O9nTfb68=.4e2d7002-d3d0-4b28-a2e8-000602852e16@github.com>
Message-ID: <gq0t5ICJo0UltEoKiPDVPxhk198ISdTIQJlGLnSODRQ=.4702aa33-cb30-414f-8476-30a1ef390d37@github.com>

On Fri, 18 Aug 2023 08:21:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding an IR test and review comment resolution.
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestValueRematDuringTypeSharpening.java line 81:
> 
>> 79:        for (int i = 0; i < 10000; i++) {
>> 80:            res += test((i % 1000) == 1 ? new dummyValue1(i) : new dummyValue2(i));
>> 81:        }
> 
> I think you should leave warmup to the IR framework. If more iterations are needed, you can control that via the `@Warmup` annotation. And here, just do:
> 
> test(new dummyValue1(0));
> test(new dummyValue2(2));

Thanks @TobiHartmann , standalone run mode has no warmups hence there was an explicit warmup loop, changed as per your suggestion.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/907#discussion_r1298829475


From jbhateja at openjdk.org  Sat Aug 19 04:47:54 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sat, 19 Aug 2023 04:47:54 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well [v2]
In-Reply-To: <qpDyBhRfCyJc9LFJEQ1mvO4llycuJqgvrGbBTBLbbQQ=.18d0a66a-8804-42a4-8767-fe1a3fbbfafb@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
 <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
 <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>
 <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>
 <qpDyBhRfCyJc9LFJEQ1mvO4llycuJqgvrGbBTBLbbQQ=.18d0a66a-8804-42a4-8767-fe1a3fbbfafb@github.com>
Message-ID: <13Toexb0NM-WYizAXfLLZiAhvDNMLjeySOLID5JyH6k=.90081b8f-fc73-4f1d-9d27-a0c5200da8d9@github.com>

On Fri, 18 Aug 2023 07:51:39 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Are you inclined to re-instantiate the old behavior ?
> 
> May I ask what the "old behavior" do you mean? Thanks!

Hi @XiaohongGong ,
Updated my previous comment, I am able reproduce an intermittent crash in another test "compiler/valhalla/inlinetypes/TestGetfieldChains.java" with additional JVM options :  "-Xbatch -XX:TieredStopAtLevel=1 -XX:CompileThresholdScaling=0.1 -XX:InlineFieldMaxFlatSize=0"
[hs_err_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385038/hs_err_pid1570004.txt)
[replay_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385039/replay_pid1570004.txt)
[TestGetfieldChains.txt](https://github.com/openjdk/valhalla/files/12385040/TestGetfieldChains.txt)

Please find attached relevant logs and replay file.

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1684804779


From christianlombardo at verizon.net  Sat Aug 19 20:05:44 2023
From: christianlombardo at verizon.net (Christian Lombardo)
Date: Sat, 19 Aug 2023 20:05:44 +0000 (UTC)
Subject: [lworld] RFR: 8311219: [lworld] VM option
 "InlineFieldMaxFlatSize" cannot work well [v2]
In-Reply-To: <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
 <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
 <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>
 <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>
Message-ID: <626792092.1088526.1692475544455@mail.yahoo.com>

Hello Team.
May you please unsubscribe me from this list, I'm changing careers :-) Keep up the great work everyone!

Love, Peace, Joy, Health, Wealth, Abundance, Happiness, Strength, Vitality, Power
Christian

Christian Lombardo, ME, OCPJP 1.6
christianlombardo at verizon.net
http://www.linkedin.com/in/christianlombardo
http://fortitudevolution.com/blog/ 

    On Thursday, August 17, 2023 at 01:19:31 AM EDT, Jatin Bhateja <jbhateja at openjdk.org> wrote:  
 
 On Thu, 17 Aug 2023 01:51:08 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Just going slightly off the topic, in context of Vector APIs (lworld+vector) all the payloads are final primitive class fields and will always be flattened in their respective boxes.
> 
> Sorry for my late reply! And yes, the payloads in Vector APIs are always be flattened for current vector size. What my concern is the larger vector size like in Arm SVE after we support the SPECIES_MAX vectors, and the expected behavior/difference if people set a smaller max flat size with `InlineFieldMaxFlatSize`.
> 
> Thanks, Xiaohong

That's correct!, my above comment was in context of existing handling where final fields of [null-restricted value types](https://openjdk.org/jeps/401) are always flattened irrespective of InlineFieldMaxFlatSize.? Are you inclined to re-instantiate the old behavior ?

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1681627002
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230819/8c39c095/attachment.htm>

From xgong at openjdk.org  Mon Aug 21 03:53:44 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 21 Aug 2023 03:53:44 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <13Toexb0NM-WYizAXfLLZiAhvDNMLjeySOLID5JyH6k=.90081b8f-fc73-4f1d-9d27-a0c5200da8d9@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
 <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
 <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>
 <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>
 <qpDyBhRfCyJc9LFJEQ1mvO4llycuJqgvrGbBTBLbbQQ=.18d0a66a-8804-42a4-8767-fe1a3fbbfafb@github.com>
 <13Toexb0NM-WYizAXfLLZiAhvDNMLjeySOLID5JyH6k=.90081b8f-fc73-4f1d-9d27-a0c5200da8d9@github.com>
Message-ID: <tRsCa73tYMEI_bqqj8Ihf6D-B1elob_wMlvRXMH1HZ8=.e9a0a449-349a-4a8e-8a9d-f6f5022e36a5@github.com>

On Sat, 19 Aug 2023 04:45:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > > Are you inclined to re-instantiate the old behavior ?
> > 
> > 
> > May I ask what the "old behavior" do you mean? Thanks!
> 
> Hi @XiaohongGong , Updated my previous comment, I am able reproduce an intermittent crash in another test "compiler/valhalla/inlinetypes/TestGetfieldChains.java" with additional JVM options : "-Xbatch -XX:TieredStopAtLevel=1 -XX:CompileThresholdScaling=0.1 -XX:InlineFieldMaxFlatSize=0" [hs_err_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385038/hs_err_pid1570004.txt) [replay_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385039/replay_pid1570004.txt) [TestGetfieldChains.txt](https://github.com/openjdk/valhalla/files/12385040/TestGetfieldChains.txt)
> 
> Please find attached relevant logs and replay file.
> 
> Best Regards, Jatin

Thanks for pointing out this! I can reproduce this issue after I rebase my patch to latest `lworld` branch. I will try my best to look at what is changed. 

Best Regards,
Xiaohong

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1685597423


From thartmann at openjdk.org  Mon Aug 21 07:20:51 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 21 Aug 2023 07:20:51 GMT
Subject: [lworld] RFR: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening. [v3]
In-Reply-To: <eBYLpvJbhhMF54gmaJEy3pSlLCN8KHOV2IYOEetpTVA=.81bdecd7-5c5d-4ca8-8cae-d91147e8b848@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
 <eBYLpvJbhhMF54gmaJEy3pSlLCN8KHOV2IYOEetpTVA=.81bdecd7-5c5d-4ca8-8cae-d91147e8b848@github.com>
Message-ID: <aJMoPJx4L5nG6yZCNYh_Tx5-dysEZH6l33T-J7jS0hc=.37a999c9-2992-480c-a727-a91722498a75@github.com>

On Fri, 18 Aug 2023 20:13:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> -  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
>>  - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.
>> 
>> Kindly review.
>> 
>> Tier1 regressions are clean.
>> 
>> Best Regards,
>> Jatin Bhateja
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

Looks good to me. Thanks for fixing!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/907#pullrequestreview-1586349684


From jbhateja at openjdk.org  Mon Aug 21 07:42:56 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Aug 2023 07:42:56 GMT
Subject: [lworld] Integrated: 8314190: [lworld] Missing InlineTypeNode
 re-materialization during type sharpening.
In-Reply-To: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
References: <G7Wt-E389HkaCjE--bM86DoEhjDsNx48ME_LE8GN-k0=.03db8ae8-1465-4d49-af9e-fa067679a465@github.com>
Message-ID: <wUCXJsKeo5ziOuhw6bA2qeActaj_jVcTHxcGPiviZ-c=.354301bf-102b-4ba4-903e-6b5d9d6b209b@github.com>

On Tue, 15 Aug 2023 11:02:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> -  Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant.
>  - This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to rematerialize InlineTypeNode from newly casted object which was missing and is fixed by the patch.
> 
> Kindly review.
> 
> Tier1 regressions are clean.
> 
> Best Regards,
> Jatin Bhateja

This pull request has now been integrated.

Changeset: 9ceb30ba
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9ceb30babc0a1aa5224ca08c8cd77eed391cd3db
Stats:     95 lines in 3 files changed: 95 ins; 0 del; 0 mod

8314190: [lworld] Missing InlineTypeNode re-materialization during type sharpening.

Reviewed-by: thartmann

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

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


From jbhateja at openjdk.org  Mon Aug 21 07:43:08 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Aug 2023 07:43:08 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation regression
 fixes and cleanups.
Message-ID: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>

Patch fixes following problem seen during validation:-

**CDS:-**
- Problem while restoring value object mirrors. These are needed to perform class level comparisons.

**VM:-**
- Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.

**ci Model:-**
- Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.

**C1 compiler:-**
- Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.

**C2 compiler:-**
1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.

>     vt = newPayload();
>     vt = Unsafe.makePrivateBuffer(vt);
>     for (int i = 0; i < Double128.length; i++) {
>          if (mask[i]) {
>               Unsafe.putDouble(vt, apply(src[i]));
>          }
>     }

   Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.

3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.

4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetype we need to re-materialize InlineTypeNode from newly casted object which was missing.

**Validation Status with patch.**
  - All VectorAPI Jtreg test points except following known issues are passing on x86 at various AVX levels and compilation levels.

**Pending/know issues:-**

1. Failures in some of the mask/shuffle related test points with -XX:+DeoptimizeALot, to be resolved after mainline merge to incorporate major shuffle re-structuring changes in in mainline.
2. Test point using Max-Species are failing, to be fixed with max species support in subsequent patch.
3. Assertion failure in cyclic graph check due to unexpected graph shape seen in box expansion.

Kindly review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - 8314628: [lworld+vector] validation regression fixes and cleanups.

Changes: https://git.openjdk.org/valhalla/pull/909/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=909&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314628
  Stats: 170 lines in 18 files changed: 99 ins; 41 del; 30 mod
  Patch: https://git.openjdk.org/valhalla/pull/909.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/909/head:pull/909

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


From xgong at openjdk.org  Tue Aug 22 02:15:50 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 22 Aug 2023 02:15:50 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
Message-ID: <9zhfXh5pXSfArhD8cu-DwoYQ8cO6BRm6SqVSoUrZdz0=.c5e674a5-06c8-4acc-b34e-77b6b2bc40da@github.com>

On Mon, 21 Aug 2023 07:36:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch fixes following problem seen during validation:-
> 
> **CDS:-**
> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
> 
> **VM:-**
> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
> 
> **ci Model:-**
> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
> 
> **C1 compiler:-**
> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
> 
> **C2 compiler:-**
> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
> 
>>     vt = newPayload();
>>     vt = Unsafe.makePrivateBuffer(vt);
>>     for (int i = 0; i < Double128.length; i++) {
>>          if (mask[i]) {
>>               Unsafe.putDouble(vt, apply(src[i]));
>>          }
>>     }
> 
>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
> 
> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
> 
> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetyp...

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

> 2205:             StoreField* store = new StoreField(new_instance, offset + sec_offset, temp, replacement, false, state_before, false);
> 2206:             append(store);
> 2207:           }

Do you have a further plan to refactor the multifields parser in ci stage so that we can remove these similar handling for multifields in many places?

src/hotspot/share/classfile/javaClasses.cpp line 4989:

> 4987:   o->obj_field_put(_payload_offset, val);
> 4988: }
> 4989: 

Can we also clean-up the classfile symbols in https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/vmClassMacros.hpp#L197 and https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/vmSymbols.hpp#L97 ?

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

> 511:       bool mismatched = (decorators & C2_MISMATCHED) != 0;
> 512:       ciField* field = holder->get_field_by_offset(offset, false);
> 513:       if (base->is_Con() && !is_array && !mismatched && !field->is_multifield_base() && ft->bundle_size() == 1) {

Could we remove the last `ft->bundle_size() == 1` check?

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

> 857:   int vec_len = field_type->bundle_size();
> 858:   Node* value = gvn.zerocon(field_type->basic_type());
> 859:   int is_multifield = klass->declared_nonstatic_field_at(index)->is_multifield_base();

Rename `is_multifield` to `is_multifield_base` ? 
Or directly change to:

if (is_java_primitive(bt) &&
    klass->declared_nonstatic_field_at(index)->is_multifield_base() &&
    Matcher::match_rule_supported_vector(...))

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1300823248
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1300824685
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1300825038
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1300825532


From xgong at openjdk.org  Tue Aug 22 03:01:44 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 22 Aug 2023 03:01:44 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
Message-ID: <OZBSfT_tnvylVNb5gZ01Ns9kBMXqIpb3hLmh0SB5SFI=.bdbab17c-2528-461c-aabe-a2060ec72626@github.com>

On Mon, 21 Aug 2023 07:36:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch fixes following problem seen during validation:-
> 
> **CDS:-**
> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
> 
> **VM:-**
> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
> 
> **ci Model:-**
> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
> 
> **C1 compiler:-**
> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
> 
> **C2 compiler:-**
> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
> 
>>     vt = newPayload();
>>     vt = Unsafe.makePrivateBuffer(vt);
>>     for (int i = 0; i < Double128.length; i++) {
>>          if (mask[i]) {
>>               Unsafe.putDouble(vt, apply(src[i]));
>>          }
>>     }
> 
>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
> 
> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
> 
> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetyp...

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

> 2342:     if (is_store) {
> 2343:       ciInlineKlass* vk = vt->type()->inline_klass();
> 2344:       if (!vt->is_allocated(&_gvn)) {

`vk` is unused in this block, so it can be removed?

src/hotspot/share/opto/parse1.cpp line 2400:

> 2398:       }
> 2399:     } else if ((is_vector_value && skip_scalarization) ||
> 2400:                (value->Opcode() != Op_VectorBox && value->is_InlineType())) {

`is_vector_value` can be removed in the `else-if` condition since `skip_scalarization = is_vector_value && Compile::current()->inlining_incrementally();` , right?

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

> 334: 
> 335:   Node* klass_node = kit.makecon(TypeKlassPtr::make(vk));
> 336:   Node* alloc_oop  = kit.new_instance(klass_node, NULL, NULL, /* deoptimize_on_exception */ true);

Is there any issue if adding `vector` to the alloc node's using edge here?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1300845435
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1300850192
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1300850651


From xgong at openjdk.org  Tue Aug 22 03:16:51 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 22 Aug 2023 03:16:51 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
Message-ID: <asYWgzIIB5RE8bi2EsNck6KoXZTivgvzZPcoWVS7Cwg=.530ac76e-e6ee-4008-b19e-b6b88c402612@github.com>

On Mon, 21 Aug 2023 07:36:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch fixes following problem seen during validation:-
> 
> **CDS:-**
> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
> 
> **VM:-**
> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
> 
> **ci Model:-**
> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
> 
> **C1 compiler:-**
> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
> 
> **C2 compiler:-**
> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
> 
>>     vt = newPayload();
>>     vt = Unsafe.makePrivateBuffer(vt);
>>     for (int i = 0; i < Double128.length; i++) {
>>          if (mask[i]) {
>>               Unsafe.putDouble(vt, apply(src[i]));
>>          }
>>     }
> 
>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
> 
> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
> 
> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetyp...

Could you please update the copyright in file `src/hotspot/share/ci/ciStreams.cpp`?

src/hotspot/share/ci/ciInstanceKlass.cpp line 572:

> 570: 
> 571:   return mfield;
> 572: }

This whole logic is quite similar with the one in `compute_nonstatic_fields_impl` when the field is a multifield. But the code style is not the same. For example, we check the `sec_fields_count` when field is multifield. This is right to me, in case other multifield is appended to a previous multifield_base which is not its expected one, although we do not have such cases now. But this similar check is missing in `compute_nonstatic_fields_impl`, isn't it? 

Another suggestion is: can we directly use `ciMultiField` instead of `ciField` as the method argument type? Besides, may I ask why we have to new another `ciMultiField`, set the secondary_fields to it and return? Can we modify the input field instead and change the method's return type to `void`?

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

PR Comment: https://git.openjdk.org/valhalla/pull/909#issuecomment-1687351223
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1300855868


From xgong at openjdk.org  Tue Aug 22 06:23:45 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 22 Aug 2023 06:23:45 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
Message-ID: <omLh1foNKX7qomHa7uqphpzbB2Njkq-WYwSMeThZ2eY=.f9e38ecf-07ed-441c-ac02-69823515bd37@github.com>

On Mon, 21 Aug 2023 07:36:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch fixes following problem seen during validation:-
> 
> **CDS:-**
> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
> 
> **VM:-**
> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
> 
> **ci Model:-**
> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
> 
> **C1 compiler:-**
> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
> 
> **C2 compiler:-**
> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
> 
>>     vt = newPayload();
>>     vt = Unsafe.makePrivateBuffer(vt);
>>     for (int i = 0; i < Double128.length; i++) {
>>          if (mask[i]) {
>>               Unsafe.putDouble(vt, apply(src[i]));
>>          }
>>     }
> 
>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
> 
> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
> 
> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetyp...

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

> 2656:   }
> 2657:   InlineTypeNode* vt = buffer->as_InlineType();
> 2658:   if (!vt->is_allocated(&_gvn) || VectorSupport::is_vector_payload_mf(vt->inline_klass()->get_InlineKlass())) {

This will make the `finishPrivateBuffer` un-inlined in all Vector API cases, won't it? This seems not so efficient to me. But I cannot find a better way to fix the masked cases now.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1301050523


From daniel at wwwmaster.at  Tue Aug 22 08:57:30 2023
From: daniel at wwwmaster.at (Daniel Schmid)
Date: Tue, 22 Aug 2023 10:57:30 +0200
Subject: super constructor of abstract value classes
Message-ID: <0295e153-3efd-93d0-918a-98d9cc555b83@wwwmaster.at>

Hi,

When reading the recent article that explains how Q-descriptors and 
v-bytecodes are not needed 
(https://cr.openjdk.org/~jrose/values/larval-values.html), I came across

 > To avoid such ambiguities, we forbid calling the superclass <init> 
method.

This seems like a pretty strong restriction though I understand why it's 
in place.
Nevertheless, it raises a question when I am reading this:
If it is possible to create abstract value classes (i.e. abstract 
classes where all subclasses are value classes), is this restriction 
really necessary for that case?
Since the superclass would "know" its subclasses are value classes, 
can't the object be copied, modified in the super constructor (the one 
of the abstract value class) before all fields are copied back when 
continuing with the constructor of the concrete value class?
Or are there just no "abstract value classes" or do you want to keep the 
same restrictions on all kind of abstract classes for consistency?

Yours,
Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230822/6179e7d0/smime.p7s>

From jbhateja at openjdk.org  Tue Aug 22 10:18:06 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 22 Aug 2023 10:18:06 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <9zhfXh5pXSfArhD8cu-DwoYQ8cO6BRm6SqVSoUrZdz0=.c5e674a5-06c8-4acc-b34e-77b6b2bc40da@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
 <9zhfXh5pXSfArhD8cu-DwoYQ8cO6BRm6SqVSoUrZdz0=.c5e674a5-06c8-4acc-b34e-77b6b2bc40da@github.com>
Message-ID: <NSUbb8Eonk5jiOnETtfA4W4H5nlFO-CksyY3C3TcpaU=.67fb0f58-eaea-4dfd-8d86-330d676acd8a@github.com>

On Tue, 22 Aug 2023 02:03:45 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Patch fixes following problem seen during validation:-
>> 
>> **CDS:-**
>> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
>> 
>> **VM:-**
>> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
>> 
>> **ci Model:-**
>> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
>> 
>> **C1 compiler:-**
>> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
>> 
>> **C2 compiler:-**
>> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
>> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
>> 
>>>     vt = newPayload();
>>>     vt = Unsafe.makePrivateBuffer(vt);
>>>     for (int i = 0; i < Double128.length; i++) {
>>>          if (mask[i]) {
>>>               Unsafe.putDouble(vt, apply(src[i]));
>>>          }
>>>     }
>> 
>>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
>> 
>> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
>> 
>> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to ...
>
> src/hotspot/share/classfile/javaClasses.cpp line 4989:
> 
>> 4987:   o->obj_field_put(_payload_offset, val);
>> 4988: }
>> 4989: 
> 
> Can we also clean-up the classfile symbols in https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/vmClassMacros.hpp#L197 and https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/vmSymbols.hpp#L97 ?

I am planning to use these symbol definitions in Max species support, estimation of multifield bundle size for max species cannot be just done based on MaxVectorSize, e.g., both LongMaxMask and ByteMaxMask will encapsulate VectorPayloadMFMaxZ which will hold @multifield(-1) annotated boolean mfield.

In order to determine the bundle size, we need to resort to VM symbol name comparison during field parsing, payload class names should also be different for Byte and Long max species mask e.g. VectorPayloadMFMaxZL and VectorPayLoadMFMaxZB. Bundle size for Long should be 8 while for Byte should be 64 for 512-bit MaxVectorSize.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1301422277


From jbhateja at openjdk.org  Tue Aug 22 10:39:50 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 22 Aug 2023 10:39:50 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <omLh1foNKX7qomHa7uqphpzbB2Njkq-WYwSMeThZ2eY=.f9e38ecf-07ed-441c-ac02-69823515bd37@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
 <omLh1foNKX7qomHa7uqphpzbB2Njkq-WYwSMeThZ2eY=.f9e38ecf-07ed-441c-ac02-69823515bd37@github.com>
Message-ID: <dZ51qI-LzxMWfnZulQIC56pyFL3IOMMfxK4KCHvMLDc=.93eadaed-3b39-47ca-aa10-c0f60078e39e@github.com>

On Tue, 22 Aug 2023 06:20:31 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Patch fixes following problem seen during validation:-
>> 
>> **CDS:-**
>> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
>> 
>> **VM:-**
>> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
>> 
>> **ci Model:-**
>> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
>> 
>> **C1 compiler:-**
>> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
>> 
>> **C2 compiler:-**
>> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
>> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
>> 
>>>     vt = newPayload();
>>>     vt = Unsafe.makePrivateBuffer(vt);
>>>     for (int i = 0; i < Double128.length; i++) {
>>>          if (mask[i]) {
>>>               Unsafe.putDouble(vt, apply(src[i]));
>>>          }
>>>     }
>> 
>>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
>> 
>> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
>> 
>> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to ...
>
> src/hotspot/share/opto/library_call.cpp line 2658:
> 
>> 2656:   }
>> 2657:   InlineTypeNode* vt = buffer->as_InlineType();
>> 2658:   if (!vt->is_allocated(&_gvn) || VectorSupport::is_vector_payload_mf(vt->inline_klass()->get_InlineKlass())) {
> 
> This will make the `finishPrivateBuffer` un-inlined in all Vector API cases, won't it? This seems not so efficient to me. But I cannot find a better way to fix the masked cases now.

You are right, but it will not affect the performance given that code is part of fallback implementation.

> src/hotspot/share/opto/vector.cpp line 336:
> 
>> 334: 
>> 335:   Node* klass_node = kit.makecon(TypeKlassPtr::make(vk));
>> 336:   Node* alloc_oop  = kit.new_instance(klass_node, NULL, NULL, /* deoptimize_on_exception */ true);
> 
> Is there any issue if adding `vector` to the alloc node's using edge here?

Yes, it causes an [assertion](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L1312) failure in InlineTypeNode::remove_redundant_allocations pass which expect such an allocation to be remove during InlineTypeNode Idealizations.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1301446721
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1301446609


From forax at univ-mlv.fr  Tue Aug 22 13:41:47 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 22 Aug 2023 15:41:47 +0200 (CEST)
Subject: super constructor of abstract value classes
In-Reply-To: <0295e153-3efd-93d0-918a-98d9cc555b83@wwwmaster.at>
References: <0295e153-3efd-93d0-918a-98d9cc555b83@wwwmaster.at>
Message-ID: <2016145115.16163142.1692711707941.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Daniel Schmid" <daniel at wwwmaster.at>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Tuesday, August 22, 2023 10:57:30 AM
> Subject: super constructor of abstract value classes

> Hi,

Hi Daniel,

> 
> When reading the recent article that explains how Q-descriptors and
> v-bytecodes are not needed
> (https://cr.openjdk.org/~jrose/values/larval-values.html), I came across
> 
> > To avoid such ambiguities, we forbid calling the superclass <init>
> method.
> 
> This seems like a pretty strong restriction though I understand why it's
> in place.
> Nevertheless, it raises a question when I am reading this:
> If it is possible to create abstract value classes (i.e. abstract
> classes where all subclasses are value classes), is this restriction
> really necessary for that case?

It is possible if the super class is marked as "value only" with ACC_VALUE but in that case it has no field (and its superclasses must have no field too).

> Since the superclass would "know" its subclasses are value classes,
> can't the object be copied, modified in the super constructor (the one
> of the abstract value class) before all fields are copied back when
> continuing with the constructor of the concrete value class?
> Or are there just no "abstract value classes" or do you want to keep the
> same restrictions on all kind of abstract classes for consistency?

I'm not sure you have fully understand the restriction about the constructor of a value class.

The current idea is that we do not need to change the actual verifier rules attached to invokespecial (see page 305 of https://docs.oracle.com/javase/specs/jvms/se20/jvms20.pdf) because we do not allow an invokespecial to occur inside the constructor of a value class (unlike the constructor of an identity class) so the verifier ensures that the constructor of a value class can not leak "this" for free.

If an invokespecial to the super class can occurs inside a value class constructor, then we have to change the verifier rules after the call to super(), the current rules allow to leak "this", but this is something we do not want for a value class given that the instance is still in larval state. 

As Brian said, it may be possible to relax the verifier rules but the gain is small compare to the complexity of modifying those rules. The verifier rules have bitten several of us in the past so we know that tweaking them will requires many engeneering cycles and we have better things to do.

> 
> Yours,
> Daniel

regards,
R?mi


From daniel at wwwmaster.at  Tue Aug 22 17:57:52 2023
From: daniel at wwwmaster.at (Daniel Schmid)
Date: Tue, 22 Aug 2023 19:57:52 +0200
Subject: super constructor of abstract value classes
In-Reply-To: <2016145115.16163142.1692711707941.JavaMail.zimbra@univ-eiffel.fr>
References: <2016145115.16163142.1692711707941.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <d0a5c3e0-5a43-b717-51f9-a390f70c6f68@wwwmaster.at>

Hi again,

First of all, thank you very much for your response, Remi. It really 
cleared up a few things for me.

> I'm not sure you have fully understand the restriction about the 
> constructor of a value class.

I made the wrong assumption that this was mainly about having multiple 
copies of the value object in multiple states and not about leaking 
this. Thanks for clearing that up.

> The current idea is that we do not need to change the actual verifier rules attached to invokespecial (see page 305 ofhttps://docs.oracle.com/javase/specs/jvms/se20/jvms20.pdf) because we do not allow an invokespecial to occur inside the constructor of a value class (unlike the constructor of an identity class) so the verifier ensures that the constructor of a value class can not leak "this" for free.
I understand the reasoning to not allow any actions in super 
constructors because that would require changing the verifier rules.
Nevertheless, I think this is a pretty strong restriction.
According to the document, it is required that "the no-argument 
constructor takes no action" in order to receive the "special marking" 
that it can be used as a super constructor of value classes.
I feel like the requirement for that marking could be relaxed a bit by 
saying that "the no-argument constructor is not allowed to use the 
this-reference except for setting fields" (and is also not allowed to 
call other methods) similar to essentially the same restriction required 
for "normal" object before the "super()" call in the constructor.

If I understood that correctly, it would be possible to mark a 
constructor as "trivial" (so that it can be used as a super constructor 
of value classes) in case the same requirements than the ones before the 
super() call of other constructors are met (and maybe also allow setting 
fields of the parent class).

Or is this also too much of an increase of complexity for only a small 
gain? Because I feel like essentially not allowing the constructor to do 
anything is a big loss.

Thank you for listening,
Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230822/23102e50/smime.p7s>

From xgong at openjdk.org  Wed Aug 23 02:01:47 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 23 Aug 2023 02:01:47 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <NSUbb8Eonk5jiOnETtfA4W4H5nlFO-CksyY3C3TcpaU=.67fb0f58-eaea-4dfd-8d86-330d676acd8a@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
 <9zhfXh5pXSfArhD8cu-DwoYQ8cO6BRm6SqVSoUrZdz0=.c5e674a5-06c8-4acc-b34e-77b6b2bc40da@github.com>
 <NSUbb8Eonk5jiOnETtfA4W4H5nlFO-CksyY3C3TcpaU=.67fb0f58-eaea-4dfd-8d86-330d676acd8a@github.com>
Message-ID: <GU7QiCEIK4pLfX27tiJajEo7nNB3CQq3srSEY-XSiWo=.619f0321-7cdb-48ae-b528-c399de4ee507@github.com>

On Tue, 22 Aug 2023 10:15:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 4989:
>> 
>>> 4987:   o->obj_field_put(_payload_offset, val);
>>> 4988: }
>>> 4989: 
>> 
>> Can we also clean-up the classfile symbols in https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/vmClassMacros.hpp#L197 and https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/vmSymbols.hpp#L97 ?
>
> I am planning to use these symbol definitions in Max species support, estimation of multifield bundle size for max species cannot be just done based on MaxVectorSize, e.g., both LongMaxMask and ByteMaxMask will encapsulate VectorPayloadMFMaxZ which will hold @multifield(-1) annotated boolean mfield.
> 
> In order to determine the bundle size, we need to resort to VM symbol name comparison during field parsing, payload class names should also be different for Byte and Long max species mask e.g. VectorPayloadMFMaxZL and VectorPayLoadMFMaxZB. Bundle size for Long should be 8 while for Byte should be 64 for 512-bit MaxVectorSize.

I also spent some time looking at this part. It's true that we have to distingunish the max lanecount for different types of VectorMask. As for this part, maybe we could also extend the `MultiField` annotation by adding another variable denotaing the type info like `esize/scale`. And calculate the right lanecount based on the `MaxVectorSize` and `esize/scale` when parsing classfile. WDYT?

>> src/hotspot/share/opto/library_call.cpp line 2658:
>> 
>>> 2656:   }
>>> 2657:   InlineTypeNode* vt = buffer->as_InlineType();
>>> 2658:   if (!vt->is_allocated(&_gvn) || VectorSupport::is_vector_payload_mf(vt->inline_klass()->get_InlineKlass())) {
>> 
>> This will make the `finishPrivateBuffer` un-inlined in all Vector API cases, won't it? This seems not so efficient to me. But I cannot find a better way to fix the masked cases now.
>
> You are right, but it will not affect the performance given that code is part of fallback implementation.

OK, it's fine to me now. We can revisit this part and fine tune if possible in future. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1302355132
PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1302356259


From jbhateja at openjdk.org  Wed Aug 23 03:30:17 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 23 Aug 2023 03:30:17 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups. [v2]
In-Reply-To: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
Message-ID: <qHfpOSkPmnN4zxpXo3oxF5VhbFJBngtYMCpCkUdbdy0=.3878d7bb-a82b-4a68-9c9c-1bf4f445e89a@github.com>

> Patch fixes following problem seen during validation:-
> 
> **CDS:-**
> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
> 
> **VM:-**
> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
> 
> **ci Model:-**
> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
> 
> **C1 compiler:-**
> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
> 
> **C2 compiler:-**
> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
> 
>>     vt = newPayload();
>>     vt = Unsafe.makePrivateBuffer(vt);
>>     for (int i = 0; i < Double128.length; i++) {
>>          if (mask[i]) {
>>               Unsafe.putDouble(vt, apply(src[i]));
>>          }
>>     }
> 
>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
> 
> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
> 
> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetyp...

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/909/files
  - new: https://git.openjdk.org/valhalla/pull/909/files/2cd01e89..bf690fa9

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

  Stats: 13 lines in 5 files changed: 5 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/909.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/909/head:pull/909

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


From jbhateja at openjdk.org  Wed Aug 23 03:30:20 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 23 Aug 2023 03:30:20 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups. [v2]
In-Reply-To: <asYWgzIIB5RE8bi2EsNck6KoXZTivgvzZPcoWVS7Cwg=.530ac76e-e6ee-4008-b19e-b6b88c402612@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
 <asYWgzIIB5RE8bi2EsNck6KoXZTivgvzZPcoWVS7Cwg=.530ac76e-e6ee-4008-b19e-b6b88c402612@github.com>
Message-ID: <VKMQK_nEjoxSIKYF7awtYPJcfseqIzrdDbFsL5bsgr8=.88e1da4e-2529-4378-ad4e-7cd1a8466693@github.com>

On Tue, 22 Aug 2023 03:10:59 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/ciInstanceKlass.cpp line 572:
> 
>> 570: 
>> 571:   return mfield;
>> 572: }
> 
> This whole logic is quite similar with the one in `compute_nonstatic_fields_impl` when the field is a multifield. But the code style is not the same. For example, we check the `sec_fields_count` when field is multifield. This is right to me, in case other multifield is appended to a previous multifield_base which is not its expected one, although we do not have such cases now. But this similar check is missing in `compute_nonstatic_fields_impl`, isn't it? 
> 
> Another suggestion is: can we directly use `ciMultiField` instead of `ciField` as the method argument type? Besides, may I ask why we have to new another `ciMultiField`, set the secondary_fields to it and return? Can we modify the input field instead and change the method's return type to `void`?

Yes, _compute_nonstatic_fields_impl_ is only called from [ InlineTypeNode constructor](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.hpp#L40), but while parsing field access bytecodes "withfield/getfield/putfield" both c1 and c2 compiler uses _ciBytecodeStream::get_field() API_,  since it directly operates over bytecode hence does not take into account the effect of @multifield annotation over it and earlier used to create only one ciField for base multifield instead of creating a hierarchical ciMutifield structure.

In addition, ClassFiledParser creates[ contiguous sequence of FieldInfo ](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/classFileParser.cpp#L1623) for both base and subsequent synthetic multifield, hense it's not possible to associate synthetic multifields with any other base multifield.

>>> But this similar check is missing in compute_nonstatic_fields_impl, isn't it?

We can add an assertion to check that secondary fields count always match the number of synthetic FieldInfos after base multifield.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1302421179


From jbhateja at openjdk.org  Wed Aug 23 03:30:18 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 23 Aug 2023 03:30:18 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <asYWgzIIB5RE8bi2EsNck6KoXZTivgvzZPcoWVS7Cwg=.530ac76e-e6ee-4008-b19e-b6b88c402612@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
 <asYWgzIIB5RE8bi2EsNck6KoXZTivgvzZPcoWVS7Cwg=.530ac76e-e6ee-4008-b19e-b6b88c402612@github.com>
Message-ID: <60JEr_AEPL8X1Kbfkp07undqbMXFh_A47DIp_gIDwp4=.2c2eac65-0c95-4c71-b883-6346814f45a0@github.com>

On Tue, 22 Aug 2023 03:13:25 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Patch fixes following problem seen during validation:-
>> 
>> **CDS:-**
>> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
>> 
>> **VM:-**
>> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
>> 
>> **ci Model:-**
>> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
>> 
>> **C1 compiler:-**
>> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
>> 
>> **C2 compiler:-**
>> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
>> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
>> 
>>>     vt = newPayload();
>>>     vt = Unsafe.makePrivateBuffer(vt);
>>>     for (int i = 0; i < Double128.length; i++) {
>>>          if (mask[i]) {
>>>               Unsafe.putDouble(vt, apply(src[i]));
>>>          }
>>>     }
>> 
>>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
>> 
>> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
>> 
>> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to ...
>
> Could you please update the copyright in file `src/hotspot/share/ci/ciStreams.cpp`?

Hi @XiaohongGong , your comments have been addressed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/909#issuecomment-1689204137


From xgong at openjdk.org  Wed Aug 23 03:30:47 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 23 Aug 2023 03:30:47 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups. [v2]
In-Reply-To: <VKMQK_nEjoxSIKYF7awtYPJcfseqIzrdDbFsL5bsgr8=.88e1da4e-2529-4378-ad4e-7cd1a8466693@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
 <asYWgzIIB5RE8bi2EsNck6KoXZTivgvzZPcoWVS7Cwg=.530ac76e-e6ee-4008-b19e-b6b88c402612@github.com>
 <VKMQK_nEjoxSIKYF7awtYPJcfseqIzrdDbFsL5bsgr8=.88e1da4e-2529-4378-ad4e-7cd1a8466693@github.com>
Message-ID: <rT0eKdr5pfuPJ4pjlY8hrwmBm095WYkNie44ch0cF04=.8a359b6d-78b5-4f18-98a8-88842844f40b@github.com>

On Wed, 23 Aug 2023 03:00:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/ci/ciInstanceKlass.cpp line 572:
>> 
>>> 570: 
>>> 571:   return mfield;
>>> 572: }
>> 
>> This whole logic is quite similar with the one in `compute_nonstatic_fields_impl` when the field is a multifield. But the code style is not the same. For example, we check the `sec_fields_count` when field is multifield. This is right to me, in case other multifield is appended to a previous multifield_base which is not its expected one, although we do not have such cases now. But this similar check is missing in `compute_nonstatic_fields_impl`, isn't it? 
>> 
>> Another suggestion is: can we directly use `ciMultiField` instead of `ciField` as the method argument type? Besides, may I ask why we have to new another `ciMultiField`, set the secondary_fields to it and return? Can we modify the input field instead and change the method's return type to `void`?
>
> Yes, _compute_nonstatic_fields_impl_ is only called from [ InlineTypeNode constructor](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.hpp#L40), but while parsing field access bytecodes "withfield/getfield/putfield" both c1 and c2 compiler uses _ciBytecodeStream::get_field() API_,  since it directly operates over bytecode hence does not take into account the effect of @multifield annotation over it and earlier used to create only one ciField for base multifield instead of creating a hierarchical ciMutifield structure.
> 
> In addition, ClassFiledParser creates[ contiguous sequence of FieldInfo ](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/classfile/classFileParser.cpp#L1623) for both base and subsequent synthetic multifield, hense it's not possible to associate synthetic multifields with any other base multifield.
> 
>>>> But this similar check is missing in compute_nonstatic_fields_impl, isn't it?
> 
> We can add an assertion to check that secondary fields count always match the number of synthetic FieldInfos after base multifield.

Sounds good to me. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1302424648


From xgong at openjdk.org  Wed Aug 23 09:25:09 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 23 Aug 2023 09:25:09 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <tRsCa73tYMEI_bqqj8Ihf6D-B1elob_wMlvRXMH1HZ8=.e9a0a449-349a-4a8e-8a9d-f6f5022e36a5@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
 <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
 <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>
 <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>
 <qpDyBhRfCyJc9LFJEQ1mvO4llycuJqgvrGbBTBLbbQQ=.18d0a66a-8804-42a4-8767-fe1a3fbbfafb@github.com>
 <13Toexb0NM-WYizAXfLLZiAhvDNMLjeySOLID5JyH6k=.90081b8f-fc73-4f1d-9d27-a0c5200da8d9@github.com>
 <tRsCa73tYMEI_bqqj8Ihf6D-B1elob_wMlvRXMH1HZ8=.e9a0a449-349a-4a8e-8a9d-f6f5022e36a5@github.com>
Message-ID: <x8Eo_9jVUxVGY5rvZAKCKbUDKQAsrJCuAVNNFOnOf2Q=.77555de2-8eca-4528-a37d-ca4a353bc630@github.com>

On Mon, 21 Aug 2023 03:50:35 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> > Are you inclined to re-instantiate the old behavior ?
>>> 
>>> May I ask what the "old behavior" do you mean? Thanks!
>> 
>> Hi @XiaohongGong ,
>> Updated my previous comment, I am able reproduce an intermittent crash in another test "compiler/valhalla/inlinetypes/TestGetfieldChains.java" with additional JVM options :  "-Xbatch -XX:TieredStopAtLevel=1 -XX:CompileThresholdScaling=0.1 -XX:InlineFieldMaxFlatSize=0"
>> [hs_err_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385038/hs_err_pid1570004.txt)
>> [replay_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385039/replay_pid1570004.txt)
>> [TestGetfieldChains.txt](https://github.com/openjdk/valhalla/files/12385040/TestGetfieldChains.txt)
>> 
>> Please find attached relevant logs and replay file.
>> 
>> Best Regards,
>> Jatin
>
>> > > Are you inclined to re-instantiate the old behavior ?
>> > 
>> > 
>> > May I ask what the "old behavior" do you mean? Thanks!
>> 
>> Hi @XiaohongGong , Updated my previous comment, I am able reproduce an intermittent crash in another test "compiler/valhalla/inlinetypes/TestGetfieldChains.java" with additional JVM options : "-Xbatch -XX:TieredStopAtLevel=1 -XX:CompileThresholdScaling=0.1 -XX:InlineFieldMaxFlatSize=0" [hs_err_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385038/hs_err_pid1570004.txt) [replay_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385039/replay_pid1570004.txt) [TestGetfieldChains.txt](https://github.com/openjdk/valhalla/files/12385040/TestGetfieldChains.txt)
>> 
>> Please find attached relevant logs and replay file.
>> 
>> Best Regards, Jatin
> 
> Thanks for pointing out this! I can reproduce this issue after I rebase my patch to latest `lworld` branch. I will try my best to look at what is changed. 
> 
> Best Regards,
> Xiaohong

> Hi @XiaohongGong,
> 
> > I think there maybe some potential issues exposed after this change, since almost all value objects cannot be flattened anymore with -XX:InlineFieldMaxFlatSize=0, which may need the buffer allocated.
> 
> Yes, I think it's likely that this change reveals some existing issues. I can help with debugging but only later next month.

That's great! Thanks so much for your help!

> > Could you please show more env/options information on this issue? I cannot reproduce it even with -XX:InlineFieldMaxFlatSize=0 -XX:TieredStopAtLevel=1 on our internal Arm NEON machine.
> 
> It fails quite reliable in our testing on x86_64 with one of the following flag combinations:
> 
> * `-Xcomp -XX:TieredStopAtLevel=1 -DIgnoreCompilerControls=true`
> * `-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true`
> * `-DWarmup=0 -DVerifyIR=false`
> * `-DWarmup=0 -XX:TieredStopAtLevel=1`
> 
> But you can reproduce this now, right?

Yes, I can reproduce now. The failure is randomly that the test can pass sometimes on my ARM system. I'm currently working on looking at this issue, but not too much progress now. 

> > Actually I don't quite understand what this assertion mean? Why the null_free value type must be allocated in this routine?
> 
> The `is_allocated` assertion checks that the InlineTypeNode should always have a valid oop to a heap buffer now that we just loaded it from an oop value. That's not guaranteed if the field/argument can be NULL though, that's why the assert checks for `!null_free`. Does that make sense?

Yes, make sense to me. Thanks a lot for the explanation!

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1689462194


From xgong at openjdk.org  Wed Aug 23 09:25:15 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 23 Aug 2023 09:25:15 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups. [v2]
In-Reply-To: <qHfpOSkPmnN4zxpXo3oxF5VhbFJBngtYMCpCkUdbdy0=.3878d7bb-a82b-4a68-9c9c-1bf4f445e89a@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
 <qHfpOSkPmnN4zxpXo3oxF5VhbFJBngtYMCpCkUdbdy0=.3878d7bb-a82b-4a68-9c9c-1bf4f445e89a@github.com>
Message-ID: <6F586-odyQQzvugyWcuRvza742W-Jum_Eumb3twiS6g=.cb82fae3-9b06-40aa-9e86-d6405c975568@github.com>

On Wed, 23 Aug 2023 03:30:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch fixes following problem seen during validation:-
>> 
>> **CDS:-**
>> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
>> 
>> **VM:-**
>> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
>> 
>> **ci Model:-**
>> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
>> 
>> **C1 compiler:-**
>> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
>> 
>> **C2 compiler:-**
>> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
>> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
>> 
>>>     vt = newPayload();
>>>     vt = Unsafe.makePrivateBuffer(vt);
>>>     for (int i = 0; i < Double128.length; i++) {
>>>          if (mask[i]) {
>>>               Unsafe.putDouble(vt, apply(src[i]));
>>>          }
>>>     }
>> 
>>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
>> 
>> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
>> 
>> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to ...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

Generally looks good to me! Thanks!

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

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/909#pullrequestreview-1590859495


From thartmann at openjdk.org  Wed Aug 23 09:25:02 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 23 Aug 2023 09:25:02 GMT
Subject: [lworld] RFR: 8311219: [lworld] VM option "InlineFieldMaxFlatSize"
 cannot work well
In-Reply-To: <tRsCa73tYMEI_bqqj8Ihf6D-B1elob_wMlvRXMH1HZ8=.e9a0a449-349a-4a8e-8a9d-f6f5022e36a5@github.com>
References: <5QNYV-nUYCE-Uzrsz81TwXroTK6x-aDxA4b8B1Svfto=.8e61ef68-a35e-4a92-9338-39ac4c083b2b@github.com>
 <R96zCHct48J7QBHScv5fakm2UxYu7_UYtVofsTR7K1k=.38b1b2a1-a221-4b3e-9c19-c0e82a388f4c@github.com>
 <g1EoNKZz_ehyAwrh3vMZB-rgjeRQsy4159yqLvxv7is=.c118e83b-b014-462f-9e9d-1450fdfcedd4@github.com>
 <FXe-ZEJwftCcEiBYV85DoHLd_-paNluIkeoo0BkHBHE=.dae10d31-fc5e-40be-ac05-98915a1cc5d7@github.com>
 <T_wvoaZ1MxwGKMObRy1HZ9t1RzcgpHW5OQ3ccQoVnkY=.1e8e933c-0137-4c4f-9159-9f61fc599f03@github.com>
 <Pbo5yW7MoFyfLCDFq-UUcJ_3wm_xqCnju-Y-AmhQjSs=.dc9a79fe-4ec1-4257-bdef-7495943ae562@github.com>
 <qpDyBhRfCyJc9LFJEQ1mvO4llycuJqgvrGbBTBLbbQQ=.18d0a66a-8804-42a4-8767-fe1a3fbbfafb@github.com>
 <13Toexb0NM-WYizAXfLLZiAhvDNMLjeySOLID5JyH6k=.90081b8f-fc73-4f1d-9d27-a0c5200da8d9@github.com>
 <tRsCa73tYMEI_bqqj8Ihf6D-B1elob_wMlvRXMH1HZ8=.e9a0a449-349a-4a8e-8a9d-f6f5022e36a5@github.com>
Message-ID: <qac6mY3gfd05XxkmfjHHS0XYhAGIgb36x9ARKx34Kjw=.a7ca7b95-f6a8-4ace-b780-92d4714262ba@github.com>

On Mon, 21 Aug 2023 03:50:35 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> > Are you inclined to re-instantiate the old behavior ?
>>> 
>>> May I ask what the "old behavior" do you mean? Thanks!
>> 
>> Hi @XiaohongGong ,
>> Updated my previous comment, I am able reproduce an intermittent crash in another test "compiler/valhalla/inlinetypes/TestGetfieldChains.java" with additional JVM options :  "-Xbatch -XX:TieredStopAtLevel=1 -XX:CompileThresholdScaling=0.1 -XX:InlineFieldMaxFlatSize=0"
>> [hs_err_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385038/hs_err_pid1570004.txt)
>> [replay_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385039/replay_pid1570004.txt)
>> [TestGetfieldChains.txt](https://github.com/openjdk/valhalla/files/12385040/TestGetfieldChains.txt)
>> 
>> Please find attached relevant logs and replay file.
>> 
>> Best Regards,
>> Jatin
>
>> > > Are you inclined to re-instantiate the old behavior ?
>> > 
>> > 
>> > May I ask what the "old behavior" do you mean? Thanks!
>> 
>> Hi @XiaohongGong , Updated my previous comment, I am able reproduce an intermittent crash in another test "compiler/valhalla/inlinetypes/TestGetfieldChains.java" with additional JVM options : "-Xbatch -XX:TieredStopAtLevel=1 -XX:CompileThresholdScaling=0.1 -XX:InlineFieldMaxFlatSize=0" [hs_err_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385038/hs_err_pid1570004.txt) [replay_pid1570004.txt](https://github.com/openjdk/valhalla/files/12385039/replay_pid1570004.txt) [TestGetfieldChains.txt](https://github.com/openjdk/valhalla/files/12385040/TestGetfieldChains.txt)
>> 
>> Please find attached relevant logs and replay file.
>> 
>> Best Regards, Jatin
> 
> Thanks for pointing out this! I can reproduce this issue after I rebase my patch to latest `lworld` branch. I will try my best to look at what is changed. 
> 
> Best Regards,
> Xiaohong

Hi @XiaohongGong,

> I think there maybe some potential issues exposed after this change, since almost all value objects cannot be flattened anymore with -XX:InlineFieldMaxFlatSize=0, which may need the buffer allocated.

Yes, I think it's likely that this change reveals some existing issues. I can help with debugging but only later next month.

> Could you please show more env/options information on this issue? I cannot reproduce it even with -XX:InlineFieldMaxFlatSize=0 -XX:TieredStopAtLevel=1 on our internal Arm NEON machine.

It fails quite reliable in our testing on x86_64 with one of the following flag combinations:
- `-Xcomp -XX:TieredStopAtLevel=1 -DIgnoreCompilerControls=true`
- `-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true`
- `-DWarmup=0 -DVerifyIR=false`
- `-DWarmup=0 -XX:TieredStopAtLevel=1`

But you can reproduce this now, right?

> Actually I don't quite understand what this assertion mean? Why the null_free value type must be allocated in this routine?

The `is_allocated` assertion checks that the InlineTypeNode should always have a valid oop to a heap buffer now that we just loaded it from an oop value. That's not guaranteed if the field/argument can be NULL though, that's why the assert checks for `!null_free`. Does that make sense?

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

PR Comment: https://git.openjdk.org/valhalla/pull/888#issuecomment-1689445893


From dsimms at openjdk.org  Wed Aug 23 16:54:57 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 23 Aug 2023 16:54:57 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <WaNIaMj7Rc5w4Epde0fF6C2EGnCHJ4A84-R9mjKwla8=.a8b0045c-d134-45c6-a998-12a454405a57@github.com>

Merge jdk-22+7

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

Commit messages:
 - Fixed merge of JDK-8287061
 - Logical merge issues
 - Merge tag 'jdk-22+7' into lworld_merge_jdk_22_7
 - 8311663: Additional refactoring of Locale tests to JUnit
 - 8311879: SA ClassWriter generates invalid invokedynamic code
 - 8312014: [s390x] TestSigInfoInHsErrFile.java Failure
 - 8312164: Refactor Arrays.hashCode for long, boolean, double, float, and Object arrays
 - 8302987: Add uniform and spatially equidistributed bounded double streams to RandomGenerator
 - 8312392: ARM32 build broken since 8311035
 - 8311971: SA's ConstantPool.java uses incorrect computation to read long value in the constant pool
 - ... and 94 more: https://git.openjdk.org/valhalla/compare/cf95308c...8601e6d0

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

Changes: https://git.openjdk.org/valhalla/pull/911/files
  Stats: 23263 lines in 717 files changed: 14382 ins; 7321 del; 1560 mod
  Patch: https://git.openjdk.org/valhalla/pull/911.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/911/head:pull/911

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


From vromero at openjdk.org  Wed Aug 23 20:19:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 23 Aug 2023 20:19:53 GMT
Subject: Integrated: Merge lworld
Message-ID: <_gdBhVTMR4Ndizn6HDmSwmwFs4dmxMY8OXzBbIvPKUc=.1b530919-7b91-4487-baa2-75647c181ca0@github.com>

Merge branch 'lworld' into lw5_merge_lworld

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - 8314181: [lw5] the check for illegal circularity should only be done if value classes are available
 - 8314165: [lw5] check for illegal circularity at class loading time
 - Merge lworld
 - [lw5] regression test cleanup, relocation
 - [lw5] fixing bugs on experimental code to generate Q-descriptors, plus code refactoring
 - [lw5] experiment: reusing primitive class tests to generate Q descriptors
 - Merge lworld
 - experiment: generate Q descriptors for lw5 code
 - 8313080: [lw5] javac parser is not accepting some array types with nullness markers
 - ... and 13 more: https://git.openjdk.org/valhalla/compare/9ceb30ba...875ef365

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

Changes: https://git.openjdk.org/valhalla/pull/912/files
  Stats: 6239 lines in 239 files changed: 3507 ins; 1753 del; 979 mod
  Patch: https://git.openjdk.org/valhalla/pull/912.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/912/head:pull/912

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


From vromero at openjdk.org  Wed Aug 23 20:19:54 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 23 Aug 2023 20:19:54 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <_gdBhVTMR4Ndizn6HDmSwmwFs4dmxMY8OXzBbIvPKUc=.1b530919-7b91-4487-baa2-75647c181ca0@github.com>
References: <_gdBhVTMR4Ndizn6HDmSwmwFs4dmxMY8OXzBbIvPKUc=.1b530919-7b91-4487-baa2-75647c181ca0@github.com>
Message-ID: <9Qd3VmjapnMMDMhwcCkvsSBlIj-9eefkbGWWU0tLx-k=.b88b8040-00e5-4f86-bd63-1153bdc4ff8f@github.com>

On Wed, 23 Aug 2023 20:13:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld

This pull request has now been integrated.

Changeset: 1a46d1ca
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1a46d1ca7c78f358e2a0fcd2d7acc104010c7cac
Stats:     63106 lines in 1006 files changed: 11744 ins; 45976 del; 5386 mod

Merge lworld

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

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


From vromero at openjdk.org  Thu Aug 24 00:32:16 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Aug 2023 00:32:16 GMT
Subject: Integrated: 8314899: [lw5] rename j.l.NonAtomic to
 j.l.LooselyConsistentValue
Message-ID: <F6-72eqNNHHnKBus0OAzkHLESiU9P1fjYSbbvl6GojQ=.799e197c-c9bb-4c07-9049-d4b656675e3f@github.com>

simple refactoring

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

Commit messages:
 - 8314899: [lw5] rename j.l.NonAtomic to j.l.LooselyConsistentValue

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

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


From vromero at openjdk.org  Thu Aug 24 00:32:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 24 Aug 2023 00:32:17 GMT
Subject: Integrated: 8314899: [lw5] rename j.l.NonAtomic to
 j.l.LooselyConsistentValue
In-Reply-To: <F6-72eqNNHHnKBus0OAzkHLESiU9P1fjYSbbvl6GojQ=.799e197c-c9bb-4c07-9049-d4b656675e3f@github.com>
References: <F6-72eqNNHHnKBus0OAzkHLESiU9P1fjYSbbvl6GojQ=.799e197c-c9bb-4c07-9049-d4b656675e3f@github.com>
Message-ID: <PCRSocB8wlmIRyml228bvbZx_Qui30NTfQcwxk_UNpQ=.83c613a8-1de2-454b-a3d0-b40091dacdc0@github.com>

On Thu, 24 Aug 2023 00:23:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> simple refactoring

This pull request has now been integrated.

Changeset: 48e680c6
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/48e680c62f84121a49adb187e1cf7f6af41e917c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8314899: [lw5] rename j.l.NonAtomic to j.l.LooselyConsistentValue

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

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


From jbhateja at openjdk.org  Thu Aug 24 05:20:53 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Aug 2023 05:20:53 GMT
Subject: [lworld+vector] RFR: 8314628: [lworld+vector] validation
 regression fixes and cleanups. [v2]
In-Reply-To: <GU7QiCEIK4pLfX27tiJajEo7nNB3CQq3srSEY-XSiWo=.619f0321-7cdb-48ae-b528-c399de4ee507@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
 <9zhfXh5pXSfArhD8cu-DwoYQ8cO6BRm6SqVSoUrZdz0=.c5e674a5-06c8-4acc-b34e-77b6b2bc40da@github.com>
 <NSUbb8Eonk5jiOnETtfA4W4H5nlFO-CksyY3C3TcpaU=.67fb0f58-eaea-4dfd-8d86-330d676acd8a@github.com>
 <GU7QiCEIK4pLfX27tiJajEo7nNB3CQq3srSEY-XSiWo=.619f0321-7cdb-48ae-b528-c399de4ee507@github.com>
Message-ID: <ms30F9obJDFBJRb5RG6kk4jkd91CpveYIt0T-QGNPPc=.3bf2a268-c709-46eb-abc9-5db2bc84e31d@github.com>

On Wed, 23 Aug 2023 01:42:34 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> I am planning to use these symbol definitions in Max species support, estimation of multifield bundle size for max species cannot be just done based on MaxVectorSize, e.g., both LongMaxMask and ByteMaxMask will encapsulate VectorPayloadMFMaxZ which will hold @multifield(-1) annotated boolean mfield.
>> 
>> In order to determine the bundle size, we need to resort to VM symbol name comparison during field parsing, payload class names should also be different for Byte and Long max species mask e.g. VectorPayloadMFMaxZL and VectorPayLoadMFMaxZB. Bundle size for Long should be 8 while for Byte should be 64 for 512-bit MaxVectorSize.
>
> I also spent some time looking at this part. It's true that we have to distingunish the max lanecount for different types of VectorMask. As for this part, maybe we could also extend the `MultiField` annotation by adding another variable denotaing the type info like `esize/scale`. And calculate the right lanecount based on the `MaxVectorSize` and `esize/scale` when parsing classfile. WDYT?

Even if we extend @multifield annotation to pass an explicit lane size, we still need to create separate Java classes for different Max species mask payloads e.g. VectorPayloadMaxLZ, VectorPayloadMaxBZ. In usual scenario field type is known to parser and sufficient to determine its size, only bundle width is passed explicitly. Its only for MaxSpecies where bundle size is dependent on MaxVectorSize we may need to do a symbol comparison, but your suggestion looks good and may save costly symbol lookup.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1303813621


From jbhateja at openjdk.org  Thu Aug 24 05:58:50 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Aug 2023 05:58:50 GMT
Subject: [lworld+vector] Integrated: 8314628: [lworld+vector] validation
 regression fixes and cleanups.
In-Reply-To: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
References: <xkxEzWloZQtTUSNZk40bs_xMeU-tE9Con9osCdozWaM=.581368c3-69d6-41f5-b0de-2693755c4a48@github.com>
Message-ID: <wSt9_FtqK_LoiwiJnK9D02ZOnHRvcqEFD3D0dvDOZdo=.ed71bb40-e5d5-41df-8112-fa9753234f56@github.com>

On Mon, 21 Aug 2023 07:36:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Patch fixes following problem seen during validation:-
> 
> **CDS:-**
> - Problem while restoring value object mirrors. These are needed to perform class level comparisons.
> 
> **VM:-**
> - Remove payload offset computation logic during VM initialization. It was earlier used during object re-materialization.
> 
> **ci Model:-**
> - Add a generic routine to handle synthetic ciField population for both static and non-static multifield. This enables returning fully populated ciMultiField structure to compilers during parsing.
> 
> **C1 compiler:-**
> - Incorrect address displacement computation in HIR while updating multifield bundle using "withfield" bytecode in VectorPayalod constructor. This was causing  failures in Double128Mask tests.
> 
> **C2 compiler:-**
> 1.  Allow vector IR creation under strict check for multifield in default_value creation routine. This was incorrectly creating vector IR for non-vector API tests for Double/Long types.
> 2. Disable inline expansion of Unsafe.finishPrivateBuffer.  This is fixing the incorrectness problems seen with masked operations loop e.g.
> 
>>     vt = newPayload();
>>     vt = Unsafe.makePrivateBuffer(vt);
>>     for (int i = 0; i < Double128.length; i++) {
>>          if (mask[i]) {
>>               Unsafe.putDouble(vt, apply(src[i]));
>>          }
>>     }
> 
>    Unsafe.putDouble() only modifies the memory state by storing a new value in payload buffer but does not update any local variable in the JVM state corresponding to latch block. Thus no inductive Phi node is inserted in the loop, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.
> 
> 3. With non-incremental in-lining (-XX:-IncrementalInline) flow user defined routines returning a vector object is incorrectly returning uninitialized VBA connected to oop input of InlineType IR. Defer returning VectorBoxAllocation node, they are expanded and initialized during box expansion and replaces all uses of box.
> 
> 4. Currently we try to sharpen the object type to a narrower type to optimize object type comparison against a class constant. This is achieved by inserting a CheckCastPP node which casts the object type to a higher speculative type, if cast type is an inlinetyp...

This pull request has now been integrated.

Changeset: c073a2fd
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c073a2fdd938b022c5cda560b201dabec9df1748
Stats:     177 lines in 18 files changed: 103 ins; 41 del; 33 mod

8314628: [lworld+vector] validation regression fixes and cleanups.

Reviewed-by: xgong

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

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


From dsimms at openjdk.org  Thu Aug 24 06:40:39 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 24 Aug 2023 06:40:39 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <WaNIaMj7Rc5w4Epde0fF6C2EGnCHJ4A84-R9mjKwla8=.a8b0045c-d134-45c6-a998-12a454405a57@github.com>
References: <WaNIaMj7Rc5w4Epde0fF6C2EGnCHJ4A84-R9mjKwla8=.a8b0045c-d134-45c6-a998-12a454405a57@github.com>
Message-ID: <mKI_s8vr3p1SRTGG6BGTU2JZpXeBWG11clKNG7XtCSE=.9b80cce6-ef2a-455c-8df9-b68106890980@github.com>

> Merge jdk-22+7

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Problem list 8314923

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/911/files
  - new: https://git.openjdk.org/valhalla/pull/911/files/8601e6d0..0adf40bd

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

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

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


From dsimms at openjdk.org  Thu Aug 24 06:42:58 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 24 Aug 2023 06:42:58 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <WaNIaMj7Rc5w4Epde0fF6C2EGnCHJ4A84-R9mjKwla8=.a8b0045c-d134-45c6-a998-12a454405a57@github.com>
References: <WaNIaMj7Rc5w4Epde0fF6C2EGnCHJ4A84-R9mjKwla8=.a8b0045c-d134-45c6-a998-12a454405a57@github.com>
Message-ID: <mYXcHCqVXjJB3EpOrENkDXR7uS-fe7kCWRCJsB9PjW4=.54430a87-9731-4d98-b738-e892e42bbc07@github.com>

On Wed, 23 Aug 2023 16:44:18 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+7

This pull request has now been integrated.

Changeset: 8bdf6240
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8bdf624019dbefa7d2fa583f306f72862b3c4629
Stats:     23264 lines in 717 files changed: 14383 ins; 7321 del; 1560 mod

Merge jdk

Merge jdk-22+7

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

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


From xgong at openjdk.org  Thu Aug 24 08:43:02 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 24 Aug 2023 08:43:02 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16
 scalar operations. [v4]
In-Reply-To: <6ZtznppSDRnEjZObGHyEyFdvbfXr1TQvklL45bwFmPg=.bf3fc04d-e2d3-4a1a-9c91-925d7fbfcb5c@github.com>
References: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
 <6ZtznppSDRnEjZObGHyEyFdvbfXr1TQvklL45bwFmPg=.bf3fc04d-e2d3-4a1a-9c91-925d7fbfcb5c@github.com>
Message-ID: <0eCZlRS1h6dj4OMBsQQ-OYbEv1XnXx9vBnlwyrqecOA=.f1934680-ef7f-4719-a539-e4a9d6f458e8@github.com>

On Fri, 18 Aug 2023 18:56:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Starting with 4th Generation Xeon, Intel has made extensive extensions to existing ISA to support 16 bit scalar and vector floating point operations based on IEEE 754 binary16 format.
>> 
>> We plan to support this in multiple stages spanning across Java side definition of Float16 type, scalar operation and finally SLP vectorization support.
>> 
>> This patch adds  minimal Java and Compiler side support for one API Float16.add.
>> 
>> **Summary of changes :-**
>> - Minimal implementation of Float16 primitive class supporting one operation (Float16.add)
>> - X86 AVX512-FP16 feature detection at VM startup.
>> - C2 IR and Inline expander changes for Float16.add API.
>> - FP16 constant folding handling.
>> - Backend support : Instruction selection patterns and assembler support.
>> - New IR framework and functional tests.
>> 
>> **Implementation details:-**
>> 
>> 1/ Newly defined Float16 class encapsulate a short value holding IEEE 754 binary16 encoded value.
>> 
>> 2/ Float16 is a primitive class which in future will be aligned with other enhanced primitive wrapper classes proposed by [JEP-402.](https://openjdk.org/jeps/402)
>> 
>> 3/ Float16 to support all the operations supported by corresponding Float class.
>> 
>> 4/ Java implementation of each API will internally perform floating point operation at FP32 granularity.
>> 
>> 5/ API which can be directly mapped to an Intel AVX512FP16 instruction will be a candidate for intensification by C2 compiler.
>> 
>> 6/ With Valhalla, C2 compiler always creates an InlineType IR node for a value class instance.
>> Total number of inputs of an InlineType node match the number of non-static fields. In this case node will have one input of short type TypeInt::SHORT.
>> 
>> 7/ Since all the scalar AVX512FP16 instructions operate on floating point registers and Float16 backing storage is held in a general-purpose register hence we need to introduce appropriate conversion IR which moves a 16-bit value from GPR to a XMM register and vice versa.
>> ![image](https://github.com/openjdk/valhalla/assets/59989778/192fca7e-6b7e-4e62-9b09-677e33eca48d)
>> 
>> 8/ Current plan is to introduce a new IR node for each operation which is a subclass of its corresponding single precision IR node. This will allow leveraging idealization routines (Ideal/Identity/Value) of its parent operation.
>> 
>> 9/ All the single/double precision IR nodes carry a Type::FLOAT/DOUBLE ideal type. This represents entire FP32/64 value range and is different from integral types which expli...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing offline review comments from Sandhya, new IR test addition.

src/hotspot/share/classfile/classFileParser.cpp line 5176:

> 5174:       // Can't enable this check fully until JDK upgrades the bytecode generators (TODO: JDK-8270852).
> 5175:       // For now, compare to class file version 51 so old verifier doesn't see Q signatures.
> 5176:       if ( (_major_version < 51 /* CONSTANT_CLASS_DESCRIPTORS */ ) || (!EnablePrimitiveClasses && !is_jdk_internal_class_sig(signature))) {

The last condition `(!EnablePrimitiveClasses && !is_jdk_internal_class_sig(signature))` seems not right to me. Assume there is a jdk internal primitive class defined , and `EnablePrimitiveClasses` is disabled, then result of `(!EnablePrimitiveClasses && !is_jdk_internal_class_sig(signature))` is `false` (i.e. `true && false`), then the followed error is not printed if the jdk version matches >= 51. But it should report the error since `EnablePrimitiveClasses` is closed.  So it should be:

if ( (_major_version < 51 /* CONSTANT_CLASS_DESCRIPTORS */ ) || !EnablePrimitiveClasses || !is_jdk_internal_class_sig(signature))

right?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/848#discussion_r1303999255


From xgong at openjdk.org  Thu Aug 24 08:53:48 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 24 Aug 2023 08:53:48 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16
 scalar operations. [v4]
In-Reply-To: <6ZtznppSDRnEjZObGHyEyFdvbfXr1TQvklL45bwFmPg=.bf3fc04d-e2d3-4a1a-9c91-925d7fbfcb5c@github.com>
References: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
 <6ZtznppSDRnEjZObGHyEyFdvbfXr1TQvklL45bwFmPg=.bf3fc04d-e2d3-4a1a-9c91-925d7fbfcb5c@github.com>
Message-ID: <Q7ASueGmVrSGSCN3Ue4N0DtVZPswpKjQ-2IxgklfBTk=.6a48cf64-cac0-48b4-8823-73ec1de90a58@github.com>

On Fri, 18 Aug 2023 18:56:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Starting with 4th Generation Xeon, Intel has made extensive extensions to existing ISA to support 16 bit scalar and vector floating point operations based on IEEE 754 binary16 format.
>> 
>> We plan to support this in multiple stages spanning across Java side definition of Float16 type, scalar operation and finally SLP vectorization support.
>> 
>> This patch adds  minimal Java and Compiler side support for one API Float16.add.
>> 
>> **Summary of changes :-**
>> - Minimal implementation of Float16 primitive class supporting one operation (Float16.add)
>> - X86 AVX512-FP16 feature detection at VM startup.
>> - C2 IR and Inline expander changes for Float16.add API.
>> - FP16 constant folding handling.
>> - Backend support : Instruction selection patterns and assembler support.
>> - New IR framework and functional tests.
>> 
>> **Implementation details:-**
>> 
>> 1/ Newly defined Float16 class encapsulate a short value holding IEEE 754 binary16 encoded value.
>> 
>> 2/ Float16 is a primitive class which in future will be aligned with other enhanced primitive wrapper classes proposed by [JEP-402.](https://openjdk.org/jeps/402)
>> 
>> 3/ Float16 to support all the operations supported by corresponding Float class.
>> 
>> 4/ Java implementation of each API will internally perform floating point operation at FP32 granularity.
>> 
>> 5/ API which can be directly mapped to an Intel AVX512FP16 instruction will be a candidate for intensification by C2 compiler.
>> 
>> 6/ With Valhalla, C2 compiler always creates an InlineType IR node for a value class instance.
>> Total number of inputs of an InlineType node match the number of non-static fields. In this case node will have one input of short type TypeInt::SHORT.
>> 
>> 7/ Since all the scalar AVX512FP16 instructions operate on floating point registers and Float16 backing storage is held in a general-purpose register hence we need to introduce appropriate conversion IR which moves a 16-bit value from GPR to a XMM register and vice versa.
>> ![image](https://github.com/openjdk/valhalla/assets/59989778/192fca7e-6b7e-4e62-9b09-677e33eca48d)
>> 
>> 8/ Current plan is to introduce a new IR node for each operation which is a subclass of its corresponding single precision IR node. This will allow leveraging idealization routines (Ideal/Identity/Value) of its parent operation.
>> 
>> 9/ All the single/double precision IR nodes carry a Type::FLOAT/DOUBLE ideal type. This represents entire FP32/64 value range and is different from integral types which expli...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing offline review comments from Sandhya, new IR test addition.

src/hotspot/share/classfile/vmIntrinsics.hpp line 201:

> 199:   /* Float16 intrinsics, similar to what we have in Math. */                                                            \
> 200:   do_intrinsic(_add_float16,              java_lang_Float16,      add_name,           floa16_float16_signature,  F_R)   \
> 201:    do_name(add_name,    "add")                                                                                          \

style: please remove extra spaces between `add_name` and `"add"`.

src/hotspot/share/opto/addnode.hpp line 133:

> 131: 
> 132: //------------------------------AddHFNode---------------------------------------
> 133: // Add 2 floats

Change to: `Add 2 half-precision floats` ?

src/hotspot/share/opto/convertnode.hpp line 179:

> 177: class ReinterpretS2HFNode : public Node {
> 178:   public:
> 179:   ReinterpretS2HFNode( Node *in1 ) : Node(0,in1) {}

Suggest changes:

ReinterpretS2HFNode(Node* in1) : Node(0, in1) {}

src/hotspot/share/opto/convertnode.hpp line 181:

> 179:   ReinterpretS2HFNode( Node *in1 ) : Node(0,in1) {}
> 180:   virtual int Opcode() const;
> 181:   virtual const Type *bottom_type() const { return Type::FLOAT; }

Suggest to:

virtual const Type* bottom_type() const { return Type::FLOAT; }

src/hotspot/share/opto/convertnode.hpp line 191:

> 189:   virtual int Opcode() const;
> 190:   virtual const Type* Value(PhaseGVN* phase) const;
> 191:   virtual const Type *bottom_type() const { return TypeInt::SHORT; }

Same as above.

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

> 4792: 
> 4793: bool LibraryCallKit::inline_fp16_operations(vmIntrinsics::ID id) {
> 4794:   Node* result = NULL;

Please use `nullptr` instead of `NULL`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/848#discussion_r1304001891
PR Review Comment: https://git.openjdk.org/valhalla/pull/848#discussion_r1304004451
PR Review Comment: https://git.openjdk.org/valhalla/pull/848#discussion_r1304009240
PR Review Comment: https://git.openjdk.org/valhalla/pull/848#discussion_r1304009952
PR Review Comment: https://git.openjdk.org/valhalla/pull/848#discussion_r1304010260
PR Review Comment: https://git.openjdk.org/valhalla/pull/848#discussion_r1304012865


From dsimms at openjdk.org  Thu Aug 24 18:08:03 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 24 Aug 2023 18:08:03 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <xvA6n1UKSz5RXCyhiyciMvBgfAQd2TAucRZ1PAWdECU=.47370920-6ff3-44c8-a15e-e25ddbe9753d@github.com>

Merge jdk-22+8

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

Commit messages:
 - Missing ACC_IDENTITY in classfile generation
 - Merge tag 'jdk-22+8' into lworld_merge_jdk_22_8
 - 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074
 - 8309088: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails
 - 8313087: DerValue::toString should output a hex view of the values in byte array
 - 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec
 - 8313155: Problem list some JUnit-based tests in test/jdk/java/lang/invoke
 - 8312445: Array types in annotation elements show square brackets twice
 - 8312526: Test dk/jfr/event/oldobject/TestHeapDeep.java failed: Could not find ChainNode
 - 8312619: Strange error message when switching over long
 - ... and 61 more: https://git.openjdk.org/valhalla/compare/8bdf6240...f471ecdb

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

Changes: https://git.openjdk.org/valhalla/pull/915/files
  Stats: 24361 lines in 417 files changed: 11704 ins; 10802 del; 1855 mod
  Patch: https://git.openjdk.org/valhalla/pull/915.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/915/head:pull/915

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


From vromero at openjdk.org  Fri Aug 25 01:29:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Aug 2023 01:29:05 GMT
Subject: Integrated: 8314913: [lw5] null restrictions can only be applied to
 value classes
Message-ID: <F6V2nyoTmD6J-SrNnGhdny-Alj02JQ2NcTNcysLM0og=.c4255124-a512-4149-89a8-bb6458e38c18@github.com>

according to last iteration of the spec null restrictions can only be applied to value classes that declares an implicit constructor

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

Commit messages:
 - Update ValueObjectCompilationTests.java
 - 8314913: [lw5] null restrictions can only be applied to value classes

Changes: https://git.openjdk.org/valhalla/pull/916/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=916&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314913
  Stats: 214 lines in 14 files changed: 80 ins; 34 del; 100 mod
  Patch: https://git.openjdk.org/valhalla/pull/916.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/916/head:pull/916

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


From vromero at openjdk.org  Fri Aug 25 01:29:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Aug 2023 01:29:06 GMT
Subject: Integrated: 8314913: [lw5] null restrictions can only be applied to
 value classes
In-Reply-To: <F6V2nyoTmD6J-SrNnGhdny-Alj02JQ2NcTNcysLM0og=.c4255124-a512-4149-89a8-bb6458e38c18@github.com>
References: <F6V2nyoTmD6J-SrNnGhdny-Alj02JQ2NcTNcysLM0og=.c4255124-a512-4149-89a8-bb6458e38c18@github.com>
Message-ID: <OBb7EQdh-_00RaHY0gtuYgk48U2OhLxyCCxM5h81gQI=.c8c6994f-a99f-4a54-bf86-70cf330654a2@github.com>

On Fri, 25 Aug 2023 01:16:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> according to last iteration of the spec null restrictions can only be applied to value classes that declares an implicit constructor

This pull request has now been integrated.

Changeset: 96b0eba3
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/96b0eba3f0ecd62d9eaac69fd3b98b91a996b23d
Stats:     214 lines in 14 files changed: 80 ins; 34 del; 100 mod

8314913: [lw5] null restrictions can only be applied to value classes

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

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


From vromero at openjdk.org  Fri Aug 25 01:44:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Aug 2023 01:44:22 GMT
Subject: RFR: Merge lworld
Message-ID: <vt6OVKwpDdQ6xtnamA1wtN3by--Zq-HZK9ogk6LKL5g=.65e9b58b-f473-4120-9644-e4a5de323c98@github.com>

Merge branch 'lworld' into lw5_merge_lworld

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - Merge jdk
 - 8311663: Additional refactoring of Locale tests to JUnit
 - 8311879: SA ClassWriter generates invalid invokedynamic code
 - 8312014: [s390x] TestSigInfoInHsErrFile.java Failure
 - 8312164: Refactor Arrays.hashCode for long, boolean, double, float, and Object arrays
 - 8302987: Add uniform and spatially equidistributed bounded double streams to RandomGenerator
 - 8312392: ARM32 build broken since 8311035
 - 8311971: SA's ConstantPool.java uses incorrect computation to read long value in the constant pool
 - 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive
 - ... and 93 more: https://git.openjdk.org/valhalla/compare/96b0eba3...96edb016

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

Changes: https://git.openjdk.org/valhalla/pull/917/files
  Stats: 23264 lines in 717 files changed: 14383 ins; 7321 del; 1560 mod
  Patch: https://git.openjdk.org/valhalla/pull/917.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/917/head:pull/917

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


From vromero at openjdk.org  Fri Aug 25 03:31:30 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Aug 2023 03:31:30 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <vt6OVKwpDdQ6xtnamA1wtN3by--Zq-HZK9ogk6LKL5g=.65e9b58b-f473-4120-9644-e4a5de323c98@github.com>
References: <vt6OVKwpDdQ6xtnamA1wtN3by--Zq-HZK9ogk6LKL5g=.65e9b58b-f473-4120-9644-e4a5de323c98@github.com>
Message-ID: <5X8QhTLxgJsHBTGZB7K1eysBcARcsH9-Y7aZCSHdGZY=.0e879b02-1c67-4634-a23c-bfe9ad62436e@github.com>

> Merge branch 'lworld' into lw5_merge_lworld

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

  fixing failing tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/917/files
  - new: https://git.openjdk.org/valhalla/pull/917/files/96edb016..66f273e4

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

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

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


From vromero at openjdk.org  Fri Aug 25 03:31:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 25 Aug 2023 03:31:32 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <vt6OVKwpDdQ6xtnamA1wtN3by--Zq-HZK9ogk6LKL5g=.65e9b58b-f473-4120-9644-e4a5de323c98@github.com>
References: <vt6OVKwpDdQ6xtnamA1wtN3by--Zq-HZK9ogk6LKL5g=.65e9b58b-f473-4120-9644-e4a5de323c98@github.com>
Message-ID: <bK2YB95OZktKJhaLyt_kF-OgggbW1Myeu5-7DHe3W74=.82cbc8b5-ce22-4074-8590-03be094a8ed4@github.com>

On Fri, 25 Aug 2023 01:35:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld

This pull request has now been integrated.

Changeset: 33347992
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/333479928aa3b98b48a355835807e4f4fcbf90e4
Stats:     23285 lines in 722 files changed: 14383 ins; 7325 del; 1577 mod

Merge lworld

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

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


From jbhateja at openjdk.org  Fri Aug 25 05:04:39 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Aug 2023 05:04:39 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider scalarization
 conditions during ciMultiField creation.
Message-ID: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>

Patch adds a new API _ciEnv::is_multifield_scalarized_, to scalarize multifield (ciField[s]) in case target vector cannot accommodate multifield bundle size, else it creates a hierarchical structure ciMultiField and expose entire multifield bundle as one field to C2 compiler.

This cleans up special handling done in C2 compiler, ci field query APIs and object reconstruction handling  at SafePoint.

Please review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - 8314980: [lworld+vector] consider scalarization conditions during ciMultiField creation.

Changes: https://git.openjdk.org/valhalla/pull/918/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=918&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314980
  Stats: 128 lines in 7 files changed: 25 ins; 70 del; 33 mod
  Patch: https://git.openjdk.org/valhalla/pull/918.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/918/head:pull/918

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


From jbhateja at openjdk.org  Fri Aug 25 05:10:04 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Aug 2023 05:10:04 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v2]
In-Reply-To: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
Message-ID: <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>

> Patch adds a new API _ciEnv::is_multifield_scalarized_, to scalarize multifield (ciField[s]) in case target vector cannot accommodate multifield bundle size, else it creates a hierarchical structure ciMultiField and expose entire multifield bundle as one field to C2 compiler.
> 
> This cleans up special handling done in C2 compiler, ci field query APIs and object reconstruction handling  at SafePoint.
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Remove unused function declaration.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/918/files
  - new: https://git.openjdk.org/valhalla/pull/918/files/08affc11..7bad3292

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

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

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


From dsimms at openjdk.org  Fri Aug 25 07:29:13 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 25 Aug 2023 07:29:13 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <xvA6n1UKSz5RXCyhiyciMvBgfAQd2TAucRZ1PAWdECU=.47370920-6ff3-44c8-a15e-e25ddbe9753d@github.com>
References: <xvA6n1UKSz5RXCyhiyciMvBgfAQd2TAucRZ1PAWdECU=.47370920-6ff3-44c8-a15e-e25ddbe9753d@github.com>
Message-ID: <oRO2emlrptA0weMkbaKZr3NCNevWSf9_eTuF2JvcOnM=.7890e233-785a-471e-8f4e-f46e6345e601@github.com>

> Merge jdk-22+8

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Adjust testing

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/915/files
  - new: https://git.openjdk.org/valhalla/pull/915/files/f471ecdb..44e6c68f

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

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

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


From dsimms at openjdk.org  Fri Aug 25 08:03:23 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 25 Aug 2023 08:03:23 GMT
Subject: [lworld] RFR: Merge jdk [v3]
In-Reply-To: <xvA6n1UKSz5RXCyhiyciMvBgfAQd2TAucRZ1PAWdECU=.47370920-6ff3-44c8-a15e-e25ddbe9753d@github.com>
References: <xvA6n1UKSz5RXCyhiyciMvBgfAQd2TAucRZ1PAWdECU=.47370920-6ff3-44c8-a15e-e25ddbe9753d@github.com>
Message-ID: <IZ3Kpt3quRgB0ts6oGyX8dX-qPqyKa-vUZG7rMSv-h0=.a2864cdb-bc01-40b6-ab7f-61e75902ef81@github.com>

> Merge jdk-22+8

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  PingPong fail on macosx only

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/915/files
  - new: https://git.openjdk.org/valhalla/pull/915/files/44e6c68f..56dea961

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

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

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


From dsimms at openjdk.org  Fri Aug 25 08:09:39 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 25 Aug 2023 08:09:39 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <xvA6n1UKSz5RXCyhiyciMvBgfAQd2TAucRZ1PAWdECU=.47370920-6ff3-44c8-a15e-e25ddbe9753d@github.com>
References: <xvA6n1UKSz5RXCyhiyciMvBgfAQd2TAucRZ1PAWdECU=.47370920-6ff3-44c8-a15e-e25ddbe9753d@github.com>
Message-ID: <bJGr6igfphB-99VRIC9-FepS1wsHbW4j-9I0qJBQMZI=.27428fc7-728c-4d3b-baf7-2d36fff3c724@github.com>

On Thu, 24 Aug 2023 18:00:04 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+8

This pull request has now been integrated.

Changeset: ae8b7dbc
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ae8b7dbc774a44ea1b9083f69e7f83b8aa72da8c
Stats:     24365 lines in 418 files changed: 11708 ins; 10802 del; 1855 mod

Merge jdk

Merge jdk-22+8

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

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


From thartmann at openjdk.org  Fri Aug 25 09:03:53 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Aug 2023 09:03:53 GMT
Subject: [lworld] RFR: 8314923: [lworld] AllocationMergesTests.java fails IR
 verification
Message-ID: <wJh6MNPTOyDmkYiy4ga6i8QbV8ObG0yMQjBpgzJFHps=.6c601bc7-52e9-48fe-b77f-f888e8ca7a0b@github.com>

The test fails due to [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) which will be fixed in mainline (see bug comments for details). I'll put a stop-the-gap-solution in Valhalla. Missing Valhalla support for [JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) (if any), will be implemented by [JDK-8315003](https://bugs.openjdk.org/browse/JDK-8315003).

Thanks,
Tobias

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

Commit messages:
 - Missing alloc array
 - 8314923: [lworld] AllocationMergesTests.java fails IR verification

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

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


From chagedorn at openjdk.org  Fri Aug 25 09:03:54 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 25 Aug 2023 09:03:54 GMT
Subject: [lworld] RFR: 8314923: [lworld] AllocationMergesTests.java fails
 IR verification
In-Reply-To: <wJh6MNPTOyDmkYiy4ga6i8QbV8ObG0yMQjBpgzJFHps=.6c601bc7-52e9-48fe-b77f-f888e8ca7a0b@github.com>
References: <wJh6MNPTOyDmkYiy4ga6i8QbV8ObG0yMQjBpgzJFHps=.6c601bc7-52e9-48fe-b77f-f888e8ca7a0b@github.com>
Message-ID: <GdPLurNSGlLfz0TdkW8zMHUqAtZ_Z_0l4kFONKNUxN0=.f07feb26-d7a6-4105-9024-b792abac29cf@github.com>

On Fri, 25 Aug 2023 08:55:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The test fails due to [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) which will be fixed in mainline (see bug comments for details). I'll put a stop-the-gap-solution in Valhalla. Missing Valhalla support for [JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) (if any), will be implemented by [JDK-8315003](https://bugs.openjdk.org/browse/JDK-8315003).
> 
> Thanks,
> Tobias

That's a reasonable temporary fix. Looks good!

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

Marked as reviewed by chagedorn (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/919#pullrequestreview-1595265334


From thartmann at openjdk.org  Fri Aug 25 09:09:32 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Aug 2023 09:09:32 GMT
Subject: [lworld] RFR: 8314923: [lworld] AllocationMergesTests.java fails
 IR verification
In-Reply-To: <wJh6MNPTOyDmkYiy4ga6i8QbV8ObG0yMQjBpgzJFHps=.6c601bc7-52e9-48fe-b77f-f888e8ca7a0b@github.com>
References: <wJh6MNPTOyDmkYiy4ga6i8QbV8ObG0yMQjBpgzJFHps=.6c601bc7-52e9-48fe-b77f-f888e8ca7a0b@github.com>
Message-ID: <OslHtXwl8aviQyjoMkSY5uatNV2RvWOxaDECE9twdGg=.ea5cbd22-0123-4090-94b7-350a3d27e591@github.com>

On Fri, 25 Aug 2023 08:55:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The test fails due to [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) which will be fixed in mainline (see bug comments for details). I'll put a stop-the-gap-solution in Valhalla. Missing Valhalla support for [JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) (if any), will be implemented by [JDK-8315003](https://bugs.openjdk.org/browse/JDK-8315003).
> 
> Thanks,
> Tobias

Thanks Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/919#issuecomment-1693030249


From thartmann at openjdk.org  Fri Aug 25 09:09:32 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Aug 2023 09:09:32 GMT
Subject: [lworld] Integrated: 8314923: [lworld] AllocationMergesTests.java
 fails IR verification
In-Reply-To: <wJh6MNPTOyDmkYiy4ga6i8QbV8ObG0yMQjBpgzJFHps=.6c601bc7-52e9-48fe-b77f-f888e8ca7a0b@github.com>
References: <wJh6MNPTOyDmkYiy4ga6i8QbV8ObG0yMQjBpgzJFHps=.6c601bc7-52e9-48fe-b77f-f888e8ca7a0b@github.com>
Message-ID: <A5D1JmgA5IWLJIYS_fh8z5S0Z3P6RDMEhCxj3fa3PbI=.6878938d-32c5-4b7b-b99c-55e586e0aa5c@github.com>

On Fri, 25 Aug 2023 08:55:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The test fails due to [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) which will be fixed in mainline (see bug comments for details). I'll put a stop-the-gap-solution in Valhalla. Missing Valhalla support for [JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) (if any), will be implemented by [JDK-8315003](https://bugs.openjdk.org/browse/JDK-8315003).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8314923: [lworld] AllocationMergesTests.java fails IR verification

Reviewed-by: chagedorn

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

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


From xgong at openjdk.org  Mon Aug 28 02:07:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 28 Aug 2023 02:07:29 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v2]
In-Reply-To: <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>
Message-ID: <VU5Nr1RC-nyXjz-Er39AmvPiOfJ8gFA8m78JlezLF90=.de9b7e4a-8b2b-4dc5-8a52-351231a406cf@github.com>

On Fri, 25 Aug 2023 05:10:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch adds a new API _ciEnv::is_multifield_scalarized_, to scalarize multifield (ciField[s]) in case target vector cannot accommodate multifield bundle size, else it creates a hierarchical structure ciMultiField and expose entire multifield bundle as one field to C2 compiler.
>> 
>> This cleans up special handling done in C2 compiler, ci field query APIs and object reconstruction handling  at SafePoint.
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused function declaration.

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

> 1780:   return InlineTypeNode::is_multifield_scalarized(bt, vec_length);
> 1781: #else
> 1782:   return false;

1. I think it's better to implement `is_multifield_scalarized()` here, and reference it in C2 compiler. It's opposite here.
2. By default, it should return `true` instead of `false` if `COMPILER2` is not supported.

src/hotspot/share/ci/ciInstanceKlass.cpp line 590:

> 588:   for (JavaFieldStream fs(k); !fs.done(); fs.next()) {
> 589:     if (fs.access_flags().is_static())  continue;
> 590:     if (fs.is_multifield() && sec_fields_count) {

Change to: `(fs.is_mutlfield() && sec_fields_count != 0)` ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/918#discussion_r1306824150
PR Review Comment: https://git.openjdk.org/valhalla/pull/918#discussion_r1306828199


From xgong at openjdk.org  Mon Aug 28 02:11:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 28 Aug 2023 02:11:30 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v2]
In-Reply-To: <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>
Message-ID: <x0sfmxo3h0rfv-MMVxWlW6fWQhn9mMUYbN-Xvool2XM=.60effdb3-73ec-4436-a9db-62a6b7fe4ed8@github.com>

On Fri, 25 Aug 2023 05:10:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch adds a new API _ciEnv::is_multifield_scalarized_, to scalarize multifield (ciField[s]) in case target vector cannot accommodate multifield bundle size, else it creates a hierarchical structure ciMultiField and expose entire multifield bundle as one field to C2 compiler.
>> 
>> This cleans up special handling done in C2 compiler, ci field query APIs and object reconstruction handling  at SafePoint.
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused function declaration.

Hi @jatin-bhateja, thanks for this refactoring! Code is much cleaner to me. So does it also need to clean the special handling for multifields in c1/interpreter (e.g. `deoptimize.cpp`) ? Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/918#issuecomment-1694893153


From jbhateja at openjdk.org  Mon Aug 28 06:15:30 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Aug 2023 06:15:30 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v2]
In-Reply-To: <VU5Nr1RC-nyXjz-Er39AmvPiOfJ8gFA8m78JlezLF90=.de9b7e4a-8b2b-4dc5-8a52-351231a406cf@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>
 <VU5Nr1RC-nyXjz-Er39AmvPiOfJ8gFA8m78JlezLF90=.de9b7e4a-8b2b-4dc5-8a52-351231a406cf@github.com>
Message-ID: <wCSpk3utqEZiz7JVDm9A-OdjXZ9tVcoHs5xc4yC4n9k=.1c6b8eba-42a3-4628-b1c5-6ef2c2188928@github.com>

On Mon, 28 Aug 2023 02:00:37 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused function declaration.
>
> src/hotspot/share/ci/ciEnv.cpp line 1782:
> 
>> 1780:   return InlineTypeNode::is_multifield_scalarized(bt, vec_length);
>> 1781: #else
>> 1782:   return false;
> 
> 1. I think it's better to implement `is_multifield_scalarized()` here, and reference it in C2 compiler. It's opposite here.
> 2. By default, it should return `true` instead of `false` if `COMPILER2` is not supported.

Agree with 2, thanks, will correct it! Idea here is that ci should leverage compiler exposed interfaces to determine scalarizability.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/918#discussion_r1306951790


From jbhateja at openjdk.org  Mon Aug 28 07:03:33 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Aug 2023 07:03:33 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v2]
In-Reply-To: <x0sfmxo3h0rfv-MMVxWlW6fWQhn9mMUYbN-Xvool2XM=.60effdb3-73ec-4436-a9db-62a6b7fe4ed8@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>
 <x0sfmxo3h0rfv-MMVxWlW6fWQhn9mMUYbN-Xvool2XM=.60effdb3-73ec-4436-a9db-62a6b7fe4ed8@github.com>
Message-ID: <NUvRvzY-ut9fXuRDj0Xnr-iomZdR4CIu3x95pvUkCgc=.52fe159d-72ec-4f44-bbbb-a8cdd03b3f77@github.com>

On Mon, 28 Aug 2023 02:09:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Hi @jatin-bhateja, thanks for this refactoring! Code is much cleaner to me. So does it also need to clean the special handling for multifields in c1/interpreter (e.g. `deoptimize.cpp`) ? Thanks!
> 
> Besides, the `secondary_fields_count()` which is broadcasted to the `bundle_size()` of the `ciField` is calculated from `multifield_info` (see: https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/fieldDescriptor.inline.hpp#L81), which I think may not be synced with each other. And it is used widely in C2 and deoptimization. Will it have any issues?
> 
> An alternative is checking the vector size supported when calculating the `secondary_fields_count()` in `fieldDescriptor.inline.hpp`. Return the multifield count if the vector size is supported, and return `1` if not. And then, we can use this information both at the ci stage when calculating the `nonstatic_fields` in `ciInstanceKlass.cpp` and C2 compiler. WDYT?

Thanks for reporting this, I was planning to do in next cleanup patch, but its good to club this with this one. Will update the PR soon.

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

PR Comment: https://git.openjdk.org/valhalla/pull/918#issuecomment-1695140156


From liangchenblue at gmail.com  Mon Aug 28 08:43:50 2023
From: liangchenblue at gmail.com (-)
Date: Mon, 28 Aug 2023 16:43:50 +0800
Subject: JVM verifier and Unsafe.allocateInstance in LambdaForm
Message-ID: <CABe8uE3KwwS8HknR9Ku3Mf=+mAsQcLTnjXF+Jm_S+yBUdZAjhg@mail.gmail.com>

Hello John and Valhalla community,
Reading the recent John Rose post "Larval Values" [1], which is about how
verifier's special rules on new-dup-<init> sequence can be applied to value
classes, I recall that in the code generated by DirectMethodHandle's lambda
forms, another sequence is used to initialize objects:
Unsafe.allocateInstance -> astore -> aload -> <init>. And in my patch [2]
where I seek to migrate serialization constructor implemented with
special-ruled classes (new-dup-<init>, but <init> a superclass, allowed per
special VM rules), this MH allocateInstance sequence apparently allows me
to call <init> of an unrelated class on the allocated object in my
experiments, such as calling Character's <init> on a String, though it has
no visible effect on the String object.

Are these behaviors of allocateInstance intended? Does the verifier treat
allocateInstance with a special rule? Since I am not familiar with JVM
internals written in C++ (being a pure Java developer), I hope someone
familiar with these matter, such as John who both led JSR 292 and now is an
important engineer in Valhalla, can help explain what exactly is going on
with Unsafe::allocateInstance in LambdaForms, and how this pattern will
evolve with the introduction of value types in Valhalla.

Truly curious,
Chen Liang

[1]: https://cr.openjdk.org/~jrose/values/larval-values.html
[2]: https://github.com/openjdk/jdk/pull/13853
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230828/3221494a/attachment.htm>

From jbhateja at openjdk.org  Tue Aug 29 09:42:14 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 29 Aug 2023 09:42:14 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v3]
In-Reply-To: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
Message-ID: <fNK1R4-VQn3YlO9feHVPl_0VXZ4BvkYYD2ZDd_ENGbI=.03e89b60-53b1-4a82-9738-eb9297e463f6@github.com>

> Patch adds a new API _ciEnv::is_multifield_scalarized_, to scalarize multifield (ciField[s]) in case target vector cannot accommodate multifield bundle size, else it creates a hierarchical structure ciMultiField and expose entire multifield bundle as one field to C2 compiler.
> 
> This cleans up special handling done in C2 compiler, ci field query APIs and object reconstruction handling  at SafePoint.
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Restricting population of multifield bundle size and setting _is_multifield_base to only ciMultifield objects.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/918/files
  - new: https://git.openjdk.org/valhalla/pull/918/files/7bad3292..fabeb37a

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

  Stats: 32 lines in 6 files changed: 9 ins; 6 del; 17 mod
  Patch: https://git.openjdk.org/valhalla/pull/918.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/918/head:pull/918

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


From jbhateja at openjdk.org  Tue Aug 29 09:42:14 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 29 Aug 2023 09:42:14 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v2]
In-Reply-To: <NUvRvzY-ut9fXuRDj0Xnr-iomZdR4CIu3x95pvUkCgc=.52fe159d-72ec-4f44-bbbb-a8cdd03b3f77@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>
 <x0sfmxo3h0rfv-MMVxWlW6fWQhn9mMUYbN-Xvool2XM=.60effdb3-73ec-4436-a9db-62a6b7fe4ed8@github.com>
 <NUvRvzY-ut9fXuRDj0Xnr-iomZdR4CIu3x95pvUkCgc=.52fe159d-72ec-4f44-bbbb-a8cdd03b3f77@github.com>
Message-ID: <tYhGll2bplWNKID0zyqbjcyx5doUsKH_vk_UEkr8Ns4=.107c5899-a1a5-4c6f-a1b5-f927f07a1ac3@github.com>

On Mon, 28 Aug 2023 07:00:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Hi @jatin-bhateja, thanks for this refactoring! Code is much cleaner to me. So does it also need to clean the special handling for multifields in c1/interpreter (e.g. `deoptimize.cpp`) ? Thanks!
> > Besides, the `secondary_fields_count()` which is broadcasted to the `bundle_size()` of the `ciField` is calculated from `multifield_info` (see: https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/runtime/fieldDescriptor.inline.hpp#L81), which I think may not be synced with each other. And it is used widely in C2 and deoptimization. Will it have any issues?


I do not think it should be a problem for de-optimization,  we have separate handling for re-assignment from vector and scalars locations.

> > An alternative is checking the vector size supported when calculating the `secondary_fields_count()` in `fieldDescriptor.inline.hpp`. Return the multifield count if the vector size is supported, and return `1` if not. And then, we can use this information both at the ci stage when calculating the `nonstatic_fields` in `ciInstanceKlass.cpp` and C2 compiler. WDYT?
> 

I am not in favor of making changes in oop population, unless there is a pressing need, all we need is to furnish appropriate data to compilers through ci layer.  

> Hi @XiaohongGong , Thanks for reporting this, I was planning to revisit this in next cleanup patch, but its good to club it with this one. Will update the PR with needed modifications.

I revisited the implementation and captured the flow in following diagram

![image](https://github.com/openjdk/valhalla/assets/59989778/c12b7a7c-2f37-4eb3-8108-0ba61687273c)

As discussed earlier, ClassFileParser creates separate FieldInfo structures for each synthetic multifield as its needed for field layout computations. Interpreter directly operates over oop model structures,  currently vectors are created by c2 compile only and it accesses oop model through compiler interface (ci).
 
I think to remove any ambiguity, its best to populate valid bundle_size and set is_multifield_base flag only if target vector size is able to accommodate multifield payload.

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

PR Comment: https://git.openjdk.org/valhalla/pull/918#issuecomment-1697098792


From fparain at openjdk.org  Tue Aug 29 20:34:47 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 29 Aug 2023 20:34:47 GMT
Subject: [lworld] RFR: 8315272: [lworld] Replacing NULL with nullptr in aarch64
 code
Message-ID: <VjJ8IXBudxJlfJTLCVcXcJuveohWsZesMI2EBD76lM4=.8a684200-3d9d-47a7-b987-be21e8d5b1db@github.com>

NULL -> nullptr replacement in aarch64 code.

Tested with Mach5 tier1.

Fred

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

Commit messages:
 - Rewrite NULL to nullptr in aarch64 code

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

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


From lfoltan at openjdk.org  Wed Aug 30 00:25:30 2023
From: lfoltan at openjdk.org (Lois Foltan)
Date: Wed, 30 Aug 2023 00:25:30 GMT
Subject: [lworld] RFR: 8315272: [lworld] Replacing NULL with nullptr in
 aarch64 code
In-Reply-To: <VjJ8IXBudxJlfJTLCVcXcJuveohWsZesMI2EBD76lM4=.8a684200-3d9d-47a7-b987-be21e8d5b1db@github.com>
References: <VjJ8IXBudxJlfJTLCVcXcJuveohWsZesMI2EBD76lM4=.8a684200-3d9d-47a7-b987-be21e8d5b1db@github.com>
Message-ID: <d23yO_y2iSKmCxb9bEGIW7YwhL7z8S2LHGLwVGQ5gqU=.14a3325d-e76f-43f4-9581-37b0b824bffe@github.com>

On Tue, 29 Aug 2023 20:28:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> NULL -> nullptr replacement in aarch64 code.
> 
> Tested with Mach5 tier1.
> 
> Fred

Looks good.
Lois

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

Marked as reviewed by lfoltan (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/920#pullrequestreview-1601623402


From xgong at openjdk.org  Wed Aug 30 01:27:36 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 30 Aug 2023 01:27:36 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v2]
In-Reply-To: <tYhGll2bplWNKID0zyqbjcyx5doUsKH_vk_UEkr8Ns4=.107c5899-a1a5-4c6f-a1b5-f927f07a1ac3@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <k66j5cZS5Sz66BQZE4YWIMIICjXk8gU-2Jk07eTSQPs=.3d323d16-6440-4a8b-8eae-2c7d30819333@github.com>
 <x0sfmxo3h0rfv-MMVxWlW6fWQhn9mMUYbN-Xvool2XM=.60effdb3-73ec-4436-a9db-62a6b7fe4ed8@github.com>
 <NUvRvzY-ut9fXuRDj0Xnr-iomZdR4CIu3x95pvUkCgc=.52fe159d-72ec-4f44-bbbb-a8cdd03b3f77@github.com>
 <tYhGll2bplWNKID0zyqbjcyx5doUsKH_vk_UEkr8Ns4=.107c5899-a1a5-4c6f-a1b5-f927f07a1ac3@github.com>
Message-ID: <5zDNhbIOYlAa6rP9FXFL4jWABiOF_LMAW0tlazJU614=.863f5b38-0ca2-41db-bf70-24ebc8dc690b@github.com>

On Tue, 29 Aug 2023 09:36:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> I think to remove any ambiguity, its best to populate valid bundle_size and set is_multifield_base flag only if target vector size is able to accommodate multifield payload.

Sounds reasonable to me. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/918#issuecomment-1698355313


From xgong at openjdk.org  Wed Aug 30 01:30:32 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 30 Aug 2023 01:30:32 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v3]
In-Reply-To: <fNK1R4-VQn3YlO9feHVPl_0VXZ4BvkYYD2ZDd_ENGbI=.03e89b60-53b1-4a82-9738-eb9297e463f6@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <fNK1R4-VQn3YlO9feHVPl_0VXZ4BvkYYD2ZDd_ENGbI=.03e89b60-53b1-4a82-9738-eb9297e463f6@github.com>
Message-ID: <0ll6JLZdDHirvRserwddYQD6ch3cL5PZr_yKEX-oDPE=.30ddb228-cfca-4744-9b91-f1ea470b2845@github.com>

On Tue, 29 Aug 2023 09:42:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Patch adds a new API _ciEnv::is_multifield_scalarized_, to scalarize multifield (ciField[s]) in case target vector cannot accommodate multifield bundle size, else it creates a hierarchical structure ciMultiField and expose entire multifield bundle as one field to C2 compiler.
>> 
>> This cleans up special handling done in C2 compiler, ci field query APIs and object reconstruction handling  at SafePoint.
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restricting population of multifield bundle size and setting _is_multifield_base to only ciMultifield objects.

src/hotspot/share/ci/ciField.cpp line 94:

> 92:   _is_multifield = false;
> 93:   _is_multifield_base = false;
> 94:   _is_transiant_multifield_base = false;

Why do we still need `_is_multifield_base` in `ciField` ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/918#discussion_r1309506468


From jbhateja at openjdk.org  Wed Aug 30 01:55:35 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 30 Aug 2023 01:55:35 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v3]
In-Reply-To: <0ll6JLZdDHirvRserwddYQD6ch3cL5PZr_yKEX-oDPE=.30ddb228-cfca-4744-9b91-f1ea470b2845@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <fNK1R4-VQn3YlO9feHVPl_0VXZ4BvkYYD2ZDd_ENGbI=.03e89b60-53b1-4a82-9738-eb9297e463f6@github.com>
 <0ll6JLZdDHirvRserwddYQD6ch3cL5PZr_yKEX-oDPE=.30ddb228-cfca-4744-9b91-f1ea470b2845@github.com>
Message-ID: <eD-yyMx1VSuK6bB6NezJOWPxjbwMnQg0b8ww8JmZnjY=.94fd1dc7-6799-48fa-980d-6b3e1d656949@github.com>

On Wed, 30 Aug 2023 01:27:56 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restricting population of multifield bundle size and setting _is_multifield_base to only ciMultifield objects.
>
> src/hotspot/share/ci/ciField.cpp line 94:
> 
>> 92:   _is_multifield = false;
>> 93:   _is_multifield_base = false;
>> 94:   _is_transiant_multifield_base = false;
> 
> Why do we still need `_is_multifield_base` in `ciField` ?

That is one which is being used by compilers. The transient one is there for ciInstanceKlass::populate_synthetic_multifields. Both c1 and C2 use ciBytecodeStream::get_field API which creates a ciField from field reference in constant pool. It does not take into account annotations over the field and hence populate synthetic fields operates over originally created field to create a fully populated ciMultifiled. I wanted to avoid adding a transient flag originally.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/918#discussion_r1309521856


From xgong at openjdk.org  Wed Aug 30 01:55:35 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 30 Aug 2023 01:55:35 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v3]
In-Reply-To: <eD-yyMx1VSuK6bB6NezJOWPxjbwMnQg0b8ww8JmZnjY=.94fd1dc7-6799-48fa-980d-6b3e1d656949@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <fNK1R4-VQn3YlO9feHVPl_0VXZ4BvkYYD2ZDd_ENGbI=.03e89b60-53b1-4a82-9738-eb9297e463f6@github.com>
 <0ll6JLZdDHirvRserwddYQD6ch3cL5PZr_yKEX-oDPE=.30ddb228-cfca-4744-9b91-f1ea470b2845@github.com>
 <eD-yyMx1VSuK6bB6NezJOWPxjbwMnQg0b8ww8JmZnjY=.94fd1dc7-6799-48fa-980d-6b3e1d656949@github.com>
Message-ID: <JIRz4L5obzPUSCpWU1jFh2OpPGzJyUN3qKW-Ybs_vOA=.27b8f6da-8a99-4d3c-b5e1-c7c46b8d7d54@github.com>

On Wed, 30 Aug 2023 01:48:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/ci/ciField.cpp line 94:
>> 
>>> 92:   _is_multifield = false;
>>> 93:   _is_multifield_base = false;
>>> 94:   _is_transiant_multifield_base = false;
>> 
>> Why do we still need `_is_multifield_base` in `ciField` ?
>
> That is one which is being used by compilers. The transient one is there for ciInstanceKlass::populate_synthetic_multifields. Both c1 and C2 use ciBytecodeStream::get_field API which creates a ciField from field reference in constant pool. It does not take into account annotations over the field and hence populate synthetic fields operates over originally created field to create a fully populated ciMultifiled. I wanted to avoid adding a transient flag originally.

Yes, I'm wondering whether we can use one like before, by just setting `_is_multifield_base = true` only when the multifields are vectorized.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/918#discussion_r1309524729


From xgong at openjdk.org  Wed Aug 30 06:17:26 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 30 Aug 2023 06:17:26 GMT
Subject: [lworld+vector] RFR: Merge lworld
Message-ID: <wIi8iBqFzQvQrE5AaWBaYwWWY26YDesd3Rj6NKHAkIA=.bd63b702-c3e4-4d44-bb46-d668001b5cef@github.com>

This patch merges the latest `valhalla:lworld` to
 `valhalla:lworld+vector` branch, together with following
 main changes:

1. Resolve conflicts mainly caused by the BACKOUT of
 `VectorShuffle refactory` in jdk mainline [1].
2. Fix the class id issue for `SafePointScalarMergeNode` added by [JDK-8287061](https://bugs.openjdk.java.net/browse/JDK-8287061). This causes an jvm crash
 when building the jdk image. `lworld` branch also
 fixes it (see [2]), but it seems the id is not correctly
 ordered.

[1] https://github.com/openjdk/jdk/pull/14629

[2] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/node.hpp#L738

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

Commit messages:
 - [lworld+vector] Merge lworld
 - 8314923: [lworld] AllocationMergesTests.java fails IR verification
 - Merge jdk
 - 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074
 - 8309088: security/infra/java/security/cert/CertPathValidator/certification/AmazonCA.java fails
 - 8313087: DerValue::toString should output a hex view of the values in byte array
 - 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec
 - 8313155: Problem list some JUnit-based tests in test/jdk/java/lang/invoke
 - 8312445: Array types in annotation elements show square brackets twice
 - 8312526: Test dk/jfr/event/oldobject/TestHeapDeep.java failed: Could not find ChainNode
 - ... and 819 more: https://git.openjdk.org/valhalla/compare/c073a2fd...9890580d

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

Changes: https://git.openjdk.org/valhalla/pull/921/files
  Stats: 238118 lines in 3830 files changed: 127006 ins; 91855 del; 19257 mod
  Patch: https://git.openjdk.org/valhalla/pull/921.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/921/head:pull/921

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


From xgong at openjdk.org  Wed Aug 30 06:36:01 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 30 Aug 2023 06:36:01 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <wIi8iBqFzQvQrE5AaWBaYwWWY26YDesd3Rj6NKHAkIA=.bd63b702-c3e4-4d44-bb46-d668001b5cef@github.com>
References: <wIi8iBqFzQvQrE5AaWBaYwWWY26YDesd3Rj6NKHAkIA=.bd63b702-c3e4-4d44-bb46-d668001b5cef@github.com>
Message-ID: <unYPkX-HDrYI5BOSFItQlQqtrfghEXBLwC118uuis_g=.26f9b522-ae46-4756-8ece-47ec4c45e6b2@github.com>

> This patch merges the latest `valhalla:lworld` to
>  `valhalla:lworld+vector` branch, together with following
>  main changes:
> 
> 1. Resolve conflicts mainly caused by the BACKOUT of
>  `VectorShuffle refactory` in jdk mainline [1].
> 2. Fix the class id issue for `SafePointScalarMergeNode` added by [JDK-8287061](https://bugs.openjdk.java.net/browse/JDK-8287061). This causes an jvm crash
>  when building the jdk image. `lworld` branch also
>  fixes it (see [2]), but it seems the id is not correctly
>  ordered.
> 
> [1] https://github.com/openjdk/jdk/pull/14629
> 
> [2] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/node.hpp#L738

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

  Merge lworld

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/921/files
  - new: https://git.openjdk.org/valhalla/pull/921/files/9890580d..6bf52e45

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

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

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


From fparain at openjdk.org  Wed Aug 30 18:59:49 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 30 Aug 2023 18:59:49 GMT
Subject: [lworld] RFR: 8315272: [lworld] Replacing NULL with nullptr in
 aarch64 code
In-Reply-To: <VjJ8IXBudxJlfJTLCVcXcJuveohWsZesMI2EBD76lM4=.8a684200-3d9d-47a7-b987-be21e8d5b1db@github.com>
References: <VjJ8IXBudxJlfJTLCVcXcJuveohWsZesMI2EBD76lM4=.8a684200-3d9d-47a7-b987-be21e8d5b1db@github.com>
Message-ID: <7hGbrYxKJ8q5tu52CtJukjlJpflK9Q_Yq527Lz9TBDU=.a69cf165-4b00-41f3-94a2-bf3986b12c3b@github.com>

On Tue, 29 Aug 2023 20:28:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> NULL -> nullptr replacement in aarch64 code.
> 
> Tested with Mach5 tier1.
> 
> Fred

Thank you for the review.
Fred

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

PR Comment: https://git.openjdk.org/valhalla/pull/920#issuecomment-1699683506


From fparain at openjdk.org  Wed Aug 30 18:59:50 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 30 Aug 2023 18:59:50 GMT
Subject: [lworld] Integrated: 8315272: [lworld] Replacing NULL with nullptr in
 aarch64 code
In-Reply-To: <VjJ8IXBudxJlfJTLCVcXcJuveohWsZesMI2EBD76lM4=.8a684200-3d9d-47a7-b987-be21e8d5b1db@github.com>
References: <VjJ8IXBudxJlfJTLCVcXcJuveohWsZesMI2EBD76lM4=.8a684200-3d9d-47a7-b987-be21e8d5b1db@github.com>
Message-ID: <VxFnjozobemoEBto2L0UYxE30x-RGxr4gxUxzVszK7w=.2d8aff04-b7d5-4ac0-8b4b-39c8d56212bc@github.com>

On Tue, 29 Aug 2023 20:28:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> NULL -> nullptr replacement in aarch64 code.
> 
> Tested with Mach5 tier1.
> 
> Fred

This pull request has now been integrated.

Changeset: 3b4cc5fd
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3b4cc5fdb038a7363e5ac8a704adacd70701c1ff
Stats:     47 lines in 6 files changed: 0 ins; 0 del; 47 mod

8315272: [lworld] Replacing NULL with nullptr in aarch64 code

Reviewed-by: lfoltan

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

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


From fparain at openjdk.org  Wed Aug 30 21:12:45 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 30 Aug 2023 21:12:45 GMT
Subject: [lworld] RFR: 8315412 [lworld] Preparing code for lw5
Message-ID: <E6XPLYmqzPCtGJu-f4khWww1iP7vEMV1oC-Qw-PpSBQ=.e2d8dd51-7166-46a3-8dab-5c051a414a91@github.com>

Quite a big patch, but it is mostly made of renaming and mechanical replacement without really changing the logic of the code.

The patch includes changes to make the VM code less dependent on Q-descriptors by encoding the presence of null-free inline types fields in FieldInfo.

The patch also includes a lot of renaming, in an effort to have uniformed naming of flat fields and flat arrays across the VM. The renaming has not been applied to the heap dumper and C2. They will be addressed in follow up patches.

Tested with Mach5, tiers 1 to 3.

Thank you

Fred

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

Commit messages:
 - Merge remote-tracking branch 'upstream/lworld' into qdesc_removal
 - Renaming and preparation for q-descriptors removal

Changes: https://git.openjdk.org/valhalla/pull/922/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=922&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315412
  Stats: 689 lines in 79 files changed: 99 ins; 88 del; 502 mod
  Patch: https://git.openjdk.org/valhalla/pull/922.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/922/head:pull/922

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


From jbhateja at openjdk.org  Thu Aug 31 05:36:49 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 31 Aug 2023 05:36:49 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v4]
In-Reply-To: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
Message-ID: <kjeGPaFnSq4Y7Vw-VSYFAPlLfq82pqeZHAO5KIeCYDQ=.664b0263-b1dc-4de5-b8e6-6d0ca81f441d@github.com>

> Patch adds a new API _ciEnv::is_multifield_scalarized_, to scalarize multifield (ciField[s]) in case target vector cannot accommodate multifield bundle size, else it creates a hierarchical structure ciMultiField and expose entire multifield bundle as one field to C2 compiler.
> 
> This cleans up special handling done in C2 compiler, ci field query APIs and object reconstruction handling  at SafePoint.
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

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

  Removing transiant flag.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/918/files
  - new: https://git.openjdk.org/valhalla/pull/918/files/fabeb37a..800bba0f

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

  Stats: 8 lines in 4 files changed: 1 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/918.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/918/head:pull/918

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


From jbhateja at openjdk.org  Thu Aug 31 05:36:50 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 31 Aug 2023 05:36:50 GMT
Subject: [lworld+vector] RFR: 8314980: [lworld+vector] consider
 scalarization conditions during ciMultiField creation. [v3]
In-Reply-To: <JIRz4L5obzPUSCpWU1jFh2OpPGzJyUN3qKW-Ybs_vOA=.27b8f6da-8a99-4d3c-b5e1-c7c46b8d7d54@github.com>
References: <bAZNvq5ifgSn3EpIKAzBSqVZNZ99I7mMENIVuF0DeJc=.4ce3ff90-4c7b-4950-856e-6ff83ea557d2@github.com>
 <fNK1R4-VQn3YlO9feHVPl_0VXZ4BvkYYD2ZDd_ENGbI=.03e89b60-53b1-4a82-9738-eb9297e463f6@github.com>
 <0ll6JLZdDHirvRserwddYQD6ch3cL5PZr_yKEX-oDPE=.30ddb228-cfca-4744-9b91-f1ea470b2845@github.com>
 <eD-yyMx1VSuK6bB6NezJOWPxjbwMnQg0b8ww8JmZnjY=.94fd1dc7-6799-48fa-980d-6b3e1d656949@github.com>
 <JIRz4L5obzPUSCpWU1jFh2OpPGzJyUN3qKW-Ybs_vOA=.27b8f6da-8a99-4d3c-b5e1-c7c46b8d7d54@github.com>
Message-ID: <-MsgrDoMQfUozqiPv4hLmU4wUlYLstyKbDYiqWhWSjw=.78139187-8bd7-4ba9-b141-952dc8e42d64@github.com>

On Wed, 30 Aug 2023 01:53:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> That is one which is being used by compilers. The transient one is there for ciInstanceKlass::populate_synthetic_multifields. Both c1 and C2 use ciBytecodeStream::get_field API which creates a ciField from field reference in constant pool. It does not take into account annotations over the field and hence populate synthetic fields operates over originally created field to create a fully populated ciMultifiled. I wanted to avoid adding a transient flag originally.
>
> Yes, I'm wondering whether we can use one like before, by just setting `_is_multifield_base = true` only when the multifields are vectorized.

Fixed the messy nit.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/918#discussion_r1311111993


From jbhateja at openjdk.org  Thu Aug 31 06:14:31 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 31 Aug 2023 06:14:31 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <unYPkX-HDrYI5BOSFItQlQqtrfghEXBLwC118uuis_g=.26f9b522-ae46-4756-8ece-47ec4c45e6b2@github.com>
References: <wIi8iBqFzQvQrE5AaWBaYwWWY26YDesd3Rj6NKHAkIA=.bd63b702-c3e4-4d44-bb46-d668001b5cef@github.com>
 <unYPkX-HDrYI5BOSFItQlQqtrfghEXBLwC118uuis_g=.26f9b522-ae46-4756-8ece-47ec4c45e6b2@github.com>
Message-ID: <szJ7216pqB8f7iBZdQPVe8d2CHoM-JaXnTtVsCMzAko=.c76cf117-7521-4824-978f-e2b3c3d4e558@github.com>

On Wed, 30 Aug 2023 06:36:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch merges the latest `valhalla:lworld` to
>>  `valhalla:lworld+vector` branch, together with following
>>  main changes:
>> 
>> 1. Resolve conflicts mainly caused by the BACKOUT of
>>  `VectorShuffle refactory` in jdk mainline [1].
>> 2. Fix the class id issue for `SafePointScalarMergeNode` added by [JDK-8287061](https://bugs.openjdk.java.net/browse/JDK-8287061). This causes an jvm crash
>>  when building the jdk image. `lworld` branch also
>>  fixes it (see [2]), but it seems the id is not correctly
>>  ordered.
>> 
>> [1] https://github.com/openjdk/jdk/pull/14629
>> 
>> [2] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/node.hpp#L738
>
> Xiaohong Gong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Merge lworld

Marked as reviewed by jbhateja (Committer).

Hi @XiaohongGong , 

I verified that validation status is intact and other failures with additional -XX:+DeoptimizeALot option are also fixed with the merge.

Best Regards,
Jatin

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

PR Review: https://git.openjdk.org/valhalla/pull/921#pullrequestreview-1604009574
PR Comment: https://git.openjdk.org/valhalla/pull/921#issuecomment-1700422522


From xgong at openjdk.org  Thu Aug 31 06:38:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 31 Aug 2023 06:38:29 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <szJ7216pqB8f7iBZdQPVe8d2CHoM-JaXnTtVsCMzAko=.c76cf117-7521-4824-978f-e2b3c3d4e558@github.com>
References: <wIi8iBqFzQvQrE5AaWBaYwWWY26YDesd3Rj6NKHAkIA=.bd63b702-c3e4-4d44-bb46-d668001b5cef@github.com>
 <unYPkX-HDrYI5BOSFItQlQqtrfghEXBLwC118uuis_g=.26f9b522-ae46-4756-8ece-47ec4c45e6b2@github.com>
 <szJ7216pqB8f7iBZdQPVe8d2CHoM-JaXnTtVsCMzAko=.c76cf117-7521-4824-978f-e2b3c3d4e558@github.com>
Message-ID: <p_ptZUbITDbE3RXRqF_wwBnQ1f22Z3h-JME7wjApePc=.55c039f8-0d32-47bb-8288-a9b6d31b47a2@github.com>

On Thu, 31 Aug 2023 06:10:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi @XiaohongGong ,
> 
> I verified that validation status is intact and other failures with additional -XX:+DeoptimizeALot option are also fixed with the merge.
> 
> Best Regards, Jatin

Thanks for the review and testing @jatin-bhateja ! Did you see any other regressions on Vector API tests with this option? I also ran the tests with `-XX:+DeoptimizeALot`, but some regressions that I met before are still there on NEON.  I remembered that some x86 specific code was changed (i.e. https://github.com/openjdk/valhalla/commit/d9f744fe6e816a91aa7c8d5e84ce464e8a9d3921#diff-a47d36f3d2e8997bd3d2320ef348dd17b91f388d2cb6e91e9d99d66df5ccd897), which is missing on AArch64 platform now. Seems this can also influence the result in interpreter, right? I will have a test by adding the similar code on AArch64 again. 

Best Regards,
Xiaohong

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

PR Comment: https://git.openjdk.org/valhalla/pull/921#issuecomment-1700445882


From xgong at openjdk.org  Thu Aug 31 06:56:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 31 Aug 2023 06:56:30 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <unYPkX-HDrYI5BOSFItQlQqtrfghEXBLwC118uuis_g=.26f9b522-ae46-4756-8ece-47ec4c45e6b2@github.com>
References: <wIi8iBqFzQvQrE5AaWBaYwWWY26YDesd3Rj6NKHAkIA=.bd63b702-c3e4-4d44-bb46-d668001b5cef@github.com>
 <unYPkX-HDrYI5BOSFItQlQqtrfghEXBLwC118uuis_g=.26f9b522-ae46-4756-8ece-47ec4c45e6b2@github.com>
Message-ID: <_qHxzhU5ylvVi3fOGYTFKY0aIKF4i6tf0oxdrLPyL5E=.1cd2a4e5-255b-41e7-a27d-db3cdd91ed07@github.com>

On Wed, 30 Aug 2023 06:36:01 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This patch merges the latest `valhalla:lworld` to
>>  `valhalla:lworld+vector` branch, together with following
>>  main changes:
>> 
>> 1. Resolve conflicts mainly caused by the BACKOUT of
>>  `VectorShuffle refactory` in jdk mainline [1].
>> 2. Fix the class id issue for `SafePointScalarMergeNode` added by [JDK-8287061](https://bugs.openjdk.java.net/browse/JDK-8287061). This causes an jvm crash
>>  when building the jdk image. `lworld` branch also
>>  fixes it (see [2]), but it seems the id is not correctly
>>  ordered.
>> 
>> [1] https://github.com/openjdk/jdk/pull/14629
>> 
>> [2] https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/node.hpp#L738
>
> Xiaohong Gong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Merge lworld

> 

Unfortunately, the regressions are still there even with the AArch64 changes. One of the log is:

test Int128VectorTests.GEInt128VectorTestsMasked(int[i], int[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 Int128VectorTests.GEInt128VectorTestsMasked(Int128VectorTests.java:4176)

Anyway, this is not invoked by this merge, and I will revisit the regressions in furure.

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

PR Comment: https://git.openjdk.org/valhalla/pull/921#issuecomment-1700465690


From jbhateja at openjdk.org  Thu Aug 31 10:04:20 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 31 Aug 2023 10:04:20 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16
 scalar operations. [v5]
In-Reply-To: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
References: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
Message-ID: <hjNLWuBYwVq3Smeg7GgZ4pXtxCR5XfuDnzF0lCgfs3A=.b7bd873a-5502-449f-b0b6-f8749d2a71e9@github.com>

> Starting with 4th Generation Xeon, Intel has made extensive extensions to existing ISA to support 16 bit scalar and vector floating point operations based on IEEE 754 binary16 format.
> 
> We plan to support this in multiple stages spanning across Java side definition of Float16 type, scalar operation and finally SLP vectorization support.
> 
> This patch adds  minimal Java and Compiler side support for one API Float16.add.
> 
> **Summary of changes :-**
> - Minimal implementation of Float16 primitive class supporting one operation (Float16.add)
> - X86 AVX512-FP16 feature detection at VM startup.
> - C2 IR and Inline expander changes for Float16.add API.
> - FP16 constant folding handling.
> - Backend support : Instruction selection patterns and assembler support.
> - New IR framework and functional tests.
> 
> **Implementation details:-**
> 
> 1/ Newly defined Float16 class encapsulate a short value holding IEEE 754 binary16 encoded value.
> 
> 2/ Float16 is a primitive class which in future will be aligned with other enhanced primitive wrapper classes proposed by [JEP-402.](https://openjdk.org/jeps/402)
> 
> 3/ Float16 to support all the operations supported by corresponding Float class.
> 
> 4/ Java implementation of each API will internally perform floating point operation at FP32 granularity.
> 
> 5/ API which can be directly mapped to an Intel AVX512FP16 instruction will be a candidate for intensification by C2 compiler.
> 
> 6/ With Valhalla, C2 compiler always creates an InlineType IR node for a value class instance.
> Total number of inputs of an InlineType node match the number of non-static fields. In this case node will have one input of short type TypeInt::SHORT.
> 
> 7/ Since all the scalar AVX512FP16 instructions operate on floating point registers and Float16 backing storage is held in a general-purpose register hence we need to introduce appropriate conversion IR which moves a 16-bit value from GPR to a XMM register and vice versa.
> ![image](https://github.com/openjdk/valhalla/assets/59989778/192fca7e-6b7e-4e62-9b09-677e33eca48d)
> 
> 8/ Current plan is to introduce a new IR node for each operation which is a subclass of its corresponding single precision IR node. This will allow leveraging idealization routines (Ideal/Identity/Value) of its parent operation.
> 
> 9/ All the single/double precision IR nodes carry a Type::FLOAT/DOUBLE ideal type. This represents entire FP32/64 value range and is different from integral types which explicitly record lower and upper bounds of value ranges. Value resolution ...

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

  Resolving offline review comments from Paul Sandoz and Xiaohong Gong.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/848/files
  - new: https://git.openjdk.org/valhalla/pull/848/files/6989b465..53ac8929

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

  Stats: 162 lines in 9 files changed: 103 ins; 27 del; 32 mod
  Patch: https://git.openjdk.org/valhalla/pull/848.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/848/head:pull/848

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


From jbhateja at openjdk.org  Thu Aug 31 10:04:24 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 31 Aug 2023 10:04:24 GMT
Subject: [lworld+fp16] RFR: 8308363: Initial compiler support for FP16
 scalar operations. [v4]
In-Reply-To: <0eCZlRS1h6dj4OMBsQQ-OYbEv1XnXx9vBnlwyrqecOA=.f1934680-ef7f-4719-a539-e4a9d6f458e8@github.com>
References: <EOUKT_hJdn716obHgArmoIGSVynJeZ4w3x0tg50bjH8=.02dc34e3-cd06-49f1-9bde-3ea6d02ac7c6@github.com>
 <6ZtznppSDRnEjZObGHyEyFdvbfXr1TQvklL45bwFmPg=.bf3fc04d-e2d3-4a1a-9c91-925d7fbfcb5c@github.com>
 <0eCZlRS1h6dj4OMBsQQ-OYbEv1XnXx9vBnlwyrqecOA=.f1934680-ef7f-4719-a539-e4a9d6f458e8@github.com>
Message-ID: <PGWQ4_uluZUsdYPoQkhypUyOjdWrWVai6rVD1f2nMu4=.84d245e4-ce30-47c8-9294-967a4b9636f6@github.com>

On Thu, 24 Aug 2023 08:38:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing offline review comments from Sandhya, new IR test addition.
>
> src/hotspot/share/classfile/classFileParser.cpp line 5176:
> 
>> 5174:       // Can't enable this check fully until JDK upgrades the bytecode generators (TODO: JDK-8270852).
>> 5175:       // For now, compare to class file version 51 so old verifier doesn't see Q signatures.
>> 5176:       if ( (_major_version < 51 /* CONSTANT_CLASS_DESCRIPTORS */ ) || (!EnablePrimitiveClasses && !is_jdk_internal_class_sig(signature))) {
> 
> The last condition `(!EnablePrimitiveClasses && !is_jdk_internal_class_sig(signature))` seems not right to me. Assume there is a jdk internal primitive class defined , and `EnablePrimitiveClasses` is disabled, then result of `(!EnablePrimitiveClasses && !is_jdk_internal_class_sig(signature))` is `false` (i.e. `true && false`), then the followed error is not printed if the jdk version matches >= 51. But it should report the error since `EnablePrimitiveClasses` is closed.  So it should be:
> 
> if ( (_major_version < 51 /* CONSTANT_CLASS_DESCRIPTORS */ ) || !EnablePrimitiveClasses || !is_jdk_internal_class_sig(signature))
> 
> right?

Idea here is to relax the need to use an explicit JVM flag -XX:+EnablePrimtiiveClasses for primitive classes known to VM.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/848#discussion_r1311394730


From jbhateja at openjdk.org  Thu Aug 31 10:28:31 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 31 Aug 2023 10:28:31 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <_qHxzhU5ylvVi3fOGYTFKY0aIKF4i6tf0oxdrLPyL5E=.1cd2a4e5-255b-41e7-a27d-db3cdd91ed07@github.com>
References: <wIi8iBqFzQvQrE5AaWBaYwWWY26YDesd3Rj6NKHAkIA=.bd63b702-c3e4-4d44-bb46-d668001b5cef@github.com>
 <unYPkX-HDrYI5BOSFItQlQqtrfghEXBLwC118uuis_g=.26f9b522-ae46-4756-8ece-47ec4c45e6b2@github.com>
 <_qHxzhU5ylvVi3fOGYTFKY0aIKF4i6tf0oxdrLPyL5E=.1cd2a4e5-255b-41e7-a27d-db3cdd91ed07@github.com>
Message-ID: <MS4hZS1fw6QBP3F2HUhaS6JdxCp6OOKSMSTz6OxgaWM=.d6c3f8c4-2b9a-4c40-8633-82f90056a323@github.com>

On Thu, 31 Aug 2023 06:53:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Merge lworld
>
>> 
> 
> Unfortunately, the regressions are still there even with the AArch64 changes. One of the log is:
> 
> test Int128VectorTests.GEInt128VectorTestsMasked(int[i], int[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 Int128VectorTests.GEInt128VectorTestsMasked(Int128VectorTests.java:4176)
> 
> Anyway, this is not invoked by this merge, and I will revisit the regressions in furure.

> > Hi @XiaohongGong ,
> > I verified that validation status is intact and other failures with additional -XX:+DeoptimizeALot option are also fixed with the merge.
> > Best Regards, Jatin
> 
> Thanks for the review and testing @jatin-bhateja ! Did you see any other regressions on Vector API tests with this option? I also ran the tests with `-XX:+DeoptimizeALot`, but some regressions that I met before are still there on NEON. I remembered that some x86 specific code was changed (i.e. [d9f744f#diff-a47d36f3d2e8997bd3d2320ef348dd17b91f388d2cb6e91e9d99d66df5ccd897](https://github.com/openjdk/valhalla/commit/d9f744fe6e816a91aa7c8d5e84ce464e8a9d3921#diff-a47d36f3d2e8997bd3d2320ef348dd17b91f388d2cb6e91e9d99d66df5ccd897)), which is missing on AArch64 platform now. Seems this can also influence the result in interpreter, right? I will have a test by adding the similar code on AArch64 again.
> 
> Best Regards, Xiaohong

Failures related to shuffle/mask in *LoadStoreTests.java are no longer seen with merge. Overall validation status improved when compared with pre-merge state. Do you see any new failures introduced with merge ?

If not can we integrate this patch and then fix the outstand regressions.

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/921#issuecomment-1700775886


From jbhateja at openjdk.org  Thu Aug 31 10:55:31 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 31 Aug 2023 10:55:31 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <_qHxzhU5ylvVi3fOGYTFKY0aIKF4i6tf0oxdrLPyL5E=.1cd2a4e5-255b-41e7-a27d-db3cdd91ed07@github.com>
References: <wIi8iBqFzQvQrE5AaWBaYwWWY26YDesd3Rj6NKHAkIA=.bd63b702-c3e4-4d44-bb46-d668001b5cef@github.com>
 <unYPkX-HDrYI5BOSFItQlQqtrfghEXBLwC118uuis_g=.26f9b522-ae46-4756-8ece-47ec4c45e6b2@github.com>
 <_qHxzhU5ylvVi3fOGYTFKY0aIKF4i6tf0oxdrLPyL5E=.1cd2a4e5-255b-41e7-a27d-db3cdd91ed07@github.com>
Message-ID: <7lnJFgD1r_7pnGeVYC1C5agdz739XQJuklvSFZQCmR4=.1a96795a-5729-4808-a579-620d9737aaa8@github.com>

On Thu, 31 Aug 2023 06:53:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Merge lworld
>
>> 
> 
> Unfortunately, the regressions are still there even with the AArch64 changes. One of the log is:
> 
> test Int128VectorTests.GEInt128VectorTestsMasked(int[i], int[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 Int128VectorTests.GEInt128VectorTestsMasked(Int128VectorTests.java:4176)
> 
> Anyway, this is not invoked by this merge, and I will revisit the regressions in furure.

> > Hi @XiaohongGong ,
> > I verified that validation status is intact and other failures with additional -XX:+DeoptimizeALot option are also fixed with the merge.
> > Best Regards, Jatin
> 
> Thanks for the review and testing @jatin-bhateja ! Did you see any other regressions on Vector API tests with this option? I also ran the tests with `-XX:+DeoptimizeALot`, but some regressions that I met before are still there on NEON. I remembered that some x86 specific code was changed (i.e. [d9f744f#diff-a47d36f3d2e8997bd3d2320ef348dd17b91f388d2cb6e91e9d99d66df5ccd897](https://github.com/openjdk/valhalla/commit/d9f744fe6e816a91aa7c8d5e84ce464e8a9d3921#diff-a47d36f3d2e8997bd3d2320ef348dd17b91f388d2cb6e91e9d99d66df5ccd897)), which is missing on AArch64 platform now. Seems this can also influence the result in interpreter, right? I will have a test by adding the similar code on AArch64 again.
> 
> Best Regards, Xiaohong

Yes, this can impact test failures since VectorPayload* constructors return a value object and we do not want to scalarize it, by default values are flattened using unpacking handlers.

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

PR Comment: https://git.openjdk.org/valhalla/pull/921#issuecomment-1700813401


From vromero at openjdk.org  Thu Aug 31 17:26:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Aug 2023 17:26:27 GMT
Subject: Integrated: Merge lworld
Message-ID: <dBkX7x4jk29pjDGL0zWW0qwqsqaFXPC9wFVMH-9FUzM=.13762fe7-7fcd-4dfc-a9ed-9f9587b02706@github.com>

Merge branch 'lworld' into lw5_merge_lworld

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

Commit messages:
 - Merge branch 'lworld' into lw5_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
 - 8314165: [lw5] check for illegal circularity at class loading time
 - Merge lworld
 - [lw5] regression test cleanup, relocation
 - [lw5] fixing bugs on experimental code to generate Q-descriptors, plus code refactoring
 - ... and 17 more: https://git.openjdk.org/valhalla/compare/3b4cc5fd...b182f4f2

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

Changes: https://git.openjdk.org/valhalla/pull/923/files
  Stats: 6286 lines in 239 files changed: 3553 ins; 1757 del; 976 mod
  Patch: https://git.openjdk.org/valhalla/pull/923.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/923/head:pull/923

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


From vromero at openjdk.org  Thu Aug 31 17:26:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 31 Aug 2023 17:26:28 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <dBkX7x4jk29pjDGL0zWW0qwqsqaFXPC9wFVMH-9FUzM=.13762fe7-7fcd-4dfc-a9ed-9f9587b02706@github.com>
References: <dBkX7x4jk29pjDGL0zWW0qwqsqaFXPC9wFVMH-9FUzM=.13762fe7-7fcd-4dfc-a9ed-9f9587b02706@github.com>
Message-ID: <HP-awWTB-4HxlH4nWqwytC2ykXVu0ihu2vmYjN_NWNM=.d5ff88ac-38df-473c-85ed-7689a4fb9374@github.com>

On Thu, 31 Aug 2023 17:19:41 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld

This pull request has now been integrated.

Changeset: 35e10244
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/35e102441815b924130c70c1ff8e353f66ccc4f1
Stats:     24417 lines in 424 files changed: 11708 ins; 10803 del; 1906 mod

Merge lworld

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

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


From lfoltan at openjdk.org  Thu Aug 31 18:58:26 2023
From: lfoltan at openjdk.org (Lois Foltan)
Date: Thu, 31 Aug 2023 18:58:26 GMT
Subject: [lworld] RFR: 8315412 [lworld] Preparing code for lw5
In-Reply-To: <E6XPLYmqzPCtGJu-f4khWww1iP7vEMV1oC-Qw-PpSBQ=.e2d8dd51-7166-46a3-8dab-5c051a414a91@github.com>
References: <E6XPLYmqzPCtGJu-f4khWww1iP7vEMV1oC-Qw-PpSBQ=.e2d8dd51-7166-46a3-8dab-5c051a414a91@github.com>
Message-ID: <mGOkPcFsZzADC-Dez1tYfE2k00MXIoioWIB-4qAJODs=.5169dd03-47ee-4565-8371-c84f1d7770b1@github.com>

On Wed, 30 Aug 2023 20:52:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Quite a big patch, but it is mostly made of renaming and mechanical replacement without really changing the logic of the code.
> 
> The patch includes changes to make the VM code less dependent on Q-descriptors by encoding the presence of null-free inline types fields in FieldInfo.
> 
> The patch also includes a lot of renaming, in an effort to have uniformed naming of flat fields and flat arrays across the VM. The renaming has not been applied to the heap dumper and C2. They will be addressed in follow up patches.
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you
> 
> Fred

Good clean up, some very minor comments, overall looks good.

src/hotspot/share/ci/ciInstanceKlass.cpp line 774:

> 772:     }
> 773:     case T_PRIMITIVE_OBJECT: // fall-through
> 774:     case T_ARRAY:  // fall-through

Minor nit: do both line 773 & 774 need "fall-through" comment?

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

> 695:  *     constraint when flattening this inline type into another container
> 696:  *   - field flattening decisions are taken in this method (those decisions are
> 697:  *     currently only based in the size of the fields to be flatten, the size

flatten -> flattened

src/hotspot/share/oops/cpCache.cpp line 136:

> 134:                   ((is_volatile ? 1 : 0) << is_volatile_shift) |
> 135:                   ((is_final    ? 1 : 0) << is_final_shift) |
> 136:                   ((is_flat  ? 1 : 0) << is_flat_shift) |

Minor nit, line up ternary expression with lines above

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

Marked as reviewed by lfoltan (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/922#pullrequestreview-1605471945
PR Review Comment: https://git.openjdk.org/valhalla/pull/922#discussion_r1312077689
PR Review Comment: https://git.openjdk.org/valhalla/pull/922#discussion_r1312066245
PR Review Comment: https://git.openjdk.org/valhalla/pull/922#discussion_r1312073822


From fparain at openjdk.org  Thu Aug 31 19:46:01 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 31 Aug 2023 19:46:01 GMT
Subject: [lworld] RFR: 8315412 [lworld] Preparing code for lw5 [v2]
In-Reply-To: <E6XPLYmqzPCtGJu-f4khWww1iP7vEMV1oC-Qw-PpSBQ=.e2d8dd51-7166-46a3-8dab-5c051a414a91@github.com>
References: <E6XPLYmqzPCtGJu-f4khWww1iP7vEMV1oC-Qw-PpSBQ=.e2d8dd51-7166-46a3-8dab-5c051a414a91@github.com>
Message-ID: <7_ummO2jCYXdyaPqO1REaEs1QUWRg71k-IDkbfOSi2w=.dc050187-062b-4725-a9a2-7d029ed7c855@github.com>

> Quite a big patch, but it is mostly made of renaming and mechanical replacement without really changing the logic of the code.
> 
> The patch includes changes to make the VM code less dependent on Q-descriptors by encoding the presence of null-free inline types fields in FieldInfo.
> 
> The patch also includes a lot of renaming, in an effort to have uniformed naming of flat fields and flat arrays across the VM. The renaming has not been applied to the heap dumper and C2. They will be addressed in follow up patches.
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Addresing Lois' comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/922/files
  - new: https://git.openjdk.org/valhalla/pull/922/files/9fa21a50..80e6f6c7

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

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

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


From fparain at openjdk.org  Thu Aug 31 19:46:05 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 31 Aug 2023 19:46:05 GMT
Subject: [lworld] RFR: 8315412 [lworld] Preparing code for lw5 [v2]
In-Reply-To: <mGOkPcFsZzADC-Dez1tYfE2k00MXIoioWIB-4qAJODs=.5169dd03-47ee-4565-8371-c84f1d7770b1@github.com>
References: <E6XPLYmqzPCtGJu-f4khWww1iP7vEMV1oC-Qw-PpSBQ=.e2d8dd51-7166-46a3-8dab-5c051a414a91@github.com>
 <mGOkPcFsZzADC-Dez1tYfE2k00MXIoioWIB-4qAJODs=.5169dd03-47ee-4565-8371-c84f1d7770b1@github.com>
Message-ID: <w618Pg6eSwPqn8bRoqWfrwGla0plw83kPZ_56SjC7ms=.1ec3b59a-cf74-43a0-abf9-4588698b32e3@github.com>

On Thu, 31 Aug 2023 18:55:38 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addresing Lois' comments
>
> src/hotspot/share/ci/ciInstanceKlass.cpp line 774:
> 
>> 772:     }
>> 773:     case T_PRIMITIVE_OBJECT: // fall-through
>> 774:     case T_ARRAY:  // fall-through
> 
> Minor nit: do both line 773 & 774 need "fall-through" comment?

The comment in the T_ARRAY case will remain even after the removal of Q-descriptor.
The comment in the T_PRIMITIVE_OBJECT case makes it much easier to see (with grep) that this case is simply going to go away after the removal of Q-descriptors.

> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 697:
> 
>> 695:  *     constraint when flattening this inline type into another container
>> 696:  *   - field flattening decisions are taken in this method (those decisions are
>> 697:  *     currently only based in the size of the fields to be flatten, the size
> 
> flatten -> flattened

Fixed

> src/hotspot/share/oops/cpCache.cpp line 136:
> 
>> 134:                   ((is_volatile ? 1 : 0) << is_volatile_shift) |
>> 135:                   ((is_final    ? 1 : 0) << is_final_shift) |
>> 136:                   ((is_flat  ? 1 : 0) << is_flat_shift) |
> 
> Minor nit, line up ternary expression with lines above

Fixed

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/922#discussion_r1312140567
PR Review Comment: https://git.openjdk.org/valhalla/pull/922#discussion_r1312137715
PR Review Comment: https://git.openjdk.org/valhalla/pull/922#discussion_r1312140683