From mchung at openjdk.org  Mon Apr  1 17:50:48 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 1 Apr 2024 17:50:48 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v7]
In-Reply-To: <_9ZgKwZOXn0leo2Ul4UpE0w6OjlQeLX5Un1LdeXj7wk=.e6d76ae2-01c7-487f-a8d4-a50de8786afa@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <_9ZgKwZOXn0leo2Ul4UpE0w6OjlQeLX5Un1LdeXj7wk=.e6d76ae2-01c7-487f-a8d4-a50de8786afa@github.com>
Message-ID: <hQDRXzpnjSuTr-zAmTj6H-Dl_sFJLaq9WaXDivio9jI=.696384a7-56b5-4c2d-9624-bb7b9b48b37c@github.com>

On Thu, 28 Mar 2024 20:14:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
>> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
>> (The class file format version numbers will need to be updated when re-synching with the mainline).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Preview and non-preview tests cannot be supported by a single test due to compilation of value classes.
>   Moved preview support for access flags to a new test (ClassAccessFlagPreviewTest) to be run only with --enable-preview.
>   Reverted all changes to ClassAccessFlagTest and will only run when not --enable-preview.

Marked as reviewed by mchung (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1060#pullrequestreview-1971790349


From mchung at openjdk.org  Mon Apr  1 17:50:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 1 Apr 2024 17:50:59 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v6]
In-Reply-To: <umzqRNnFmBiB0inOVOAc-fMLxacyduPQdvGqs155ff4=.73cafde7-c892-48d7-adf5-0f92ba466fe6@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <6Y93H65-Wl6C3nB9wlHjFJi9c7GSdioustvjhVpvONY=.2ceb5d8e-73ce-4a39-b43a-dbee3c049331@github.com>
 <0tFCT5l7QRM-X9PKo3lf0YDWQcnI7kLISmj4iV2A-AY=.399b6c8e-1e2e-44af-a7f3-f9320c353084@github.com>
 <umzqRNnFmBiB0inOVOAc-fMLxacyduPQdvGqs155ff4=.73cafde7-c892-48d7-adf5-0f92ba466fe6@github.com>
Message-ID: <ZbzCuXvRXsOhLa5t6RmoykSv1Ewyf2ooSRvo-ICSkS0=.fa8b9a21-7cae-4ecf-a70e-7c725571c513@github.com>

On Thu, 28 Mar 2024 19:07:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 364:
>> 
>>> 362:                public Set<Location> apply(ClassFileFormatVersion cffv) {
>>> 363:                    return (cffv.compareTo(ClassFileFormatVersion.RELEASE_2)  >= 0 &&
>>> 364:                            cffv.compareTo(ClassFileFormatVersion.RELEASE_16) <= 0) ?
>> 
>> I believe we still want to keep the strict field modifier for value class fields.
>
> I dropped it because its not in JEP401 and the feature has not settled yet nor which spec its covered in.

I'm okay either way if you want to make change now or later.   If the testing is good, it's fine to integrate this change and follow up later.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1546639387


From vromero at openjdk.org  Mon Apr  1 17:53:01 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 Apr 2024 17:53:01 GMT
Subject: [lworld] Integrated: 8329400: [lworld] add a test to check that
 IllegalMonitorStateException is thrown for value objects
In-Reply-To: <snOhda1X3CzGRdMMyLjo_j1zDZIIdK6zFaFSCJ4cYxc=.5d6eceb2-3884-4d54-869b-d6eaa7350b01@github.com>
References: <snOhda1X3CzGRdMMyLjo_j1zDZIIdK6zFaFSCJ4cYxc=.5d6eceb2-3884-4d54-869b-d6eaa7350b01@github.com>
Message-ID: <x5E5-NBrPia0t86g7dMzDFsRjmiP1x8fI02heoDLp4s=.764f392f-2f4d-42d7-b034-397e92fdebc8@github.com>

On Mon, 1 Apr 2024 17:27:52 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> just adding a missing regression test

This pull request has now been integrated.

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

8329400: [lworld] add a test to check that IllegalMonitorStateException is thrown for value objects

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

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


From vromero at openjdk.org  Mon Apr  1 17:52:59 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 Apr 2024 17:52:59 GMT
Subject: [lworld] Integrated: 8329400: [lworld] add a test to check that
 IllegalMonitorStateException is thrown for value objects
Message-ID: <snOhda1X3CzGRdMMyLjo_j1zDZIIdK6zFaFSCJ4cYxc=.5d6eceb2-3884-4d54-869b-d6eaa7350b01@github.com>

just adding a missing regression test

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

Commit messages:
 - 8329400: [lworld] add a test to check that IllegalMonitorStateException is thrown for value objects

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

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


From rriggs at openjdk.org  Tue Apr  2 19:16:49 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Apr 2024 19:16:49 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v8]
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <XIt7nTGggfXICvgbm3S_bYsBvslcXBEXWPK-SvYHAiU=.1a370f15-85b2-4b1b-b542-13acefc0c8cb@github.com>

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct copyright text

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1060/files
  - new: https://git.openjdk.org/valhalla/pull/1060/files/c3fb4d85..096ee4ea

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

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

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


From rriggs at openjdk.org  Tue Apr  2 19:35:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Apr 2024 19:35:29 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v9]
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <Zj28We3FIUHKg-8uBOvhzruGC4wUN0-0GEP2VI821Tk=.bc87e586-c77a-4937-80e9-c7f1b31e90db@github.com>

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1060/files
  - new: https://git.openjdk.org/valhalla/pull/1060/files/096ee4ea..137477cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1060&range=08
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1060&range=07-08

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

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


From rriggs at openjdk.org  Wed Apr  3 13:24:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 Apr 2024 13:24:16 GMT
Subject: [lworld] Integrated: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <H9jBuV_9N9HvjrYcVmYFcnd7BxsiQcrj4tqGuQ4lQDY=.66f8be69-014b-4557-9fcb-d247a6f87e50@github.com>

On Fri, 22 Mar 2024 20:12:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

This pull request has now been integrated.

Changeset: af7f7aba
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/af7f7aba57670bacc3f9d556a5554828b4a42c1f
Stats:     399 lines in 16 files changed: 321 ins; 34 del; 44 mod

8328543: [lworld] Library and test updates to use --enable-preview instead of ValhallaFeatures

Reviewed-by: mchung

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

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


From mchung at openjdk.org  Wed Apr  3 16:25:30 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 3 Apr 2024 16:25:30 GMT
Subject: [lworld] RFR: 8329218: [lworld] Arrays.copyOf and Arrays.copyOfRange
 support for null-restricted arrays
Message-ID: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>

`Arrays::copyOf` and `Arrays::copyOfRange` should return a null-restricted array if the input array is null-restricted.   The intrinsification for these methods will need to be updated ([JDK-8329218](https://bugs.openjdk.org/browse/JDK-8329218)).  Three test cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java` are commented out until JDK-8329218 is resolved.

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

Commit messages:
 - Add argument check to NullRestrictedCheckedType::of and NormalCheckedType::of
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into arraysCopyOf
 - comment out the test cases depending on JDK-8329224
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into arraysCopyOf
 - 8329218: [lworld] Arrays.copyOf and Arrays.copyOfRange support for null-restricted arrays

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

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


From liach at openjdk.org  Wed Apr  3 17:15:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Apr 2024 17:15:08 GMT
Subject: [lworld] RFR: 8329218: [lworld] Arrays.copyOf and
 Arrays.copyOfRange support for null-restricted arrays
In-Reply-To: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
References: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
Message-ID: <9PpGYShJvE74tUgGu0B7d2eoWy0xyISUFTVe-bL_gLY=.d27aea38-9d3e-434d-91a4-5ebf0ef4c064@github.com>

On Wed, 3 Apr 2024 16:21:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Arrays::copyOf` and `Arrays::copyOfRange` should return a null-restricted array if the input array is null-restricted.   The intrinsification for these methods will need to be updated ([JDK-8329218](https://bugs.openjdk.org/browse/JDK-8329218)).  Three test cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java` are commented out until JDK-8329218 is resolved.

Just a few questions about current state of NR arrays:
1. Does NR (inlined) array share the same class as their null-friendly (reference) counterparts? Since they have totally different layouts, they probably are distinct enough to guarantee a class split (like a value class with 3 Integer fields vs one with 3 Integer! fields), and how about their System.arraycopy behavior?
2. If they share the same class, will there be overloads of Arrays.copyOf taking `CheckedType`?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1070#issuecomment-2035145542


From mchung at openjdk.org  Wed Apr  3 17:38:07 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 3 Apr 2024 17:38:07 GMT
Subject: [lworld] RFR: 8329218: [lworld] Arrays.copyOf and
 Arrays.copyOfRange support for null-restricted arrays
In-Reply-To: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
References: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
Message-ID: <7iolb2a54ttPFMBnz89ElTRuaAwGOVqNzyPb4PIwe9w=.ac2d40ef-a3e9-4ed5-a8cc-b5197ceab188@github.com>

On Wed, 3 Apr 2024 16:21:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Arrays::copyOf` and `Arrays::copyOfRange` should return a null-restricted array if the input array is null-restricted.   The intrinsification for these methods will need to be updated ([JDK-8329218](https://bugs.openjdk.org/browse/JDK-8329218)).  Three test cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java` are commented out until JDK-8329218 is resolved.

I should clarify.  This change is to enable valhalla tests to continue to use `Arrays::copyOf` for null-restricted arrays.  It's solely implementation change.     lworld does not have the compiler and class file support for null-restricted types which is a separate JEP.   No public API for null-restricted arrays.

To create a null-restricted array, it has to use `jdk.internal.value.ValueClass::newNullRestrictedArray` and `CheckedType` and `NullRestrictedCheckedType` are internal APIs.   `System.arraycopy` should already work for null-restricted arrays.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1070#issuecomment-2035195991


From mchung at openjdk.org  Wed Apr  3 17:50:10 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 3 Apr 2024 17:50:10 GMT
Subject: [lworld] RFR: 8329218: [lworld] Arrays.copyOf and
 Arrays.copyOfRange support for null-restricted arrays
In-Reply-To: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
References: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
Message-ID: <E66rKMcl6uBDtMmE1L1YnGu-kmPoT_2O_Gd6ZF8TAZs=.ba0c0119-16b7-475c-94ea-1992774dba82@github.com>

On Wed, 3 Apr 2024 16:21:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Arrays::copyOf` and `Arrays::copyOfRange` should return a null-restricted array if the input array is null-restricted.   The intrinsification for these methods will need to be updated ([JDK-8329218](https://bugs.openjdk.org/browse/JDK-8329218)).  Three test cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java` are commented out until JDK-8329218 is resolved.

As of now, the class mirror is the same for normal and null-restricted array.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1070#issuecomment-2035219458


From liach at openjdk.org  Wed Apr  3 23:11:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Apr 2024 23:11:08 GMT
Subject: [lworld] RFR: 8329218: [lworld] Arrays.copyOf and
 Arrays.copyOfRange support for null-restricted arrays
In-Reply-To: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
References: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
Message-ID: <J1unpTFQ95dxlKjbpHT_gcedkQoKRoSSm71aFce-a-Q=.068bb4c4-94cb-480f-9cf4-bc6bee48edc1@github.com>

On Wed, 3 Apr 2024 16:21:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Arrays::copyOf` and `Arrays::copyOfRange` should return a null-restricted array if the input array is null-restricted.   The intrinsification for these methods will need to be updated ([JDK-8329218](https://bugs.openjdk.org/browse/JDK-8329218)).  Three test cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java` are commented out until JDK-8329218 is resolved.

Thanks for the explanations. I was curious that the current copyOf implementation doesn't allow specifying if the new array should be NR or not.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1070#issuecomment-2035787206


From rriggs at openjdk.org  Fri Apr  5 18:00:28 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Apr 2024 18:00:28 GMT
Subject: [lworld] RFR: 8329795: [lworld] Remove the jdk internal
 ValhallaFeatures test api
Message-ID: <bsHTmo4iP6xbm591zkvHDRRjTe6vFc2L5RcNAiUcz-E=.1d508b48-dffc-49e7-ad2d-817d2a0882a5@github.com>

The api point jdk.internal.misc.ValhallaFeatures has been replaced by `--enable-preview` and `jdk.internal.misc.PreviewFeatures` and can be removed. 

The supporting files and test are removed.

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

Commit messages:
 - 8329795: [lworld] Remove the jdk internal ValhallaFeatures test api

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

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


From rriggs at openjdk.org  Fri Apr  5 18:26:15 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Apr 2024 18:26:15 GMT
Subject: [lworld] RFR: 8329218: [lworld] Arrays.copyOf and
 Arrays.copyOfRange support for null-restricted arrays
In-Reply-To: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
References: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
Message-ID: <9atI_d0E07H794wi1nRQQgM738yxO13j1FkDzF1EMls=.ba0d54c3-1f0c-4a9a-bfd3-c89f7a18eca3@github.com>

On Wed, 3 Apr 2024 16:21:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Arrays::copyOf` and `Arrays::copyOfRange` should return a null-restricted array if the input array is null-restricted.   The intrinsification for these methods will need to be updated ([JDK-8329218](https://bugs.openjdk.org/browse/JDK-8329218)).  Three test cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java` are commented out until JDK-8329218 is resolved.

LGTM

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1070#pullrequestreview-1983859986


From mchung at openjdk.org  Fri Apr  5 19:13:21 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 19:13:21 GMT
Subject: [lworld] RFR: 8329795: [lworld] Remove the jdk internal
 ValhallaFeatures test api
In-Reply-To: <bsHTmo4iP6xbm591zkvHDRRjTe6vFc2L5RcNAiUcz-E=.1d508b48-dffc-49e7-ad2d-817d2a0882a5@github.com>
References: <bsHTmo4iP6xbm591zkvHDRRjTe6vFc2L5RcNAiUcz-E=.1d508b48-dffc-49e7-ad2d-817d2a0882a5@github.com>
Message-ID: <NaoGNcd4qpJuaCpugVUzgoIVVDCdwROWpmKRp2t0fyg=.18802051-8ccb-4813-80e9-d71f7450ee31@github.com>

On Fri, 5 Apr 2024 17:55:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The api point jdk.internal.misc.ValhallaFeatures has been replaced by `--enable-preview` and `jdk.internal.misc.PreviewFeatures` and can be removed. 
> 
> The supporting files and test are removed.

Marked as reviewed by mchung (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1071#pullrequestreview-1984007457


From mchung at openjdk.org  Fri Apr  5 19:18:08 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 19:18:08 GMT
Subject: [lworld] RFR: 8329795: [lworld] Remove the jdk internal
 ValhallaFeatures test api
In-Reply-To: <bsHTmo4iP6xbm591zkvHDRRjTe6vFc2L5RcNAiUcz-E=.1d508b48-dffc-49e7-ad2d-817d2a0882a5@github.com>
References: <bsHTmo4iP6xbm591zkvHDRRjTe6vFc2L5RcNAiUcz-E=.1d508b48-dffc-49e7-ad2d-817d2a0882a5@github.com>
Message-ID: <76iX47AUY-aCCbib0zKe4xQ0SC9QTeWvUCTVnz8Fq-4=.7a903bfd-f642-488d-9e1c-b45d2269007a@github.com>

On Fri, 5 Apr 2024 17:55:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The api point jdk.internal.misc.ValhallaFeatures has been replaced by `--enable-preview` and `jdk.internal.misc.PreviewFeatures` and can be removed. 
> 
> The supporting files and test are removed.

Thanks for the update.  Looks good.

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

Marked as reviewed by mchung (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1071#pullrequestreview-1984014728


From mchung at openjdk.org  Fri Apr  5 20:55:09 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Apr 2024 20:55:09 GMT
Subject: [lworld] Integrated: 8329218: [lworld] Arrays.copyOf and
 Arrays.copyOfRange support for null-restricted arrays
In-Reply-To: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
References: <Av74UuUUu9pmaCavKyhGExD2Lh2VoIfhF3rCZ3cwpjs=.0d341cf0-24ad-4aac-aaca-0cafaa0e9a79@github.com>
Message-ID: <QfdW-Dhp8Wz5M0IHcmFyVOqXRUSBIm6TI5EXP8-T01k=.a060d04b-b9a5-465e-b9ae-2a780abcd2c8@github.com>

On Wed, 3 Apr 2024 16:21:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Arrays::copyOf` and `Arrays::copyOfRange` should return a null-restricted array if the input array is null-restricted.   The intrinsification for these methods will need to be updated ([JDK-8329218](https://bugs.openjdk.org/browse/JDK-8329218)).  Three test cases in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java` are commented out until JDK-8329218 is resolved.

This pull request has now been integrated.

Changeset: 221b1da7
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/221b1da7224356c3555c68718a893a876317aac8
Stats:     118 lines in 6 files changed: 91 ins; 11 del; 16 mod

8329218: [lworld] Arrays.copyOf and Arrays.copyOfRange support for null-restricted arrays

Reviewed-by: rriggs

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

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


From jbossons at gmail.com  Mon Apr  8 02:30:44 2024
From: jbossons at gmail.com (John Bossons)
Date: Sun, 7 Apr 2024 22:30:44 -0400
Subject: Implementation of == and Object::equals
Message-ID: <CACvEv_zm=B8X4DJ=y4LFSaRo6HJezV+WKFw0q-GWcyb_LZJyew@mail.gmail.com>

I'm not sure that this is the right place to raise this, but don't know
where else to do so.

For identity types, == is simply a test of reference equality and so is a
useful first test in an overriding type-specific equals method.

For value types, the relationship is more subtle, since == is a test of
value equality, not reference equality. I suggest it be implemented as an
operator causing Object::equals to be invoked, so that if Object::equals is
overloaded (e.g. to first test equality of hash codes or otherwise modify
the default equals test), the overloaded method is automatically invoked
when == is used.

This would mean that Object::equals implements the == operator, rather than
the reverse, so that a specification that a == b always means a.equals(b),
whether implemented by the default test or by an overriding type-specific
method (that e.g. tests for equality of identity object field values). I
believe this would make value types (especially value trees) easier to use.

John

-- 
Phone:  (416) 450-3584 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240407/04837a91/attachment.htm>

From rriggs at openjdk.org  Mon Apr  8 14:08:14 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Apr 2024 14:08:14 GMT
Subject: [lworld] Integrated: 8329795: [lworld] Remove the jdk internal
 ValhallaFeatures test api
In-Reply-To: <bsHTmo4iP6xbm591zkvHDRRjTe6vFc2L5RcNAiUcz-E=.1d508b48-dffc-49e7-ad2d-817d2a0882a5@github.com>
References: <bsHTmo4iP6xbm591zkvHDRRjTe6vFc2L5RcNAiUcz-E=.1d508b48-dffc-49e7-ad2d-817d2a0882a5@github.com>
Message-ID: <MAuthdHgEjc_uWHnS4yLsRaiBlChyZcP-En_8-6sgcw=.bb1454f9-aa18-4869-863f-f28efb25c254@github.com>

On Fri, 5 Apr 2024 17:55:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The api point jdk.internal.misc.ValhallaFeatures has been replaced by `--enable-preview` and `jdk.internal.misc.PreviewFeatures` and can be removed. 
> 
> The supporting files and test are removed.

This pull request has now been integrated.

Changeset: 7333d293
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7333d29303918ad02e515d3e671afe1e909a3e39
Stats:     150 lines in 3 files changed: 0 ins; 150 del; 0 mod

8329795: [lworld] Remove the jdk internal ValhallaFeatures test api

Reviewed-by: mchung

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

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


From roger.riggs at oracle.com  Mon Apr  8 14:25:25 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 8 Apr 2024 10:25:25 -0400
Subject: Implementation of == and Object::equals
In-Reply-To: <CACvEv_zm=B8X4DJ=y4LFSaRo6HJezV+WKFw0q-GWcyb_LZJyew@mail.gmail.com>
References: <CACvEv_zm=B8X4DJ=y4LFSaRo6HJezV+WKFw0q-GWcyb_LZJyew@mail.gmail.com>
Message-ID: <d64f661e-87a9-4479-8fb7-ff651c023515@oracle.com>

Hi John,

This is covered under discussions of ==, specified in the VM spec as 
implemented by the "acmp" bytecode
and described as "same"ness or "substitutability" on the 
valhalla-spec-experts archive.

The discussion of substitutability for float and double along with more 
general principles were discussed in February 2024.
See the archives for details: 
https://mail.openjdk.org/pipermail/valhalla-spec-experts/2024-February/subject.html

Regards, Roger

On 4/7/24 10:30 PM, John Bossons wrote:
> I'm not sure that this is the right place to raise this, but don't 
> know where else to do so.
>
> For identity types, == is simply a test of reference equality and so 
> is a useful first test in an overriding type-specific equals method.
>
> For value types, the relationship is more subtle, since == is a test 
> of value equality,?not reference equality. I suggest it be implemented 
> as an operator causing Object::equals to be invoked, so that if 
> Object::equals is overloaded (e.g. to first test equality of hash 
> codes or otherwise modify the default equals test), the overloaded 
> method is automatically invoked when == is used.
>
> This would mean that Object::equals implements the == operator, rather 
> than the reverse, so that a specification that a == b always means 
> a.equals(b), whether implemented by the default test or by an 
> overriding type-specific method (that e.g. tests for equality of 
> identity object field values). I believe this would make value types 
> (especially value trees) easier to use.
>
> John
>
> -- 
> Phone:? (416) 450-3584 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240408/2db83cc7/attachment.htm>

From forax at univ-mlv.fr  Tue Apr  9 11:09:21 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 9 Apr 2024 13:09:21 +0200 (CEST)
Subject: Implementation of == and Object::equals
In-Reply-To: <CACvEv_zm=B8X4DJ=y4LFSaRo6HJezV+WKFw0q-GWcyb_LZJyew@mail.gmail.com>
References: <CACvEv_zm=B8X4DJ=y4LFSaRo6HJezV+WKFw0q-GWcyb_LZJyew@mail.gmail.com>
Message-ID: <225116462.52636008.1712660961086.JavaMail.zimbra@univ-eiffel.fr>

> From: "John Bossons" <jbossons at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Monday, April 8, 2024 4:30:44 AM
> Subject: Implementation of == and Object::equals
Hi John, 
adding to what Roger said, 

> I'm not sure that this is the right place to raise this, but don't know where
> else to do so.
> For identity types, == is simply a test of reference equality and so is a useful
> first test in an overriding type-specific equals method.

No, it's a bad idea performance-wise. 
see https://youtu.be/kuzjX_efuDs?list=PLX8CzqL3ArzV4BpOzLanxd4bZr46x5e87 

> For value types, the relationship is more subtle, since == is a test of value
> equality, not reference equality. I suggest it be implemented as an operator
> causing Object::equals to be invoked, so that if Object::equals is overloaded
> (e.g. to first test equality of hash codes or otherwise modify the default
> equals test), the overloaded method is automatically invoked when == is used.

> This would mean that Object::equals implements the == operator, rather than the
> reverse, so that a specification that a == b always means a.equals(b), whether
> implemented by the default test or by an overriding type-specific method (that
> e.g. tests for equality of identity object field values). I believe this would
> make value types (especially value trees) easier to use.

Two things, (1) the semantics of equals() on a class (value or identity) is stronger than the semantics of == on a value class, (2) what you propose introduce a circularity between == and equals, so if equals itslef uses ==, it's an infinite loop. 

Imagine you have a value class defined like this: 
value class MyValueClass { 
String s; 

public boolean equals(Object o) { 
return o instanceof MyValueClass other && s.equals(other.s); 
} 
} 

1) calling == on an instance of MyValueClass should check if s == other.s, not calling s.equals(other.s) on the field "field" so the semantics of == is different from the semantics of equals. 

2) if we write equals like that and == calls equals() 
public boolean equals(Object o) { 
return this == o && o instanceof MyValueClass v && field.equals(v.field); 
} 

we have an infinite loop. 

That's why == on value type is defined as doing == on each field and not as calling equals on each field. 

That's said, in the future, for some value types, we may let users to be able to override == and identity hashCode so anyone can write it's own primitive type, but it will not be the default behavior and we are not there yet. 

> John

regards, 
R?mi 

> --
> Phone: (416) 450-3584 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240409/95a2672b/attachment.htm>

From jbossons at gmail.com  Tue Apr  9 13:01:47 2024
From: jbossons at gmail.com (John Bossons)
Date: Tue, 9 Apr 2024 09:01:47 -0400
Subject: Implementation of == and Object::equals
In-Reply-To: <225116462.52636008.1712660961086.JavaMail.zimbra@univ-eiffel.fr>
References: <CACvEv_zm=B8X4DJ=y4LFSaRo6HJezV+WKFw0q-GWcyb_LZJyew@mail.gmail.com>
 <225116462.52636008.1712660961086.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CACvEv_yWaaLdkdNcLQKpGwrXVdgFY0h_Q98dSvwGvzS0ZN8C7Q@mail.gmail.com>

Thanks, Remi. Very interesting, more than answers my question!

John

On Tue, Apr 9, 2024 at 7:09?AM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"John Bossons" <jbossons at gmail.com>
> *To: *"valhalla-dev" <valhalla-dev at openjdk.org>
> *Sent: *Monday, April 8, 2024 4:30:44 AM
> *Subject: *Implementation of == and Object::equals
>
>
> Hi John,
> adding to what Roger said,
>
>
> I'm not sure that this is the right place to raise this, but don't know
> where else to do so.
> For identity types, == is simply a test of reference equality and so is a
> useful first test in an overriding type-specific equals method.
>
>
> No, it's a bad idea performance-wise.
> see https://youtu.be/kuzjX_efuDs?list=PLX8CzqL3ArzV4BpOzLanxd4bZr46x5e87
>
>
> For value types, the relationship is more subtle, since == is a test of
> value equality, not reference equality. I suggest it be implemented as an
> operator causing Object::equals to be invoked, so that if Object::equals is
> overloaded (e.g. to first test equality of hash codes or otherwise modify
> the default equals test), the overloaded method is automatically invoked
> when == is used.
>
> This would mean that Object::equals implements the == operator, rather
> than the reverse, so that a specification that a == b always means
> a.equals(b), whether implemented by the default test or by an overriding
> type-specific method (that e.g. tests for equality of identity object field
> values). I believe this would make value types (especially value trees)
> easier to use.
>
>
> Two things, (1) the semantics of equals() on a class (value or identity)
> is stronger than the semantics of == on a value class, (2) what you propose
> introduce a circularity between == and equals, so if equals itslef uses ==,
> it's an infinite loop.
>
> Imagine you have a value class defined like this:
>   value class MyValueClass {
>     String s;
>
>     public boolean equals(Object o) {
>       return o instanceof MyValueClass other && s.equals(other.s);
>     }
>   }
>
> 1) calling == on an instance of MyValueClass should check if s == other.s,
> not calling s.equals(other.s) on the field "field" so the semantics of ==
> is different from the semantics of equals.
>
> 2) if we write equals like that and == calls equals()
>
>    public boolean equals(Object o) {
>       return this == o && o instanceof MyValueClass v &&
> field.equals(v.field);
>     }
>
> we have an infinite loop.
>
> That's why == on value type is defined as doing == on each field and not
> as calling equals on each field.
>
> That's said, in the future, for some value types, we may let users to be
> able to override == and identity hashCode so anyone can write it's own
> primitive type, but it will not be the default behavior and we are not
> there yet.
>
>
> John
>
>
> regards,
> R?mi
>
>
> --
> Phone:  (416) 450-3584 (cell)
>
>

-- 
Phone:  (416) 450-3584 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240409/ae2bf3e8/attachment.htm>

From forax at univ-mlv.fr  Tue Apr  9 20:50:04 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 9 Apr 2024 22:50:04 +0200 (CEST)
Subject: Einherjar
Message-ID: <734592800.53333681.1712695804832.JavaMail.zimbra@univ-eiffel.fr>

Hello,
i've written a small tool that let you annotate your Java 8+ code with an annotation (@ValueType by default), verifies that the annotated classes can be transformed to a value classes in the future and even enhance a jar to forward port the annotated classes to be value types when used with a the Valhalla VM.

https://github.com/forax/einherjar

@Kevin, I think this is close top what you describe on the spec-expert mailing list.

regards,
R?mi

PS: this is a raw first version, when the first preview of Valhalla will be released, i will be able to do more tests.


From andvasp at gmail.com  Wed Apr 10 10:19:12 2024
From: andvasp at gmail.com (Anderson Vasconcelos Pires)
Date: Wed, 10 Apr 2024 07:19:12 -0300
Subject: Einherjar
In-Reply-To: <734592800.53333681.1712695804832.JavaMail.zimbra@univ-eiffel.fr>
References: <734592800.53333681.1712695804832.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CACB8oqXU9_4LksxsQHLK50ySfVXuFPHF9YZrNBUC__j0DsoD1A@mail.gmail.com>

Hi Remi,

This is really great!

I was wondering about a tool like this since your email "Civilizer - let's
civilize those primitive types !" [1]

I believe that most libraries will not be able to release versions that can
use directly value types. So this tool will help a lot.

Best regards,
Anderson.

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

On Tue, Apr 9, 2024 at 5:51?PM Remi Forax <forax at univ-mlv.fr> wrote:

> Hello,
> i've written a small tool that let you annotate your Java 8+ code with an
> annotation (@ValueType by default), verifies that the annotated classes can
> be transformed to a value classes in the future and even enhance a jar to
> forward port the annotated classes to be value types when used with a the
> Valhalla VM.
>
> https://github.com/forax/einherjar
>
> @Kevin, I think this is close top what you describe on the spec-expert
> mailing list.
>
> regards,
> R?mi
>
> PS: this is a raw first version, when the first preview of Valhalla will
> be released, i will be able to do more tests.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240410/23a1b85b/attachment.htm>

From thartmann at openjdk.org  Thu Apr 11 13:10:12 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Apr 2024 13:10:12 GMT
Subject: [lworld] RFR: 8329196: [lworld] More fixes to value object
 construction in C2 [v3]
In-Reply-To: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
References: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
Message-ID: <yvNFt7clooFsPdRCr2F8MN4bGZbzl0udtS7MFnRL33U=.1346df4c-bd9d-43c2-beef-526cf18c2f16@github.com>

> Follow-up from [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660). We can't rely on `GraphKit::replace_in_map` to reliably replace an InlineTypeNode that is initialized in the constructor in the caller map because there can be data flow merges. Instead, we need to explicitly update the node in the exit map. I added corresponding regression tests.
> 
> I also noticed that we are extensively cloning InlineTypeNodes during parsing, which often leads to an explosion of redundant nodes that then need to be removed. I added `InlineTypeNode::clone_if_required` to mitigate this, this can probably be further improved (I added corresponding ToDo's).
> 
> There are still issues with deoptimization from the constructor (`-XX:+DeoptimizeALot`). I'll address these in another fix.
> 
> I also disabled an IR rule in `TestZGCBarrierElision`. The issue will be fixed by [JDK-8329234](https://bugs.openjdk.org/browse/JDK-8329234).
> 
> Thanks,
> Tobias

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

  Fixing constructor to constructor calls and added more tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1064/files
  - new: https://git.openjdk.org/valhalla/pull/1064/files/d12ce386..b18ec2fe

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

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

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


From thartmann at openjdk.org  Thu Apr 11 13:25:21 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Apr 2024 13:25:21 GMT
Subject: [lworld] RFR: 8329196: [lworld] More fixes to value object
 construction in C2 [v4]
In-Reply-To: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
References: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
Message-ID: <AoPKQ_nDEFh3BLxOCAQbYpUnv3lUuYf4he-V8FsuhaA=.8dbc510e-93c9-4e30-83a1-3e7e7ef8a30e@github.com>

> Follow-up from [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660). We can't rely on `GraphKit::replace_in_map` to reliably replace an InlineTypeNode that is initialized in the constructor in the caller map because there can be data flow merges. Instead, we need to explicitly update the node in the exit map. I added corresponding regression tests.
> 
> I also noticed that we are extensively cloning InlineTypeNodes during parsing, which often leads to an explosion of redundant nodes that then need to be removed. I added `InlineTypeNode::clone_if_required` to mitigate this, this can probably be further improved (I added corresponding ToDo's).
> 
> There are still issues with deoptimization from the constructor (`-XX:+DeoptimizeALot`). I'll address these in another fix.
> 
> I also disabled an IR rule in `TestZGCBarrierElision`. The issue will be fixed by [JDK-8329234](https://bugs.openjdk.org/browse/JDK-8329234).
> 
> Thanks,
> Tobias

Tobias Hartmann 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 seven additional commits since the last revision:

 - Merge branch 'lworld' into JDK-8329196
 - Fixing constructor to constructor calls and added more tests
 - Handling abstract value class constructors with arguments
 - Disabled IR verification due to JDK-8329234
 - Merge branch 'lworld' into JDK-8329196
 - More fixes, refactoring
 - First prototype

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1064/files
  - new: https://git.openjdk.org/valhalla/pull/1064/files/b18ec2fe..610c6aa4

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

  Stats: 1872 lines in 63 files changed: 621 ins; 1081 del; 170 mod
  Patch: https://git.openjdk.org/valhalla/pull/1064.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1064/head:pull/1064

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


From thartmann at openjdk.org  Thu Apr 11 14:01:24 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Apr 2024 14:01:24 GMT
Subject: [lworld] Integrated: [lworld] Fixing compiler tests failing after
 JDK-8328543
Message-ID: <7Ak5yKPlNC5C9AJenDU1WF0MBV_h82dy5dd3Rd37gtM=.d99d2f90-b110-466b-8726-fd15e3f28fef@github.com>

Tests fail after [JDK-8328543](https://bugs.openjdk.org/browse/JDK-8328543) got integrated.

Thanks,
Tobias

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

Commit messages:
 - [lworld] Fixing compiler tests failing after JDK-8328543

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

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


From thartmann at openjdk.org  Thu Apr 11 14:01:24 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Apr 2024 14:01:24 GMT
Subject: [lworld] Integrated: [lworld] Fixing compiler tests failing after
 JDK-8328543
In-Reply-To: <7Ak5yKPlNC5C9AJenDU1WF0MBV_h82dy5dd3Rd37gtM=.d99d2f90-b110-466b-8726-fd15e3f28fef@github.com>
References: <7Ak5yKPlNC5C9AJenDU1WF0MBV_h82dy5dd3Rd37gtM=.d99d2f90-b110-466b-8726-fd15e3f28fef@github.com>
Message-ID: <tjM10pCV20sn5X9hrf2MUsL0ftcR2h1rfVlVm3yz80o=.00f8acc0-ad35-463d-98b9-9ee6db5b8949@github.com>

On Thu, 11 Apr 2024 13:56:13 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Tests fail after [JDK-8328543](https://bugs.openjdk.org/browse/JDK-8328543) got integrated.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

[lworld] Fixing compiler tests failing after JDK-8328543

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

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


From thartmann at openjdk.org  Thu Apr 11 14:39:03 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Apr 2024 14:39:03 GMT
Subject: [lworld] Integrated: 8329196: [lworld] More fixes to value object
 construction in C2
In-Reply-To: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
References: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
Message-ID: <Ny8YGKXU0nHrMW4kquFB5CWOXl48Id_vrlm5JYSEgOs=.ac5ed686-485e-479c-96c8-22b1d8f24c90@github.com>

On Wed, 27 Mar 2024 15:54:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Follow-up from [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660). We can't rely on `GraphKit::replace_in_map` to reliably replace an InlineTypeNode that is initialized in the constructor in the caller map because there can be data flow merges. Instead, we need to explicitly update the node in the exit map. I added corresponding regression tests.
> 
> I also noticed that we are extensively cloning InlineTypeNodes during parsing, which often leads to an explosion of redundant nodes that then need to be removed. I added `InlineTypeNode::clone_if_required` to mitigate this, this can probably be further improved (I added corresponding ToDo's).
> 
> There are still issues with deoptimization from the constructor (`-XX:+DeoptimizeALot`). I'll address these in another fix.
> 
> I also disabled an IR rule in `TestZGCBarrierElision`. The issue will be fixed by [JDK-8329234](https://bugs.openjdk.org/browse/JDK-8329234).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: e01ec832
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e01ec832189453cc302c7ca8915e69bb63a3d4b1
Stats:     304 lines in 14 files changed: 249 ins; 10 del; 45 mod

8329196: [lworld] More fixes to value object construction in C2

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

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


From jbhateja at openjdk.org  Mon Apr 15 07:27:49 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 15 Apr 2024 07:27:49 GMT
Subject: [lworld+vector] RFR: Merge lworld
Message-ID: <OvHK15_xdRNWBIw-IBjIF5T91voRBwKvFXlAHIWlmVA=.f2736a8d-00fb-474a-b128-6153643ef20d@github.com>

Merge from lworld to bring in changes w.r.t to new code model as per revised JEP 401 specification.

All the Vector API and Valhalla jtreg tests are passing at various AVX levels.

There are few failures with -XX:+DeoptimizeALot, explicit sub-tasks for issues to be addressed post merge have been added to existing bug report [JDK-8327435](https://bugs.openjdk.org/browse/JDK-8327435) related to JEP alignment.

Best Regards,
Jatin

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

Commit messages:
 - Adding space.
 - Changes for alignment with new code model.
 - Merge branch 'lworld' of http://github.com/openjdk/valhalla into merge_from_lworld
 - 8329196: [lworld] More fixes to value object construction in C2
 - [lworld] Fixing compiler tests failing after JDK-8328543
 - 8329795: [lworld] Remove the jdk internal ValhallaFeatures test api
 - 8329218: [lworld] Arrays.copyOf and Arrays.copyOfRange support for null-restricted arrays
 - 8328543: [lworld] Library and test updates to use --enable-preview instead of ValhallaFeatures
 - 8329400: [lworld] add a test to check that IllegalMonitorStateException is thrown for value objects
 - 8304168: [lworld] CDS tests fail with --enable-preview patched value classes
 - ... and 772 more: https://git.openjdk.org/valhalla/compare/ff8a4159...08ea01fc

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

Changes: https://git.openjdk.org/valhalla/pull/1073/files
  Stats: 777910 lines in 4901 files changed: 158514 ins; 525732 del; 93664 mod
  Patch: https://git.openjdk.org/valhalla/pull/1073.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1073/head:pull/1073

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


From jbhateja at openjdk.org  Mon Apr 15 08:03:28 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 15 Apr 2024 08:03:28 GMT
Subject: [lworld+vector] RFR: Merge lworld [v2]
In-Reply-To: <OvHK15_xdRNWBIw-IBjIF5T91voRBwKvFXlAHIWlmVA=.f2736a8d-00fb-474a-b128-6153643ef20d@github.com>
References: <OvHK15_xdRNWBIw-IBjIF5T91voRBwKvFXlAHIWlmVA=.f2736a8d-00fb-474a-b128-6153643ef20d@github.com>
Message-ID: <RVUrCN6KVb31fWeYdonmiaWy7QUlkzCWxDuwLPJRqMw=.8615357c-929f-43f9-a266-95f585700ee7@github.com>

> Merge from lworld to bring in changes w.r.t to new code model as per revised JEP 401 specification.
> 
> All the Vector API and Valhalla jtreg tests are passing at various AVX levels.
> 
> There are few failures with -XX:+DeoptimizeALot, explicit sub-tasks for issues to be addressed post merge have been added to existing bug report [JDK-8327435](https://bugs.openjdk.org/browse/JDK-8327435) related to JEP alignment.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Adding space.
 - Changes for alignment with new code model.
 - Merge branch 'lworld' of http://github.com/openjdk/valhalla into merge_from_lworld
 - JDK 8327435: [lworld+vector] Align existing Vector API support with JEP 401
 - Merge lworld
 - 8319945: [lworld+vector] Fix vector api jtreg crash with "-XX:-EnableVectorSupport"
   
   Reviewed-by: jbhateja
 - 8319972: [lworld+vector] Enable intrinsification of Unsafe.finishPrivateBuffer.
   
   Reviewed-by: xgong
 - 8319971: [lworld+vector] Fallback implementation cleanups.
   
   Reviewed-by: xgong
 - 8311675: [lworld+vector] Max Species support.
   
   Reviewed-by: xgong
 - 8317699: [lworld+vector] Fix Vector API tests crash with "assert(vbox->is_Phi()) failed: should be phi"
   
   Reviewed-by: jbhateja
 - ... and 12 more: https://git.openjdk.org/valhalla/compare/e01ec832...08ea01fc

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

Changes: https://git.openjdk.org/valhalla/pull/1073/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1073&range=01
  Stats: 12033 lines in 267 files changed: 4581 ins; 2627 del; 4825 mod
  Patch: https://git.openjdk.org/valhalla/pull/1073.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1073/head:pull/1073

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


From jbhateja at openjdk.org  Mon Apr 15 08:03:31 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 15 Apr 2024 08:03:31 GMT
Subject: [lworld+vector] Integrated: Merge lworld
In-Reply-To: <OvHK15_xdRNWBIw-IBjIF5T91voRBwKvFXlAHIWlmVA=.f2736a8d-00fb-474a-b128-6153643ef20d@github.com>
References: <OvHK15_xdRNWBIw-IBjIF5T91voRBwKvFXlAHIWlmVA=.f2736a8d-00fb-474a-b128-6153643ef20d@github.com>
Message-ID: <vv0NOANqflh0ArFcvzvo3aiLyWoI8SreWdEDrjKr6CU=.43fe6e52-5ddc-4b24-b760-ec725b5ff7db@github.com>

On Mon, 15 Apr 2024 06:51:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld to bring in changes w.r.t to new code model as per revised JEP 401 specification.
> 
> All the Vector API and Valhalla jtreg tests are passing at various AVX levels.
> 
> There are few failures with -XX:+DeoptimizeALot, explicit sub-tasks for issues to be addressed post merge have been added to existing bug report [JDK-8327435](https://bugs.openjdk.org/browse/JDK-8327435) related to JEP alignment.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: e406cacb
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e406cacbe3cfdbe99bd06375c8e0991927e896eb
Stats:     777910 lines in 4901 files changed: 158514 ins; 525732 del; 93664 mod

Merge lworld

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

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


From dsimms at openjdk.org  Tue Apr 16 09:38:05 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Apr 2024 09:38:05 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <wIEteQre-EKQWH7G-ko0_AGbxiuWGuk6QaHEujvnU0Q=.48645927-41eb-49d2-9cc7-05537b5dcc03@github.com>

Merge 'jdk-22+26'

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

Commit messages:
 - AccessFlag.SUPER used without preview check (including classfile version minor, implicitly set)
 - Merge tag 'jdk-22+26' into lworld_merge_jdk_22_26
 - 8320945: problemlist tests failing on latest Windows 11 update
 - 8210410: Refactor java.util.Currency:i18n shell tests to plain java tests
 - 8320942: Only set openjdk-target when cross compiling linux-aarch64
 - 8320937: support latest VS2022 MSC_VER in abstract_vm_version.cpp
 - 8319444: Unhelpful failure output in TestLegalNotices
 - 8313816: Accessing jmethodID might lead to spurious crashes
 - 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency support
 - 8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes
 - ... and 106 more: https://git.openjdk.org/valhalla/compare/e01ec832...e296f9bc

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

Changes: https://git.openjdk.org/valhalla/pull/1074/files
  Stats: 14953 lines in 621 files changed: 9926 ins; 2909 del; 2118 mod
  Patch: https://git.openjdk.org/valhalla/pull/1074.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1074/head:pull/1074

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


From dsimms at openjdk.org  Tue Apr 16 11:01:42 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Apr 2024 11:01:42 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <wIEteQre-EKQWH7G-ko0_AGbxiuWGuk6QaHEujvnU0Q=.48645927-41eb-49d2-9cc7-05537b5dcc03@github.com>
References: <wIEteQre-EKQWH7G-ko0_AGbxiuWGuk6QaHEujvnU0Q=.48645927-41eb-49d2-9cc7-05537b5dcc03@github.com>
Message-ID: <kAlAv8msmKkfOmFL8nNrxHh3WuIdFuixh2ZLbaPL0pA=.9efd7493-f86c-40bc-ba98-d95633811d3e@github.com>

> Merge 'jdk-22+26'

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

  Conditionally use SUPER/IDENTITY when generating bytecode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1074/files
  - new: https://git.openjdk.org/valhalla/pull/1074/files/e296f9bc..f4f61a58

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

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

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


From vromero at openjdk.org  Tue Apr 16 18:44:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Apr 2024 18:44:32 GMT
Subject: [lworld] Integrated: 8330391: [lworld] minor code clean-up
Message-ID: <XAxNUNOrg67NLHLdgE_RxAFiM1h4pnQ9JJeABmdM_5A=.63930519-f3bd-4503-a414-5b5a0dc5e686@github.com>

removing dead code

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

Commit messages:
 - 8330391: [lworld] minor code clean-up

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

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


From vromero at openjdk.org  Tue Apr 16 18:44:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Apr 2024 18:44:32 GMT
Subject: [lworld] Integrated: 8330391: [lworld] minor code clean-up
In-Reply-To: <XAxNUNOrg67NLHLdgE_RxAFiM1h4pnQ9JJeABmdM_5A=.63930519-f3bd-4503-a414-5b5a0dc5e686@github.com>
References: <XAxNUNOrg67NLHLdgE_RxAFiM1h4pnQ9JJeABmdM_5A=.63930519-f3bd-4503-a414-5b5a0dc5e686@github.com>
Message-ID: <gxkvDWLau4ssHs6jsEMhDdvO7XvUai2RhQldznoVDdI=.56cac06c-7c9e-40e2-8e88-8c7865bfa9a7@github.com>

On Tue, 16 Apr 2024 18:38:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> removing dead code

This pull request has now been integrated.

Changeset: 3151d4bf
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3151d4bf96d4d3634220399e90f39389f571ca93
Stats:     10 lines in 2 files changed: 0 ins; 10 del; 0 mod

8330391: [lworld] minor code clean-up

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

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


From dsimms at openjdk.org  Wed Apr 17 08:03:15 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 17 Apr 2024 08:03:15 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <wIEteQre-EKQWH7G-ko0_AGbxiuWGuk6QaHEujvnU0Q=.48645927-41eb-49d2-9cc7-05537b5dcc03@github.com>
References: <wIEteQre-EKQWH7G-ko0_AGbxiuWGuk6QaHEujvnU0Q=.48645927-41eb-49d2-9cc7-05537b5dcc03@github.com>
Message-ID: <hVlYRe_WYqsDfDSupRytQhTS3kh_fG-oxzNp6HDpKo8=.0a773150-b611-4f67-adb4-2769b3cd6eee@github.com>

On Tue, 16 Apr 2024 09:28:36 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge 'jdk-22+26'

This pull request has now been integrated.

Changeset: b73b512f
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b73b512f115ef59c48a0b6c0612cde725bc5e377
Stats:     14954 lines in 621 files changed: 9927 ins; 2909 del; 2118 mod

Merge jdk

Merge jdk-22+26

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

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


From fparain at openjdk.org  Thu Apr 18 13:41:39 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 18 Apr 2024 13:41:39 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules
Message-ID: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>

Small changes to implement new field modifiers rules (JVMS 4.5 Fields) related to ACC_STRICT.
Those changes trigger some test failures because of a bug in javac related to final synthetic field. This bug is tracked by JDK-8330583.

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

Commit messages:
 - Add new field modifiers rules (ACC_STRICT)

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

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


From fparain at openjdk.org  Thu Apr 18 13:46:22 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 18 Apr 2024 13:46:22 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules
In-Reply-To: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
Message-ID: <qQAlx5AffGaJf8b2iUjNnU5RQ57aj6PiMSuFdlD4pnw=.b5e21df9-0ed6-4690-a2e9-62035464d118@github.com>

On Thu, 18 Apr 2024 13:36:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small changes to implement new field modifiers rules (JVMS 4.5 Fields) related to ACC_STRICT.
> Those changes trigger some test failures because of a bug in javac related to final synthetic field. This bug is tracked by JDK-8330583.

Note that the new field modifiers verification rules are applied only to new class files. The current JVMS draft of JEP 401 doesn't state that the new rules are only for new class files, but after a discussion with Dan Smith, the JVMS will be updated to clarify the behavior for old class files with respect to ACC_STRICT.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1076#issuecomment-2063902257


From dsimms at openjdk.org  Thu Apr 18 14:24:48 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 18 Apr 2024 14:24:48 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <ZXoIIB4rhT3BbvFqTo1BoIhoXIbJPUKmrJ3GOE0xm2I=.4b2c1452-a9a7-46fd-8547-a385d16d43e0@github.com>

Merge jdk-23+0

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

Commit messages:
 - Fix tests after classfile API move to "java.lang"
 - Merge tag 'jdk-23+0' into lworld_merge_jdk_23_0
 - 8319313: G1: Rename G1EvacFailureInjector appropriately
 - 8320370: NMT: Change MallocMemorySnapshot to simplify code.
 - 8321223: Implementation of Scoped Values (Second Preview)
 - 8321001: RISC-V: C2 SignumVF
 - 8316454: JFR break locale settings
 - 8321470: ThreadLocal.nextHashCode can be static final
 - 8321467: MemorySegment.setString(long, String, Charset) throws IAE(Misaligned access)
 - 8321505: JFR: Update views
 - ... and 135 more: https://git.openjdk.org/valhalla/compare/b73b512f...98c9e487

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

Changes: https://git.openjdk.org/valhalla/pull/1077/files
  Stats: 88347 lines in 1725 files changed: 41593 ins; 40224 del; 6530 mod
  Patch: https://git.openjdk.org/valhalla/pull/1077.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1077/head:pull/1077

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


From dsimms at openjdk.org  Thu Apr 18 15:13:27 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 18 Apr 2024 15:13:27 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <ZXoIIB4rhT3BbvFqTo1BoIhoXIbJPUKmrJ3GOE0xm2I=.4b2c1452-a9a7-46fd-8547-a385d16d43e0@github.com>
References: <ZXoIIB4rhT3BbvFqTo1BoIhoXIbJPUKmrJ3GOE0xm2I=.4b2c1452-a9a7-46fd-8547-a385d16d43e0@github.com>
Message-ID: <6epXSHHuFDpaUh1_R_3PT0uqxUuWFABK1wPxBgovzNA=.a2427f9b-166a-43d8-b959-2c651e548a88@github.com>

> Merge jdk-23+0

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

  Old "ClassFile" name (from "Classfile")

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1077/files
  - new: https://git.openjdk.org/valhalla/pull/1077/files/98c9e487..4b531eba

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

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

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


From dsimms at openjdk.org  Fri Apr 19 09:57:33 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 19 Apr 2024 09:57:33 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <ZXoIIB4rhT3BbvFqTo1BoIhoXIbJPUKmrJ3GOE0xm2I=.4b2c1452-a9a7-46fd-8547-a385d16d43e0@github.com>
References: <ZXoIIB4rhT3BbvFqTo1BoIhoXIbJPUKmrJ3GOE0xm2I=.4b2c1452-a9a7-46fd-8547-a385d16d43e0@github.com>
Message-ID: <W76xx0x2C4OfhxTAOmQ6Njn1Z-dLLPpW-zk-n_c2mns=.f623476c-4b2e-436a-a974-cc99cd2288db@github.com>

On Thu, 18 Apr 2024 14:16:33 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+0

This pull request has now been integrated.

Changeset: 2a85be04
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2a85be0465b0dafa878818741427dc3c5c12f165
Stats:     88355 lines in 1725 files changed: 41593 ins; 40224 del; 6538 mod

Merge jdk

Merge jdk-23+0

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

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


From chagedorn at openjdk.org  Fri Apr 19 11:34:39 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 19 Apr 2024 11:34:39 GMT
Subject: [lworld] RFR: 8321734: [lworld] C2: flat_in_array type is not handled
 correctly leading to crashes
Message-ID: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>

There are multiple issues around types being `flat_in_array`:

#### 1. `SubTypeCheckNode` is not folded while `CheckCastPP` is correctly replaced by top due to an impossible type:
Test: `testSubTypeCheckNotFoldedParsingAbstractClass():` 

We have the following:
- `PUnique` is the unique concrete value sub class of the abstract value `AUnique` class
- `Object[] arr` -> elements could be an inline type that is flat

We apply loop unswitching such that we have a loop where the access `arr[i]` is with a flat inline type (i.e. marked as flat-in-array) and one version without. In the flat-in-array loop, we have the following sub type check for the `checkcast` for `(AUnique)arr[i]`:

AUnique [maybe-flat-in-array] <: Object [flat-in-array]

Since we do not know if `AUnique` is flat-in-array, we cannot fold this check. However, the corresponding `CheckCastPP` for this sub type check uses the unique concrete sub class `PUnique` which is known to be *not*-flat-in-array with `FlatArrayElementMaxSize=4`. Since a not-flat-in-array type cannot be a sub type of a flat-in-array type (determined during class loading), the `CheckCastPP` is replaced by top. But the `SubTypeCheck` is not folded. 

This was found in Valhalla and fixed in mainline with JDK-8328480. I've added the Valhalla specific test and merged the fix from mainline into this patch.

#### 2. Wrong `not_flat_in_array` default value
Test: `testSubTypeCheck()` and `testCmpP()`:
Arrays are always normal objects (i.e. not inline types). They are therefore never flat-in-array and always not-flat-in-array. While they are correctly never marked as flat-in-array, they are currently not marked as *not*-flat-in-array and thus have the implicit state *maybe*-flat-in-array:
https://github.com/openjdk/valhalla/blob/e01ec832189453cc302c7ca8915e69bb63a3d4b1/src/hotspot/share/opto/type.hpp#L1096

This becomes a problem for `SubTypeCheck` and `CmpP` nodes which cannot determine that a flat-in-array klass and an array klass are unrelated. But the type system itself correctly treat arrays as *not*-flat-in-array when doing a meet operation. As a result, data is folded while control is not.

This is fixed by changing the flat-in-array tri-state: As a default, a type is always not-flat-in-array. Inline types then override this property accordingly.

#### 3. Type system wrongly treats "maybe-be-flat-in-array <: flat-in-array" as top
Test: `testUnswitchingAbstractClass()`
 "maybe-be-flat-in-array <: flat-in-array" should not be treated as top. We could have cases where we know more about the super type while the sub type does not. In this case, the sub type should take over the flat-in-array property. We therefore have the following decision matrix for sub und super types:
https://github.com/openjdk/valhalla/blob/beb128981325b71c6891048d98282df08dddf329/src/hotspot/share/opto/type.cpp#L4585-L4592

Thanks,
Christian

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

Commit messages:
 - small update
 - Update test and add fix from JDK-8328480
 - 8321734: [lworld] C2: flat_in_array type with array type comparisons are not folded

Changes: https://git.openjdk.org/valhalla/pull/1079/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1079&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321734
  Stats: 308 lines in 5 files changed: 278 ins; 5 del; 25 mod
  Patch: https://git.openjdk.org/valhalla/pull/1079.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1079/head:pull/1079

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


From chagedorn at openjdk.org  Fri Apr 19 11:34:40 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 19 Apr 2024 11:34:40 GMT
Subject: [lworld] RFR: 8321734: [lworld] C2: flat_in_array type is not
 handled correctly leading to crashes
In-Reply-To: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
References: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
Message-ID: <oVZRZ2Eabtp19Ek2QXFLOkwKYyqvcrvL91Nk1oW-bHQ=.e9012452-7bc3-461e-af09-7c80bbd5e142@github.com>

On Fri, 19 Apr 2024 11:13:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> There are multiple issues around types being `flat_in_array`:
> 
> #### 1. `SubTypeCheckNode` is not folded while `CheckCastPP` is correctly replaced by top due to an impossible type:
> Test: `testSubTypeCheckNotFoldedParsingAbstractClass():` 
> 
> We have the following:
> - `PUnique` is the unique concrete value sub class of the abstract value `AUnique` class
> - `Object[] arr` -> elements could be an inline type that is flat
> 
> We apply loop unswitching such that we have a loop where the access `arr[i]` is with a flat inline type (i.e. marked as flat-in-array) and one version without. In the flat-in-array loop, we have the following sub type check for the `checkcast` for `(AUnique)arr[i]`:
> 
> AUnique [maybe-flat-in-array] <: Object [flat-in-array]
> 
> Since we do not know if `AUnique` is flat-in-array, we cannot fold this check. However, the corresponding `CheckCastPP` for this sub type check uses the unique concrete sub class `PUnique` which is known to be *not*-flat-in-array with `FlatArrayElementMaxSize=4`. Since a not-flat-in-array type cannot be a sub type of a flat-in-array type (determined during class loading), the `CheckCastPP` is replaced by top. But the `SubTypeCheck` is not folded. 
> 
> This was found in Valhalla and fixed in mainline with JDK-8328480. I've added the Valhalla specific test and merged the fix from mainline into this patch.
> 
> #### 2. Wrong `not_flat_in_array` default value
> Test: `testSubTypeCheck()` and `testCmpP()`:
> Arrays are always normal objects (i.e. not inline types). They are therefore never flat-in-array and always not-flat-in-array. While they are correctly never marked as flat-in-array, they are currently not marked as *not*-flat-in-array and thus have the implicit state *maybe*-flat-in-array:
> https://github.com/openjdk/valhalla/blob/e01ec832189453cc302c7ca8915e69bb63a3d4b1/src/hotspot/share/opto/type.hpp#L1096
> 
> This becomes a problem for `SubTypeCheck` and `CmpP` nodes which cannot determine that a flat-in-array klass and an array klass are unrelated. But the type system itself correctly treat arrays as *not*-flat-in-array when doing a meet operation. As a result, data is folded while control is not.
> 
> This is fixed by changing the flat-in-array tri-state: As a default, a type is always not-flat-in-array. Inline types then override this property accordingly.
> 
> #### 3. Type system wrongly treats "maybe-be-flat-in-array <: flat-in-array" as top
> Test: `testUnswitchingAbstractClass()`
>  "maybe-be-flat-in-array <: flat-in-array" should not be treate...

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

> 3449:   const TypeKlassPtr* klass_ptr_type = _gvn.type(superklass)->is_klassptr();
> 3450:   const TypeKlassPtr* improved_klass_ptr_type = klass_ptr_type->try_improve();
> 3451:   const TypeOopPtr* toop = improved_klass_ptr_type->cast_to_exactness(false)->as_instance_type();

Changes in this file taken from JDK-8328480.

src/hotspot/share/opto/type.cpp line 997:

> 995: 
> 996:   // Verify that:
> 997:   //      this meet t == t meet this

Found these comments useful while verifying the type system changes.

src/hotspot/share/opto/type.cpp line 4536:

> 4534:   const bool other_flat_in_array = other_type->flat_in_array();
> 4535:   const bool this_not_flat_in_array = this_type->not_flat_in_array();
> 4536:   const bool other_not_flat_in_array = other_type->not_flat_in_array();

`this_flat_in_array` and `flat_array` are both used to hold intermediate and final results about whether the type is going to be flat-in-array or not. This was somewhat hard to follow what was going on.

Changed this into: `this_flat_in_array` for the flat-in-array state of `this_type` and `flat_in_array` to hold the intermediate and eventually the final result assigned to `res_flat_in_array`.

src/hotspot/share/opto/type.cpp line 4582:

> 4580:     subtype_exact = below_centerline(ptr) ? (this_xk && other_xk) : (this_xk || other_xk);
> 4581:     flat_array = below_centerline(ptr) ? (this_flat_in_array && other_flat_in_array) : (this_flat_in_array || other_flat_in_array);
> 4582:   } else if (!other_xk && this_type->is_meet_subtype_of(other_type) && (!other_flat_in_array || this_flat_in_array)) {

Extracted `is_meet_subtype_of()` + flat-in-array checks to separate methods to simplify the condition.

src/hotspot/share/opto/type.cpp line 4604:

> 4602:       other_type = this_type; // this is down; keep down man
> 4603:       other_xk = this_xk;
> 4604:       other_flat_in_array = this_flat_in_array;

Assignments to `other*` are not used anymore later and are thus removed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1079#discussion_r1572215555
PR Review Comment: https://git.openjdk.org/valhalla/pull/1079#discussion_r1572215040
PR Review Comment: https://git.openjdk.org/valhalla/pull/1079#discussion_r1572228027
PR Review Comment: https://git.openjdk.org/valhalla/pull/1079#discussion_r1572220233
PR Review Comment: https://git.openjdk.org/valhalla/pull/1079#discussion_r1572216420


From madi.radu88 at gmail.com  Fri Apr 19 22:44:25 2024
From: madi.radu88 at gmail.com (MADI RADU)
Date: Sat, 20 Apr 2024 01:44:25 +0300
Subject: Eden proposed idea
Message-ID: <CAAit081OExsEmx6dFtqCH45oUadPQfb3n1HMYAcRP7L9MN5N3A@mail.gmail.com>

Hello,

I am not sure how all the versions of Eden are implemented but you can add
one version with reversed timestamps parameters maybe for debugging
purposes (I heard there are AMD bugs I think related to this) or I saw on
the internet java agents with scavaging concepts.

Regards,
Madalina-Maria Radu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240420/055b9f5d/attachment.htm>

From fparain at openjdk.org  Mon Apr 22 17:48:00 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 22 Apr 2024 17:48:00 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules [v2]
In-Reply-To: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
Message-ID: <R5LMG-vP6tdYOLJzlelSU9c2jWiryCWkZuaaADV311Y=.dc9d228f-34e5-4dd4-b7a6-b4a775fb396f@github.com>

> Small changes to implement new field modifiers rules (JVMS 4.5 Fields) related to ACC_STRICT.
> Those changes trigger some test failures because of a bug in javac related to final synthetic field. This bug is tracked by JDK-8330583.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Fix fields access flags filtering

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1076/files
  - new: https://git.openjdk.org/valhalla/pull/1076/files/3b423484..992a2f77

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

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

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


From heidinga at openjdk.org  Mon Apr 22 18:32:51 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 22 Apr 2024 18:32:51 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules [v2]
In-Reply-To: <R5LMG-vP6tdYOLJzlelSU9c2jWiryCWkZuaaADV311Y=.dc9d228f-34e5-4dd4-b7a6-b4a775fb396f@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
 <R5LMG-vP6tdYOLJzlelSU9c2jWiryCWkZuaaADV311Y=.dc9d228f-34e5-4dd4-b7a6-b4a775fb396f@github.com>
Message-ID: <Uq0l19EMeZgJ2vss5TRsre1ruy-DkiyiXs8uveVoXHI=.9c573b86-b373-485b-b467-225ae779e8e4@github.com>

On Mon, 22 Apr 2024 17:48:00 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Small changes to implement new field modifiers rules (JVMS 4.5 Fields) related to ACC_STRICT.
>> Those changes trigger some test failures because of a bug in javac related to final synthetic field. This bug is tracked by JDK-8330583.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix fields access flags filtering

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

> 4798:         is_illegal = true;
> 4799:       } else if (supports_inline_types()) {
> 4800:         if (!is_identity_class && !is_static && !is_strict) {

Suggestion:

        if (!is_identity_class && !is_static && !is_strict) {
            /* non-static value class fields must be be strict */

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

> 4800:         if (!is_identity_class && !is_static && !is_strict) {
> 4801:           is_illegal = true;
> 4802:         } else if (is_abstract && !is_identity_class && !is_static) {

Suggestion:

        } else if (is_abstract && !is_identity_class && !is_static) {
            /* abstract value classes can only have static fields */

If I'm reading that correctly, we're not yet allowing value classes to inherit instance fields.  Should this have a TODO so we come back and support as per JEP 401 later?

src/hotspot/share/include/jvm_constants.h line 49:

> 47:                                         JVM_ACC_ENUM | \
> 48:                                         JVM_ACC_SYNTHETIC | \
> 49:                                         JVM_ACC_STRICT)

Should we flip the order of these so they appear in bit order and match the METHOD_MODIFIERS order as well?

Suggestion:

                                        JVM_ACC_STRICT | \
                                        JVM_ACC_SYNTHETIC)

test/hotspot/jtreg/runtime/valhalla/inlinetypes/classfileparser/fieldModifiersTest.jcod line 158:

> 156: 
> 157: 
> 158: // A field has both ACC_STRCIT and ACC_STATIC set

Suggestion:

// A field has both ACC_STRICT and ACC_STATIC set

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1076#discussion_r1575190756
PR Review Comment: https://git.openjdk.org/valhalla/pull/1076#discussion_r1575192363
PR Review Comment: https://git.openjdk.org/valhalla/pull/1076#discussion_r1575197265
PR Review Comment: https://git.openjdk.org/valhalla/pull/1076#discussion_r1575199504


From fparain at openjdk.org  Mon Apr 22 20:23:02 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 22 Apr 2024 20:23:02 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules [v3]
In-Reply-To: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
Message-ID: <lWEp_hcHndG9i2wqMAqDeEQh6Wc3Oq4rv9rrFAVHWO0=.a22afbe4-4416-41bb-8cf6-a4bbff2726da@github.com>

> Small changes to implement new field modifiers rules (JVMS 4.5 Fields) related to ACC_STRICT.
> Those changes trigger some test failures because of a bug in javac related to final synthetic field. This bug is tracked by JDK-8330583.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Fixes suggested by review

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1076/files
  - new: https://git.openjdk.org/valhalla/pull/1076/files/992a2f77..68382f8e

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

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

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


From fparain at openjdk.org  Mon Apr 22 20:29:42 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 22 Apr 2024 20:29:42 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules [v2]
In-Reply-To: <Uq0l19EMeZgJ2vss5TRsre1ruy-DkiyiXs8uveVoXHI=.9c573b86-b373-485b-b467-225ae779e8e4@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
 <R5LMG-vP6tdYOLJzlelSU9c2jWiryCWkZuaaADV311Y=.dc9d228f-34e5-4dd4-b7a6-b4a775fb396f@github.com>
 <Uq0l19EMeZgJ2vss5TRsre1ruy-DkiyiXs8uveVoXHI=.9c573b86-b373-485b-b467-225ae779e8e4@github.com>
Message-ID: <MVV27huiiA4bOA6Tcb5D9JXhvMxlg5LzYLydan_CjVw=.1d2fb15a-8bc7-415e-8f2b-f90f9a251a6b@github.com>

On Mon, 22 Apr 2024 18:19:41 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix fields access flags filtering
>
> src/hotspot/share/classfile/classFileParser.cpp line 4800:
> 
>> 4798:         is_illegal = true;
>> 4799:       } else if (supports_inline_types()) {
>> 4800:         if (!is_identity_class && !is_static && !is_strict) {
> 
> Suggestion:
> 
>         if (!is_identity_class && !is_static && !is_strict) {
>             /* non-static value class fields must be be strict */

Fixed as suggested.

> src/hotspot/share/classfile/classFileParser.cpp line 4802:
> 
>> 4800:         if (!is_identity_class && !is_static && !is_strict) {
>> 4801:           is_illegal = true;
>> 4802:         } else if (is_abstract && !is_identity_class && !is_static) {
> 
> Suggestion:
> 
>         } else if (is_abstract && !is_identity_class && !is_static) {
>             /* abstract value classes can only have static fields */
> 
> If I'm reading that correctly, we're not yet allowing value classes to inherit instance fields.  Should this have a TODO so we come back and support as per JEP 401 later?

I'll start working on value classes field inheritance immediately after the the first nullable flat field patch is pushed (hopefully this week).

> src/hotspot/share/include/jvm_constants.h line 49:
> 
>> 47:                                         JVM_ACC_ENUM | \
>> 48:                                         JVM_ACC_SYNTHETIC | \
>> 49:                                         JVM_ACC_STRICT)
> 
> Should we flip the order of these so they appear in bit order and match the METHOD_MODIFIERS order as well?
> 
> Suggestion:
> 
>                                         JVM_ACC_STRICT | \
>                                         JVM_ACC_SYNTHETIC)

Fixed as suggested.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1076#discussion_r1575317584
PR Review Comment: https://git.openjdk.org/valhalla/pull/1076#discussion_r1575320804
PR Review Comment: https://git.openjdk.org/valhalla/pull/1076#discussion_r1575318986


From vromero at openjdk.org  Mon Apr 22 20:56:50 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 Apr 2024 20:56:50 GMT
Subject: [lworld] RFR: 8330583: [lworld] javac doesn't set ACC_STRICT to final
 synthetic fields in value classes
Message-ID: <KqVKr1_gCjpPc8VpVpSkhxfb91njaont9l9GdWIa8vw=.85e41793-b1a7-4448-9fba-12f529ea6a80@github.com>

javac is not setting the ACC_STRICT flag to final synthetic fields in value classes. The code below reproduces the issue:


class NestedTest {
    value class MyValue {
        int i = 0;

        public String toString() {
            return "MyValue("+i+","+outerInt+")";
        }
    }

    int outerInt = 42;
    MyValue v = new MyValue();

    public static void main(String[] args) {
        NestedTest nt = new NestedTest();
    }
}

in this case class MyValue has an outer this field of type NestedTest which is final and synthetic but in the case of value classes should also be strict.

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

Commit messages:
 - 8330583: [lworld] javac doesn't set ACC_STRICT to final synthetic fields in value classes

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

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


From vromero at openjdk.org  Mon Apr 22 21:50:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 Apr 2024 21:50:41 GMT
Subject: [lworld] Integrated: 8330583: [lworld] javac doesn't set ACC_STRICT to
 final synthetic fields in value classes
In-Reply-To: <KqVKr1_gCjpPc8VpVpSkhxfb91njaont9l9GdWIa8vw=.85e41793-b1a7-4448-9fba-12f529ea6a80@github.com>
References: <KqVKr1_gCjpPc8VpVpSkhxfb91njaont9l9GdWIa8vw=.85e41793-b1a7-4448-9fba-12f529ea6a80@github.com>
Message-ID: <9rSalwqQ0Y7t2rWyFC_a_7i7kYXqka_lxsPUcyM-EKA=.72829e4c-b6bf-46c6-bf01-6d7482d2a688@github.com>

On Mon, 22 Apr 2024 20:52:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is not setting the ACC_STRICT flag to final synthetic fields in value classes. The code below reproduces the issue:
> 
> 
> class NestedTest {
>     value class MyValue {
>         int i = 0;
> 
>         public String toString() {
>             return "MyValue("+i+","+outerInt+")";
>         }
>     }
> 
>     int outerInt = 42;
>     MyValue v = new MyValue();
> 
>     public static void main(String[] args) {
>         NestedTest nt = new NestedTest();
>     }
> }
> 
> in this case class MyValue has an outer this field of type NestedTest which is final and synthetic but in the case of value classes should also be strict.

This pull request has now been integrated.

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

8330583: [lworld] javac doesn't set ACC_STRICT to final synthetic fields in value classes

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

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


From fparain at openjdk.org  Tue Apr 23 11:46:49 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 23 Apr 2024 11:46:49 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules [v2]
In-Reply-To: <Uq0l19EMeZgJ2vss5TRsre1ruy-DkiyiXs8uveVoXHI=.9c573b86-b373-485b-b467-225ae779e8e4@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
 <R5LMG-vP6tdYOLJzlelSU9c2jWiryCWkZuaaADV311Y=.dc9d228f-34e5-4dd4-b7a6-b4a775fb396f@github.com>
 <Uq0l19EMeZgJ2vss5TRsre1ruy-DkiyiXs8uveVoXHI=.9c573b86-b373-485b-b467-225ae779e8e4@github.com>
Message-ID: <CU7VoafjY_r7lAeN9uCV2ThwUxbiqwl4KsGIFuG9fEI=.4c21d1fc-6058-4d50-be60-edac5daec639@github.com>

On Mon, 22 Apr 2024 18:28:14 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix fields access flags filtering
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/classfileparser/fieldModifiersTest.jcod line 158:
> 
>> 156: 
>> 157: 
>> 158: // A field has both ACC_STRCIT and ACC_STATIC set
> 
> Suggestion:
> 
> // A field has both ACC_STRICT and ACC_STATIC set

Fixed as suggested.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1076#discussion_r1576110330


From heidinga at openjdk.org  Tue Apr 23 14:56:44 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 23 Apr 2024 14:56:44 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules [v3]
In-Reply-To: <lWEp_hcHndG9i2wqMAqDeEQh6Wc3Oq4rv9rrFAVHWO0=.a22afbe4-4416-41bb-8cf6-a4bbff2726da@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
 <lWEp_hcHndG9i2wqMAqDeEQh6Wc3Oq4rv9rrFAVHWO0=.a22afbe4-4416-41bb-8cf6-a4bbff2726da@github.com>
Message-ID: <C0xtNyWKaPLCJ5fL3h_dqcRaT08k2dAnpuTgHm0DGUo=.9766974c-407c-47f4-83ba-41bddfa42815@github.com>

On Mon, 22 Apr 2024 20:23:02 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Small changes to implement new field modifiers rules (JVMS 4.5 Fields) related to ACC_STRICT.
>> Those changes trigger some test failures because of a bug in javac related to final synthetic field. This bug is tracked by JDK-8330583.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes suggested by review

Thanks Fred.  Looks good to me

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1076#pullrequestreview-2017510754


From fparain at openjdk.org  Tue Apr 23 15:02:52 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 23 Apr 2024 15:02:52 GMT
Subject: [lworld] RFR: 8330582: [lworld] The JVM must enforce new field
 modifiers rules [v3]
In-Reply-To: <lWEp_hcHndG9i2wqMAqDeEQh6Wc3Oq4rv9rrFAVHWO0=.a22afbe4-4416-41bb-8cf6-a4bbff2726da@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
 <lWEp_hcHndG9i2wqMAqDeEQh6Wc3Oq4rv9rrFAVHWO0=.a22afbe4-4416-41bb-8cf6-a4bbff2726da@github.com>
Message-ID: <7n1tYjRs2wa69rCE-V__MhGv2TPNuD0z4asf15YPsmg=.39154f5e-1a07-45bb-b791-d386c72c3d8a@github.com>

On Mon, 22 Apr 2024 20:23:02 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Small changes to implement new field modifiers rules (JVMS 4.5 Fields) related to ACC_STRICT.
>> Those changes trigger some test failures because of a bug in javac related to final synthetic field. This bug is tracked by JDK-8330583.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes suggested by review

Thanks for the review Dan.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1076#issuecomment-2072592826


From fparain at openjdk.org  Tue Apr 23 15:02:54 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 23 Apr 2024 15:02:54 GMT
Subject: [lworld] Integrated: 8330582: [lworld] The JVM must enforce new field
 modifiers rules
In-Reply-To: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
References: <iG-1_4uwCcJz0QJiiqpdEN9GkxLQkANdYdIoLwRivIA=.e64ae021-d0b5-4a9a-a187-9ed671eff1fe@github.com>
Message-ID: <AKT-D4dwEYHI6EmCGCma-06QxY1FLV_ZQxHbEMX-7do=.0e809261-583e-4c4c-afa9-d54414cbafd3@github.com>

On Thu, 18 Apr 2024 13:36:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small changes to implement new field modifiers rules (JVMS 4.5 Fields) related to ACC_STRICT.
> Those changes trigger some test failures because of a bug in javac related to final synthetic field. This bug is tracked by JDK-8330583.

This pull request has now been integrated.

Changeset: eadbb377
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/eadbb37770ef13f97f16fc0ed5f954e3717cd5b3
Stats:     607 lines in 9 files changed: 600 ins; 0 del; 7 mod

8330582: [lworld] The JVM must enforce new field modifiers rules

Reviewed-by: heidinga

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

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


From fparain at openjdk.org  Tue Apr 23 17:51:04 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 23 Apr 2024 17:51:04 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for nullable
 flat fields
Message-ID: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>

This is the first step in supporting nullable flat fields in JEP 401.
Those changes give value fields the optional capability to be associated with a null marker that indicates if the value if the field is null or not. Null markers are integrated in the object layout, and in the field metadata (in both compresses and uncompressed forms).
Field accesses in the x86 and the arch64 interpreter have been extended to check the presence of a null marker when reading a field. If present, the null marker is checked in reads and updated on writes.

The field layout logic is becoming more complex (and the complexity will continue to increase in the future with the addition of atomic flat fields and atomic nullable flat fields). So the changeset includes a test framework able to verify the consistency of fields layout using the output of -XX:+PrintFieldLayout. The format of data printed by PrintFieldLayout has been extended and modified to be easier to parse.

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

Commit messages:
 - More cleanup
 - Merge remote-tracking branch 'upstream/lworld' into null_flat
 - Fixes and cleanup
 - Merge remote-tracking branch 'upstream/lworld' into null_flat
 - Document nullable flat field access protocols
 - Add internal null marker support, aarch64 support, unsafe support
 - Add support for internal null markers in layouts and tests
 - Add layout test framework plus bug fixes
 - Fix metadata, FieldInfoStream and printing
 - Merge remote-tracking branch 'upstream/lworld' into null_flat
 - ... and 3 more: https://git.openjdk.org/valhalla/compare/2a85be04...684da164

Changes: https://git.openjdk.org/valhalla/pull/1078/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1078&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331006
  Stats: 1964 lines in 37 files changed: 1772 ins; 13 del; 179 mod
  Patch: https://git.openjdk.org/valhalla/pull/1078.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1078/head:pull/1078

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


From thartmann at openjdk.org  Wed Apr 24 11:43:43 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 24 Apr 2024 11:43:43 GMT
Subject: [lworld] RFR: 8321734: [lworld] C2: flat_in_array type is not
 handled correctly leading to crashes
In-Reply-To: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
References: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
Message-ID: <R-8OCgE1QjDBm2Szx1gabaC1hLiDC7Lv8TpsDM_6yoc=.cddbcb8a-ec3f-4576-b781-5b8ba2dfd5a5@github.com>

On Fri, 19 Apr 2024 11:13:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> There are multiple issues around types being `flat_in_array`:
> 
> #### 1. `SubTypeCheckNode` is not folded while `CheckCastPP` is correctly replaced by top due to an impossible type:
> Test: `testSubTypeCheckNotFoldedParsingAbstractClass():` 
> 
> We have the following:
> - `PUnique` is the unique concrete value sub class of the abstract value `AUnique` class
> - `Object[] arr` -> elements could be an inline type that is flat
> 
> We apply loop unswitching such that we have a loop where the access `arr[i]` is with a flat inline type (i.e. marked as flat-in-array) and one version without. In the flat-in-array loop, we have the following sub type check for the `checkcast` for `(AUnique)arr[i]`:
> 
> AUnique [maybe-flat-in-array] <: Object [flat-in-array]
> 
> Since we do not know if `AUnique` is flat-in-array, we cannot fold this check. However, the corresponding `CheckCastPP` for this sub type check uses the unique concrete sub class `PUnique` which is known to be *not*-flat-in-array with `FlatArrayElementMaxSize=4`. Since a not-flat-in-array type cannot be a sub type of a flat-in-array type (determined during class loading), the `CheckCastPP` is replaced by top. But the `SubTypeCheck` is not folded. 
> 
> This was found in Valhalla and fixed in mainline with JDK-8328480. I've added the Valhalla specific test and merged the fix from mainline into this patch.
> 
> #### 2. Wrong `not_flat_in_array` default value
> Test: `testSubTypeCheck()` and `testCmpP()`:
> Arrays are always normal objects (i.e. not inline types). They are therefore never flat-in-array and always not-flat-in-array. While they are correctly never marked as flat-in-array, they are currently not marked as *not*-flat-in-array and thus have the implicit state *maybe*-flat-in-array:
> https://github.com/openjdk/valhalla/blob/e01ec832189453cc302c7ca8915e69bb63a3d4b1/src/hotspot/share/opto/type.hpp#L1096
> 
> This becomes a problem for `SubTypeCheck` and `CmpP` nodes which cannot determine that a flat-in-array klass and an array klass are unrelated. But the type system itself correctly treat arrays as *not*-flat-in-array when doing a meet operation. As a result, data is folded while control is not.
> 
> This is fixed by changing the flat-in-array tri-state: As a default, a type is always not-flat-in-array. Inline types then override this property accordingly.
> 
> #### 3. Type system wrongly treats "maybe-be-flat-in-array <: flat-in-array" as top
> Test: `testUnswitchingAbstractClass()`
>  "maybe-be-flat-in-array <: flat-in-array" should not be treate...

Thanks for the thorough investigation, Christian. Great job! The fixes look good to me.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatInArraysFolding.java line 30:

> 28:  * @summary Test that CmpPNode::sub and SubTypeCheckNode::sub correctly identify unrelated classes based on the flat
> 29:  *          in array property of the types. Additionally check that the type system properly handles the case of a
> 30:  *         super class being flat in array while the sub klass could be flat in array.

Suggestion:

 *          super class being flat in array while the sub klass could be flat in array.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatInArraysFolding.java line 43:

> 41:  * @summary Test that CmpPNode::sub and SubTypeCheckNode::sub correctly identify unrelated classes based on the flat
> 42:  *          in array property of the types. Additionally check that the type system properly handles the case of a
> 43:  *         super class being flat in array while the sub klass could be flat in array.

Suggestion:

 *          super class being flat in array while the sub klass could be flat in array.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1079#pullrequestreview-2019615504
PR Review Comment: https://git.openjdk.org/valhalla/pull/1079#discussion_r1577736697
PR Review Comment: https://git.openjdk.org/valhalla/pull/1079#discussion_r1577736833


From thartmann at openjdk.org  Wed Apr 24 11:43:44 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 24 Apr 2024 11:43:44 GMT
Subject: [lworld] RFR: 8321734: [lworld] C2: flat_in_array type is not
 handled correctly leading to crashes
In-Reply-To: <oVZRZ2Eabtp19Ek2QXFLOkwKYyqvcrvL91Nk1oW-bHQ=.e9012452-7bc3-461e-af09-7c80bbd5e142@github.com>
References: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
 <oVZRZ2Eabtp19Ek2QXFLOkwKYyqvcrvL91Nk1oW-bHQ=.e9012452-7bc3-461e-af09-7c80bbd5e142@github.com>
Message-ID: <Nzc0Iyfd9ZZtumA_EiQhwzQ06B4HWXJXFYlYZNGZZhs=.174b754d-33a4-49f2-a8d8-ab4d8790e8f6@github.com>

On Fri, 19 Apr 2024 11:14:34 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> There are multiple issues around types being `flat_in_array`:
>> 
>> #### 1. `SubTypeCheckNode` is not folded while `CheckCastPP` is correctly replaced by top due to an impossible type:
>> Test: `testSubTypeCheckNotFoldedParsingAbstractClass():` 
>> 
>> We have the following:
>> - `PUnique` is the unique concrete value sub class of the abstract value `AUnique` class
>> - `Object[] arr` -> elements could be an inline type that is flat
>> 
>> We apply loop unswitching such that we have a loop where the access `arr[i]` is with a flat inline type (i.e. marked as flat-in-array) and one version without. In the flat-in-array loop, we have the following sub type check for the `checkcast` for `(AUnique)arr[i]`:
>> 
>> AUnique [maybe-flat-in-array] <: Object [flat-in-array]
>> 
>> Since we do not know if `AUnique` is flat-in-array, we cannot fold this check. However, the corresponding `CheckCastPP` for this sub type check uses the unique concrete sub class `PUnique` which is known to be *not*-flat-in-array with `FlatArrayElementMaxSize=4`. Since a not-flat-in-array type cannot be a sub type of a flat-in-array type (determined during class loading), the `CheckCastPP` is replaced by top. But the `SubTypeCheck` is not folded. 
>> 
>> This was found in Valhalla and fixed in mainline with JDK-8328480. I've added the Valhalla specific test and merged the fix from mainline into this patch.
>> 
>> #### 2. Wrong `not_flat_in_array` default value
>> Test: `testSubTypeCheck()` and `testCmpP()`:
>> Arrays are always normal objects (i.e. not inline types). They are therefore never flat-in-array and always not-flat-in-array. While they are correctly never marked as flat-in-array, they are currently not marked as *not*-flat-in-array and thus have the implicit state *maybe*-flat-in-array:
>> https://github.com/openjdk/valhalla/blob/e01ec832189453cc302c7ca8915e69bb63a3d4b1/src/hotspot/share/opto/type.hpp#L1096
>> 
>> This becomes a problem for `SubTypeCheck` and `CmpP` nodes which cannot determine that a flat-in-array klass and an array klass are unrelated. But the type system itself correctly treat arrays as *not*-flat-in-array when doing a meet operation. As a result, data is folded while control is not.
>> 
>> This is fixed by changing the flat-in-array tri-state: As a default, a type is always not-flat-in-array. Inline types then override this property accordingly.
>> 
>> #### 3. Type system wrongly treats "maybe-be-flat-in-array <: flat-in-array" as top
>> Test: `testUnswitchingAbstractClass()`
>>  "may...
>
> src/hotspot/share/opto/type.cpp line 997:
> 
>> 995: 
>> 996:   // Verify that:
>> 997:   //      this meet t == t meet this
> 
> Found these comments useful while verifying the type system changes.

Nice!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1079#discussion_r1577738905


From chagedorn at openjdk.org  Wed Apr 24 11:55:06 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 24 Apr 2024 11:55:06 GMT
Subject: [lworld] RFR: 8321734: [lworld] C2: flat_in_array type is not
 handled correctly leading to crashes [v2]
In-Reply-To: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
References: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
Message-ID: <mqaUx60Iy5l2y87zrfTSm_aPYDO2xd_8-YX-2HV7xyQ=.3eb5f9fe-7a9b-45dd-9f29-fc669c3b2146@github.com>

> There are multiple issues around types being `flat_in_array`:
> 
> #### 1. `SubTypeCheckNode` is not folded while `CheckCastPP` is correctly replaced by top due to an impossible type:
> Test: `testSubTypeCheckNotFoldedParsingAbstractClass():` 
> 
> We have the following:
> - `PUnique` is the unique concrete value sub class of the abstract value `AUnique` class
> - `Object[] arr` -> elements could be an inline type that is flat
> 
> We apply loop unswitching such that we have a loop where the access `arr[i]` is with a flat inline type (i.e. marked as flat-in-array) and one version without. In the flat-in-array loop, we have the following sub type check for the `checkcast` for `(AUnique)arr[i]`:
> 
> AUnique [maybe-flat-in-array] <: Object [flat-in-array]
> 
> Since we do not know if `AUnique` is flat-in-array, we cannot fold this check. However, the corresponding `CheckCastPP` for this sub type check uses the unique concrete sub class `PUnique` which is known to be *not*-flat-in-array with `FlatArrayElementMaxSize=4`. Since a not-flat-in-array type cannot be a sub type of a flat-in-array type (determined during class loading), the `CheckCastPP` is replaced by top. But the `SubTypeCheck` is not folded. 
> 
> This was found in Valhalla and fixed in mainline with JDK-8328480. I've added the Valhalla specific test and merged the fix from mainline into this patch.
> 
> #### 2. Wrong `not_flat_in_array` default value
> Test: `testSubTypeCheck()` and `testCmpP()`:
> Arrays are always normal objects (i.e. not inline types). They are therefore never flat-in-array and always not-flat-in-array. While they are correctly never marked as flat-in-array, they are currently not marked as *not*-flat-in-array and thus have the implicit state *maybe*-flat-in-array:
> https://github.com/openjdk/valhalla/blob/e01ec832189453cc302c7ca8915e69bb63a3d4b1/src/hotspot/share/opto/type.hpp#L1096
> 
> This becomes a problem for `SubTypeCheck` and `CmpP` nodes which cannot determine that a flat-in-array klass and an array klass are unrelated. But the type system itself correctly treat arrays as *not*-flat-in-array when doing a meet operation. As a result, data is folded while control is not.
> 
> This is fixed by changing the flat-in-array tri-state: As a default, a type is always not-flat-in-array. Inline types then override this property accordingly.
> 
> #### 3. Type system wrongly treats "maybe-be-flat-in-array <: flat-in-array" as top
> Test: `testUnswitchingAbstractClass()`
>  "maybe-be-flat-in-array <: flat-in-array" should not be treate...

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1079/files
  - new: https://git.openjdk.org/valhalla/pull/1079/files/8501d19f..18b027e6

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

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

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


From chagedorn at openjdk.org  Wed Apr 24 11:55:06 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 24 Apr 2024 11:55:06 GMT
Subject: [lworld] RFR: 8321734: [lworld] C2: flat_in_array type is not
 handled correctly leading to crashes
In-Reply-To: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
References: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
Message-ID: <kmV3by3p5-N3F1CgUgCLbH3nt9tEbBEHsF3MdPhOdgo=.699a1c6d-7652-47d7-9e80-11a41c07d695@github.com>

On Fri, 19 Apr 2024 11:13:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> There are multiple issues around types being `flat_in_array`:
> 
> #### 1. `SubTypeCheckNode` is not folded while `CheckCastPP` is correctly replaced by top due to an impossible type:
> Test: `testSubTypeCheckNotFoldedParsingAbstractClass():` 
> 
> We have the following:
> - `PUnique` is the unique concrete value sub class of the abstract value `AUnique` class
> - `Object[] arr` -> elements could be an inline type that is flat
> 
> We apply loop unswitching such that we have a loop where the access `arr[i]` is with a flat inline type (i.e. marked as flat-in-array) and one version without. In the flat-in-array loop, we have the following sub type check for the `checkcast` for `(AUnique)arr[i]`:
> 
> AUnique [maybe-flat-in-array] <: Object [flat-in-array]
> 
> Since we do not know if `AUnique` is flat-in-array, we cannot fold this check. However, the corresponding `CheckCastPP` for this sub type check uses the unique concrete sub class `PUnique` which is known to be *not*-flat-in-array with `FlatArrayElementMaxSize=4`. Since a not-flat-in-array type cannot be a sub type of a flat-in-array type (determined during class loading), the `CheckCastPP` is replaced by top. But the `SubTypeCheck` is not folded. 
> 
> This was found in Valhalla and fixed in mainline with JDK-8328480. I've added the Valhalla specific test and merged the fix from mainline into this patch.
> 
> #### 2. Wrong `not_flat_in_array` default value
> Test: `testSubTypeCheck()` and `testCmpP()`:
> Arrays are always normal objects (i.e. not inline types). They are therefore never flat-in-array and always not-flat-in-array. While they are correctly never marked as flat-in-array, they are currently not marked as *not*-flat-in-array and thus have the implicit state *maybe*-flat-in-array:
> https://github.com/openjdk/valhalla/blob/e01ec832189453cc302c7ca8915e69bb63a3d4b1/src/hotspot/share/opto/type.hpp#L1096
> 
> This becomes a problem for `SubTypeCheck` and `CmpP` nodes which cannot determine that a flat-in-array klass and an array klass are unrelated. But the type system itself correctly treat arrays as *not*-flat-in-array when doing a meet operation. As a result, data is folded while control is not.
> 
> This is fixed by changing the flat-in-array tri-state: As a default, a type is always not-flat-in-array. Inline types then override this property accordingly.
> 
> #### 3. Type system wrongly treats "maybe-be-flat-in-array <: flat-in-array" as top
> Test: `testUnswitchingAbstractClass()`
>  "maybe-be-flat-in-array <: flat-in-array" should not be treate...

Thanks Tobias for your review and the offline discussions!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1079#issuecomment-2074760038


From chagedorn at openjdk.org  Wed Apr 24 11:55:07 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 24 Apr 2024 11:55:07 GMT
Subject: [lworld] Integrated: 8321734: [lworld] C2: flat_in_array type is not
 handled correctly leading to crashes
In-Reply-To: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
References: <G9z2lV4W8wtkfXgk_ZQXD6aPB_iCqe-IJqIHgvTOe8c=.e79aac6a-17c6-49d9-b499-2db00f27ed43@github.com>
Message-ID: <08SEbihD3MSf6rsY6DY91QHMEWe2m3kSZNnBNnMZpX8=.c552ddda-8ac3-4f74-b02a-2ec1fc6b4c41@github.com>

On Fri, 19 Apr 2024 11:13:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> There are multiple issues around types being `flat_in_array`:
> 
> #### 1. `SubTypeCheckNode` is not folded while `CheckCastPP` is correctly replaced by top due to an impossible type:
> Test: `testSubTypeCheckNotFoldedParsingAbstractClass():` 
> 
> We have the following:
> - `PUnique` is the unique concrete value sub class of the abstract value `AUnique` class
> - `Object[] arr` -> elements could be an inline type that is flat
> 
> We apply loop unswitching such that we have a loop where the access `arr[i]` is with a flat inline type (i.e. marked as flat-in-array) and one version without. In the flat-in-array loop, we have the following sub type check for the `checkcast` for `(AUnique)arr[i]`:
> 
> AUnique [maybe-flat-in-array] <: Object [flat-in-array]
> 
> Since we do not know if `AUnique` is flat-in-array, we cannot fold this check. However, the corresponding `CheckCastPP` for this sub type check uses the unique concrete sub class `PUnique` which is known to be *not*-flat-in-array with `FlatArrayElementMaxSize=4`. Since a not-flat-in-array type cannot be a sub type of a flat-in-array type (determined during class loading), the `CheckCastPP` is replaced by top. But the `SubTypeCheck` is not folded. 
> 
> This was found in Valhalla and fixed in mainline with JDK-8328480. I've added the Valhalla specific test and merged the fix from mainline into this patch.
> 
> #### 2. Wrong `not_flat_in_array` default value
> Test: `testSubTypeCheck()` and `testCmpP()`:
> Arrays are always normal objects (i.e. not inline types). They are therefore never flat-in-array and always not-flat-in-array. While they are correctly never marked as flat-in-array, they are currently not marked as *not*-flat-in-array and thus have the implicit state *maybe*-flat-in-array:
> https://github.com/openjdk/valhalla/blob/e01ec832189453cc302c7ca8915e69bb63a3d4b1/src/hotspot/share/opto/type.hpp#L1096
> 
> This becomes a problem for `SubTypeCheck` and `CmpP` nodes which cannot determine that a flat-in-array klass and an array klass are unrelated. But the type system itself correctly treat arrays as *not*-flat-in-array when doing a meet operation. As a result, data is folded while control is not.
> 
> This is fixed by changing the flat-in-array tri-state: As a default, a type is always not-flat-in-array. Inline types then override this property accordingly.
> 
> #### 3. Type system wrongly treats "maybe-be-flat-in-array <: flat-in-array" as top
> Test: `testUnswitchingAbstractClass()`
>  "maybe-be-flat-in-array <: flat-in-array" should not be treate...

This pull request has now been integrated.

Changeset: 2aa66137
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2aa66137140b73db9e914eefe34dedccbc0b4629
Stats:     308 lines in 5 files changed: 278 ins; 5 del; 25 mod

8321734: [lworld] C2: flat_in_array type is not handled correctly leading to crashes

Reviewed-by: thartmann

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

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


From thartmann at openjdk.org  Wed Apr 24 13:11:56 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 24 Apr 2024 13:11:56 GMT
Subject: [lworld] RFR: 8330833: [lworld] Handle deoptimization during value
 object construction
Message-ID: <BrZfA-05ewKH50wVTRsGZR5LHsypyT9C9-RLT6wPxoQ=.e83e9946-e693-4d0b-8b06-58d1c8805649@github.com>

Follow-up fix from https://github.com/openjdk/valhalla/pull/1064. Debug information at calls/traps in value object constructors is incorrect because the side effects of the constructor are not propagated. As a result, deoptimization creates a wrong state leading to incorrect execution. This patch addresses the remaining issues and adds more tests.

Thanks,
Tobias

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

Commit messages:
 - Comment and flag fixes
 - Merge branch 'lworld' into JDK-8330833
 - Another fix
 - More changes
 - Merge branch 'lworld' into JDK-8330833
 - More fixes
 - First prototype

Changes: https://git.openjdk.org/valhalla/pull/1081/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1081&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330833
  Stats: 320 lines in 8 files changed: 246 ins; 22 del; 52 mod
  Patch: https://git.openjdk.org/valhalla/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1081/head:pull/1081

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


From thartmann at openjdk.org  Wed Apr 24 14:33:43 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 24 Apr 2024 14:33:43 GMT
Subject: [lworld] Integrated: 8330833: [lworld] Handle deoptimization during
 value object construction
In-Reply-To: <BrZfA-05ewKH50wVTRsGZR5LHsypyT9C9-RLT6wPxoQ=.e83e9946-e693-4d0b-8b06-58d1c8805649@github.com>
References: <BrZfA-05ewKH50wVTRsGZR5LHsypyT9C9-RLT6wPxoQ=.e83e9946-e693-4d0b-8b06-58d1c8805649@github.com>
Message-ID: <EWlPfGcLpQcEwXzmkMIVS0c5M69pYYye6UzsEkNDBlc=.51314798-9b01-424c-9c9b-5a797768ac67@github.com>

On Wed, 24 Apr 2024 11:20:17 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Follow-up fix from https://github.com/openjdk/valhalla/pull/1064. Debug information at calls/traps in value object constructors is incorrect because the side effects of the constructor are not propagated. As a result, deoptimization creates a wrong state leading to incorrect execution. This patch addresses the remaining issues and adds more tests.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 675c436d
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/675c436da1854b726c53182bb3e5a2831b95b906
Stats:     320 lines in 8 files changed: 246 ins; 22 del; 52 mod

8330833: [lworld] Handle deoptimization during value object construction

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

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


From dsimms at openjdk.org  Thu Apr 25 09:56:16 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 25 Apr 2024 09:56:16 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <l7wHQg4fNyHf4b6F1WMvHhE7c302645RY6QPPQb8GJ8=.680afb0b-4789-4e1b-97d8-cfe3a8a8d4ab@github.com>

Merge jdk-23+1

ClassFile version flick

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

Commit messages:
 - ClassFile version flicks
 - Merge tag 'jdk-23+1' into lworld_merge_jdk_23_1
 - 8319413: Start of release updates for JDK 23

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

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

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


From dsimms at openjdk.org  Thu Apr 25 10:21:39 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 25 Apr 2024 10:21:39 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields
In-Reply-To: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
Message-ID: <Oxars1JhF5uazlE5MJGFhDylbcItoMcS8fwvNh0b_7k=.d02e4e7a-ebf4-4431-9736-659ee078dd27@github.com>

On Thu, 18 Apr 2024 20:40:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> This is the first step in supporting nullable flat fields in JEP 401.
> Those changes give value fields the optional capability to be associated with a null marker that indicates if the value if the field is null or not. Null markers are integrated in the object layout, and in the field metadata (in both compresses and uncompressed forms).
> Field accesses in the x86 and the arch64 interpreter have been extended to check the presence of a null marker when reading a field. If present, the null marker is checked in reads and updated on writes.
> 
> The field layout logic is becoming more complex (and the complexity will continue to increase in the future with the addition of atomic flat fields and atomic nullable flat fields). So the changeset includes a test framework able to verify the consistency of fields layout using the output of -XX:+PrintFieldLayout. The format of data printed by PrintFieldLayout has been extended and modified to be easier to parse.

test/hotspot/jtreg/runtime/valhalla/inlinetypes/NullableFlatFieldTest.java line 29:

> 27:  * @modules java.base/jdk.internal.vm.annotation
> 28:  * @enablePreview
> 29:  * @run main/othervm -XX:+EnableNullableFieldFlattening -XX:+PrintInlineLayout NullableFlatFieldTest

`PrintInlineLayout` isn't a "product flag" is it ? Should the test be debug only, or should we make `PrintInlineLayout` a product flag ? I'd consider the later for EA release.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1579233942


From dsimms at openjdk.org  Thu Apr 25 10:40:42 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 25 Apr 2024 10:40:42 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields
In-Reply-To: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
Message-ID: <sWCX8LAcvCKfpGpSLc-1Qilt1wfHbFKt848DpuWE2KU=.4572327b-f336-4126-8a22-2dae11d8a0e7@github.com>

On Thu, 18 Apr 2024 20:40:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> This is the first step in supporting nullable flat fields in JEP 401.
> Those changes give value fields the optional capability to be associated with a null marker that indicates if the value if the field is null or not. Null markers are integrated in the object layout, and in the field metadata (in both compresses and uncompressed forms).
> Field accesses in the x86 and the arch64 interpreter have been extended to check the presence of a null marker when reading a field. If present, the null marker is checked in reads and updated on writes.
> 
> The field layout logic is becoming more complex (and the complexity will continue to increase in the future with the addition of atomic flat fields and atomic nullable flat fields). So the changeset includes a test framework able to verify the consistency of fields layout using the output of -XX:+PrintFieldLayout. The format of data printed by PrintFieldLayout has been extended and modified to be easier to parse.

test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/NullMarkersTest.java line 276:

> 274:     OutputAnalyzer out = new OutputAnalyzer(pb.start());
> 275: 
> 276:     Asserts.assertEquals(out.getExitValue(), 0, "Something went wrong while running the tests");

Speeds up problem solving if the output and error streams for processes is printed...there is the same issue with `PrintFieldLayout` not being product flag

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1579256501


From dsimms at openjdk.org  Thu Apr 25 11:22:43 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 25 Apr 2024 11:22:43 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields
In-Reply-To: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
Message-ID: <XuhnrB48UQ7ajUWWD4j27ubb3ve9QRv9Nus-xdTX_6c=.4debbff0-fa7a-40c3-b497-c90fecdde8db@github.com>

On Thu, 18 Apr 2024 20:40:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> This is the first step in supporting nullable flat fields in JEP 401.
> Those changes give value fields the optional capability to be associated with a null marker that indicates if the value if the field is null or not. Null markers are integrated in the object layout, and in the field metadata (in both compresses and uncompressed forms).
> Field accesses in the x86 and the arch64 interpreter have been extended to check the presence of a null marker when reading a field. If present, the null marker is checked in reads and updated on writes.
> 
> The field layout logic is becoming more complex (and the complexity will continue to increase in the future with the addition of atomic flat fields and atomic nullable flat fields). So the changeset includes a test framework able to verify the consistency of fields layout using the output of -XX:+PrintFieldLayout. The format of data printed by PrintFieldLayout has been extended and modified to be easier to parse.

test/hotspot/jtreg/runtime/valhalla/inlinetypes/NullableFlatFieldTest.java line 29:

> 27:  * @modules java.base/jdk.internal.vm.annotation
> 28:  * @enablePreview
> 29:  * @run main/othervm -XX:+EnableNullableFieldFlattening -XX:+PrintInlineLayout NullableFlatFieldTest

Although the tests are short (just now), shouldn't all uses of `EnableNullableFieldFlattening` need `-Xint` just now ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1579303848


From vromero at openjdk.org  Fri Apr 26 03:46:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 03:46:06 GMT
Subject: [lworld] Integrated: 8331154: [lworld] javac is not adding the STRICT
 flag to final instance fields of value records
Message-ID: <9BcGujJVxtougCoY0Kc8MaFPUNr7VEXAJYgMMjdSgmc=.5449cfd0-5cf5-42eb-91f0-0b99db62d58a@github.com>

The compiler has an internal STRICT flag that was clashing with another flag used in record fields. Due to this clash the internal STRICT flag was being interpreted as another flag. The fix here is to select another bit position for the STRICT flag avoiding the clash. There was also another issue with locals captured by anonymous classes for which the STRICT flag was not being generated. This issue has been fixed as part of this PR too.

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

Commit messages:
 - 8331154: [lworld] javac is not adding the STRICT flag to final instance fields of value records

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

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


From vromero at openjdk.org  Fri Apr 26 03:46:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 03:46:06 GMT
Subject: [lworld] Integrated: 8331154: [lworld] javac is not adding the STRICT
 flag to final instance fields of value records
In-Reply-To: <9BcGujJVxtougCoY0Kc8MaFPUNr7VEXAJYgMMjdSgmc=.5449cfd0-5cf5-42eb-91f0-0b99db62d58a@github.com>
References: <9BcGujJVxtougCoY0Kc8MaFPUNr7VEXAJYgMMjdSgmc=.5449cfd0-5cf5-42eb-91f0-0b99db62d58a@github.com>
Message-ID: <Kv_h6VuO-1CWP4xTQBG2x7B4fXtvpM1sMcPepHm02r8=.76984ef7-f8da-4c2f-9f12-2566ab5f339c@github.com>

On Fri, 26 Apr 2024 03:37:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The compiler has an internal STRICT flag that was clashing with another flag used in record fields. Due to this clash the internal STRICT flag was being interpreted as another flag. The fix here is to select another bit position for the STRICT flag avoiding the clash. There was also another issue with locals captured by anonymous classes for which the STRICT flag was not being generated. This issue has been fixed as part of this PR too.

This pull request has now been integrated.

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

8331154: [lworld] javac is not adding the STRICT flag to final instance fields of value records

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

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


From dsimms at openjdk.org  Fri Apr 26 07:41:58 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 26 Apr 2024 07:41:58 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <l7wHQg4fNyHf4b6F1WMvHhE7c302645RY6QPPQb8GJ8=.680afb0b-4789-4e1b-97d8-cfe3a8a8d4ab@github.com>
References: <l7wHQg4fNyHf4b6F1WMvHhE7c302645RY6QPPQb8GJ8=.680afb0b-4789-4e1b-97d8-cfe3a8a8d4ab@github.com>
Message-ID: <I2L_ZcUSuDuAvfvLXF2ySJlGik6THgYo8b5vVfFApNs=.a6013edf-3d56-4cc4-a195-6ea8535c3e3e@github.com>

On Thu, 25 Apr 2024 09:49:55 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+1
> 
> ClassFile version flick

This pull request has now been integrated.

Changeset: 24644e77
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/24644e77cf1dbfbaab7bb4a2b76473072c48a434
Stats:     4954 lines in 109 files changed: 4816 ins; 0 del; 138 mod

Merge jdk

Merge jdk-23+1

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

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


From dsimms at openjdk.org  Fri Apr 26 13:36:06 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 26 Apr 2024 13:36:06 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <1MoJYG96MRwHL1L1YwnGIX1HLJON8HZjVPp60d00Y8A=.d4ba6b4d-a6d6-49ec-aa46-6d053f685a85@github.com>

Merge jdk-23+5

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

Commit messages:
 - Remove warnings preventing compilation
 - Fix exports and exclude the copy of asmtools (they don't compile as a whole)
 - Logical merge errors in tests
 - Logical merge errors
 - Merge tag 'jdk-23+5' into lworld_merge_jdk_23_2
 - 8321616: Retire binary test vectors in test/jdk/java/util/zip/ZipFile
 - 8317804: com/sun/jdi/JdwpAllowTest.java fails on Alpine 3.17 / 3.18
 - 8322565: (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits
 - 8322982: CTW fails to build after 8308753
 - 8320788: The system properties page is missing some properties
 - ... and 285 more: https://git.openjdk.org/valhalla/compare/24644e77...d8898796

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

Changes: https://git.openjdk.org/valhalla/pull/1084/files
  Stats: 38921 lines in 1108 files changed: 27061 ins; 6839 del; 5021 mod
  Patch: https://git.openjdk.org/valhalla/pull/1084.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1084/head:pull/1084

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


From mchung at openjdk.org  Fri Apr 26 23:35:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 23:35:46 GMT
Subject: [lworld] Integrated: 8331220: [lworld] minor clean up (no runtime
 change)
Message-ID: <s5GQKWRJ7g4PCvy-urcAopQo-xmPmGvcXwmW6ThMgk4=.3d13a97b-56cb-4435-9e7a-807374d68e41@github.com>

Mostly documentation clean up.   Minor code clean up.

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

Commit messages:
 - typo
 - 8331220: [lworld] minor clean up (no runtime change)

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

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


From mchung at openjdk.org  Fri Apr 26 23:35:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 23:35:46 GMT
Subject: [lworld] Integrated: 8331220: [lworld] minor clean up (no runtime
 change)
In-Reply-To: <s5GQKWRJ7g4PCvy-urcAopQo-xmPmGvcXwmW6ThMgk4=.3d13a97b-56cb-4435-9e7a-807374d68e41@github.com>
References: <s5GQKWRJ7g4PCvy-urcAopQo-xmPmGvcXwmW6ThMgk4=.3d13a97b-56cb-4435-9e7a-807374d68e41@github.com>
Message-ID: <fX2wSNjid5VYrHjGgWNcqJa1-zfA8BQBaAlxFnRjRss=.cf17815c-06c9-485f-a96d-ff5c3e696975@github.com>

On Fri, 26 Apr 2024 23:25:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Mostly documentation clean up.   Minor code clean up.

This pull request has now been integrated.

Changeset: ff56a574
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ff56a5743263b7c0d8c1d9ea1b54f25e2e765019
Stats:     28 lines in 7 files changed: 3 ins; 9 del; 16 mod

8331220: [lworld] minor clean up (no runtime change)

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

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


From mchung at openjdk.org  Fri Apr 26 23:39:41 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 Apr 2024 23:39:41 GMT
Subject: [lworld] RFR: 8331217: [lworld] sun.misc.Unsafe should fail to get the
 offset of a field of value type
Message-ID: <en6BxY4KBYElDxG66Af9ob7zyP8a6rBnKedjcirvEts=.ca1b34f2-5b0f-4dfb-bad4-cd84d3475539@github.com>

Memory-access methods in `sun.misc.Unsafe` are proposed to be deprecated for removal [1]. `staticFieldOffset`, `staticFieldBase` and `staticFieldOffset` should throw UOE if the given field is of value type.

[1] https://openjdk.org/jeps/8323072

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

Commit messages:
 - 8331217: [lworld] sun.misc.Unsafe should fail to get the offset of a field of value type

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

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


From duke at openjdk.org  Sun Apr 28 20:23:31 2024
From: duke at openjdk.org (Federico Medina)
Date: Sun, 28 Apr 2024 20:23:31 GMT
Subject: [valhalla-docs] RFR: 01-background.md: fix link in-defense-of-erasure
 md
Message-ID: <ze8d-67Y1Avx0xJ_2Zs0_qXdbbvBBv-LwrRfIpgVTJI=.8f90b28b-48ea-4574-b62d-7b567c0cf43d@github.com>

Udate link `in-defense-of-erasure.html` -> `in-defense-of-erasure`

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

Commit messages:
 - 01-background.md: fix link md (#1)

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

PR: https://git.openjdk.org/valhalla-docs/pull/12


From chagedorn at openjdk.org  Mon Apr 29 07:04:25 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 29 Apr 2024 07:04:25 GMT
Subject: [lworld] RFR: 8326401: [lworld]
 compiler/valhalla/inlinetypes/TestLWorld.java fails after merge of jdk-22+25
Message-ID: <rT7XVasRZ1Pk5A__ptygsDkK5HcuLBEq3NNBYU5wc3w=.d9201de9-0f9e-49e8-b244-b65c26733292@github.com>

The uncommented IR rule no longer fails with latest `lworld`. I'm therefore simply proposing to re-enable the IR rule again.

Tested `TestLWorld.java` with tier1-4 flag settings.

Thanks,
Christian

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

Commit messages:
 - 8326401: [lworld] compiler/valhalla/inlinetypes/TestLWorld.java fails after merge of jdk-22+25

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

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


From dsimms at openjdk.org  Mon Apr 29 07:49:36 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 29 Apr 2024 07:49:36 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <1MoJYG96MRwHL1L1YwnGIX1HLJON8HZjVPp60d00Y8A=.d4ba6b4d-a6d6-49ec-aa46-6d053f685a85@github.com>
References: <1MoJYG96MRwHL1L1YwnGIX1HLJON8HZjVPp60d00Y8A=.d4ba6b4d-a6d6-49ec-aa46-6d053f685a85@github.com>
Message-ID: <-UKdC3r_TNFsSLZVLJHBhZwNtciHQfD6xsb8nFQGrxY=.b6e515de-2085-4633-aee1-0b913e9eb744@github.com>

On Fri, 26 Apr 2024 13:12:49 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+5

This pull request has now been integrated.

Changeset: f40784df
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f40784df6865269f0afb14e032486684de50a6b4
Stats:     38921 lines in 1108 files changed: 27061 ins; 6839 del; 5021 mod

Merge jdk

Merge jdk-23+5

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

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


From thartmann at openjdk.org  Mon Apr 29 08:49:29 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 29 Apr 2024 08:49:29 GMT
Subject: [lworld] RFR: 8326401: [lworld]
 compiler/valhalla/inlinetypes/TestLWorld.java fails after merge of jdk-22+25
In-Reply-To: <rT7XVasRZ1Pk5A__ptygsDkK5HcuLBEq3NNBYU5wc3w=.d9201de9-0f9e-49e8-b244-b65c26733292@github.com>
References: <rT7XVasRZ1Pk5A__ptygsDkK5HcuLBEq3NNBYU5wc3w=.d9201de9-0f9e-49e8-b244-b65c26733292@github.com>
Message-ID: <N0Qg95heyN6G0QBKLYSjoGT7Ftu6cGLdR1ZWQcSJr44=.268f8c95-f7a2-457f-ae97-fbd48e19c50c@github.com>

On Mon, 29 Apr 2024 06:58:47 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The uncommented IR rule no longer fails with latest `lworld`. I'm therefore simply proposing to re-enable the IR rule again.
> 
> Tested `TestLWorld.java` with tier1-4 flag settings.
> 
> Thanks,
> Christian

Looks good, thanks!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1087#pullrequestreview-2027878906


From chagedorn at openjdk.org  Mon Apr 29 09:04:17 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 29 Apr 2024 09:04:17 GMT
Subject: [lworld] RFR: 8326401: [lworld]
 compiler/valhalla/inlinetypes/TestLWorld.java fails after merge of jdk-22+25
In-Reply-To: <rT7XVasRZ1Pk5A__ptygsDkK5HcuLBEq3NNBYU5wc3w=.d9201de9-0f9e-49e8-b244-b65c26733292@github.com>
References: <rT7XVasRZ1Pk5A__ptygsDkK5HcuLBEq3NNBYU5wc3w=.d9201de9-0f9e-49e8-b244-b65c26733292@github.com>
Message-ID: <IWD2RonNV0Z154Gbi-0u2hsYQEFciABCxm2_QBM0FR4=.3a2f20a6-92ac-4b24-80fb-6b9e966353c2@github.com>

On Mon, 29 Apr 2024 06:58:47 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The uncommented IR rule no longer fails with latest `lworld`. I'm therefore simply proposing to re-enable the IR rule again.
> 
> Tested `TestLWorld.java` with tier1-4 flag settings.
> 
> Thanks,
> Christian

Thanks Tobias for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1087#issuecomment-2082207540


From fparain at openjdk.org  Mon Apr 29 14:41:45 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 29 Apr 2024 14:41:45 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
Message-ID: <a4lunRrpGn8OtepUkR98e5WGlbEMhXijLmUmOvSVyp4=.07382625-c856-4380-95ad-c61e9bef39a9@github.com>

> This is the first step in supporting nullable flat fields in JEP 401.
> Those changes give value fields the optional capability to be associated with a null marker that indicates if the value if the field is null or not. Null markers are integrated in the object layout, and in the field metadata (in both compresses and uncompressed forms).
> Field accesses in the x86 and the arch64 interpreter have been extended to check the presence of a null marker when reading a field. If present, the null marker is checked in reads and updated on writes.
> 
> The field layout logic is becoming more complex (and the complexity will continue to increase in the future with the addition of atomic flat fields and atomic nullable flat fields). So the changeset includes a test framework able to verify the consistency of fields layout using the output of -XX:+PrintFieldLayout. The format of data printed by PrintFieldLayout has been extended and modified to be easier to parse.

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Fixing issues spotted during reviews

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1078/files
  - new: https://git.openjdk.org/valhalla/pull/1078/files/684da164..34180e09

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

  Stats: 117 lines in 6 files changed: 96 ins; 2 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1078.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1078/head:pull/1078

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


From fparain at openjdk.org  Mon Apr 29 15:38:25 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 29 Apr 2024 15:38:25 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <XuhnrB48UQ7ajUWWD4j27ubb3ve9QRv9Nus-xdTX_6c=.4debbff0-fa7a-40c3-b497-c90fecdde8db@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
 <XuhnrB48UQ7ajUWWD4j27ubb3ve9QRv9Nus-xdTX_6c=.4debbff0-fa7a-40c3-b497-c90fecdde8db@github.com>
Message-ID: <P9dRU5oAMrRtQuYVof4Xmp69ambkXf06RMgIvsgidRI=.b20c9b63-1035-48ff-903f-10e20c81a85e@github.com>

On Thu, 25 Apr 2024 11:20:05 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing issues spotted during reviews
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/NullableFlatFieldTest.java line 29:
> 
>> 27:  * @modules java.base/jdk.internal.vm.annotation
>> 28:  * @enablePreview
>> 29:  * @run main/othervm -XX:+EnableNullableFieldFlattening -XX:+PrintInlineLayout NullableFlatFieldTest
> 
> Although the tests are short (just now), shouldn't all uses of `EnableNullableFieldFlattening` need `-Xint` just now ?

Fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1583295136


From fparain at openjdk.org  Mon Apr 29 15:44:32 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 29 Apr 2024 15:44:32 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <Oxars1JhF5uazlE5MJGFhDylbcItoMcS8fwvNh0b_7k=.d02e4e7a-ebf4-4431-9736-659ee078dd27@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
 <Oxars1JhF5uazlE5MJGFhDylbcItoMcS8fwvNh0b_7k=.d02e4e7a-ebf4-4431-9736-659ee078dd27@github.com>
Message-ID: <LR9wAAMOMHObH61MHsjjugZwqg37J1p3aEhz2au7WXA=.3f178b9e-512e-425f-bc75-a525636b5ff8@github.com>

On Thu, 25 Apr 2024 10:19:02 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing issues spotted during reviews
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/NullableFlatFieldTest.java line 29:
> 
>> 27:  * @modules java.base/jdk.internal.vm.annotation
>> 28:  * @enablePreview
>> 29:  * @run main/othervm -XX:+EnableNullableFieldFlattening -XX:+PrintInlineLayout NullableFlatFieldTest
> 
> `PrintInlineLayout` isn't a "product flag" is it ? Should the test be debug only, or should we make `PrintInlineLayout` a product flag ? I'd consider the later for EA release.

`PrintFieldLayout` and `PrintInlineLayout` are now product diagnostic flags.

> test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/NullMarkersTest.java line 276:
> 
>> 274:     OutputAnalyzer out = new OutputAnalyzer(pb.start());
>> 275: 
>> 276:     Asserts.assertEquals(out.getExitValue(), 0, "Something went wrong while running the tests");
> 
> Speeds up problem solving if the output and error streams for processes is printed...there is the same issue with `PrintFieldLayout` not being product flag

The output now contains more information to speed-up investigations. In most cases, the output is too big to be saved by jtreg with a normal configuration, but added information should indicate in which class an error has been detected (last part of the log is saved by jtreg). 
A better solution would be to not print the whole output, but just the layouts of the classes involved in the fail check. But this would require significant work and this patch is already big. I'd prefer to push that in another RFE.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1583306227
PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1583304944


From mchung at openjdk.org  Mon Apr 29 18:05:32 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 29 Apr 2024 18:05:32 GMT
Subject: [lworld] Integrated: 8331217: [lworld] sun.misc.Unsafe should fail to
 get the offset of a field of value type
In-Reply-To: <en6BxY4KBYElDxG66Af9ob7zyP8a6rBnKedjcirvEts=.ca1b34f2-5b0f-4dfb-bad4-cd84d3475539@github.com>
References: <en6BxY4KBYElDxG66Af9ob7zyP8a6rBnKedjcirvEts=.ca1b34f2-5b0f-4dfb-bad4-cd84d3475539@github.com>
Message-ID: <o4hf8Wbf3dAncaTcIFod4YZ-z5IafwOlPR7IN-zE0IY=.229dad52-2007-4c3e-9b6a-982b118c583c@github.com>

On Fri, 26 Apr 2024 23:33:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Memory-access methods in `sun.misc.Unsafe` are proposed to be deprecated for removal [1]. `staticFieldOffset`, `staticFieldBase` and `staticFieldOffset` should throw UOE if the given field is of value type.
> 
> [1] https://openjdk.org/jeps/8323072

This pull request has now been integrated.

Changeset: 9ecd7cee
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9ecd7cee4aac2b560016c9766df35e3fca3fc8c1
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8331217: [lworld] sun.misc.Unsafe should fail to get the offset of a field of value type

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

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


From dsimms at openjdk.org  Tue Apr 30 06:20:20 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 30 Apr 2024 06:20:20 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <a4lunRrpGn8OtepUkR98e5WGlbEMhXijLmUmOvSVyp4=.07382625-c856-4380-95ad-c61e9bef39a9@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
 <a4lunRrpGn8OtepUkR98e5WGlbEMhXijLmUmOvSVyp4=.07382625-c856-4380-95ad-c61e9bef39a9@github.com>
Message-ID: <qVcpBiydfS0lwtHH1ZRsg3YPwf9HAKNeFJnt1jt-SL0=.dd3a88fb-c783-49bd-80a2-4e4c00ce6e49@github.com>

On Mon, 29 Apr 2024 14:41:45 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is the first step in supporting nullable flat fields in JEP 401.
>> Those changes give value fields the optional capability to be associated with a null marker that indicates if the value if the field is null or not. Null markers are integrated in the object layout, and in the field metadata (in both compresses and uncompressed forms).
>> Field accesses in the x86 and the arch64 interpreter have been extended to check the presence of a null marker when reading a field. If present, the null marker is checked in reads and updated on writes.
>> 
>> The field layout logic is becoming more complex (and the complexity will continue to increase in the future with the addition of atomic flat fields and atomic nullable flat fields). So the changeset includes a test framework able to verify the consistency of fields layout using the output of -XX:+PrintFieldLayout. The format of data printed by PrintFieldLayout has been extended and modified to be easier to parse.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing issues spotted during reviews

Good initial runtime implementation to hang the JIT implementation off of, further work for other PRs...good to go !

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1078#pullrequestreview-2030292225


From dsimms at openjdk.org  Tue Apr 30 08:09:32 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 30 Apr 2024 08:09:32 GMT
Subject: [lworld] RFR: 8331362: [lworld] JDK-8331217 breaks the build
Message-ID: <w8fq4vJvoC82bsdWQ_hbK9rY7OyALru6PAWhVzAcHjs=.2eae9051-522a-4d76-b12e-279ff65a4bec@github.com>

Avoid preview feature code

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

Commit messages:
 - 8331362: [lworld] JDK-8331217 breaks the build

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

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


From dsimms at openjdk.org  Tue Apr 30 08:52:27 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 30 Apr 2024 08:52:27 GMT
Subject: [lworld] Integrated: 8331362: [lworld] JDK-8331217 breaks the build
In-Reply-To: <w8fq4vJvoC82bsdWQ_hbK9rY7OyALru6PAWhVzAcHjs=.2eae9051-522a-4d76-b12e-279ff65a4bec@github.com>
References: <w8fq4vJvoC82bsdWQ_hbK9rY7OyALru6PAWhVzAcHjs=.2eae9051-522a-4d76-b12e-279ff65a4bec@github.com>
Message-ID: <nVOT0YTCY9K6JIjfmPy5IIgXSF-oODlZgFMV8FQ6caw=.7c7709af-c991-494b-b422-96cd49eb5282@github.com>

On Tue, 30 Apr 2024 08:05:04 GMT, David Simms <dsimms at openjdk.org> wrote:

> Avoid preview feature code

This pull request has now been integrated.

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

8331362: [lworld] JDK-8331217 breaks the build

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

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


From dsimms at openjdk.org  Tue Apr 30 09:02:04 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 30 Apr 2024 09:02:04 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <5B00UbI39ekohTjgj7jDbCp7CqMePBUVAY3ch-dMFQ8=.fc091549-a93f-457a-9343-ad8adb43e17c@github.com>

Merge tag 'jdk-23+6' into lworld_merge_jdk_23_6
Added tag jdk-23+6 for changeset ff8cc268

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

Commit messages:
 - Merge tag 'jdk-23+6' into lworld_merge_jdk_23_6
 - 8323694: RISC-V: Unnecessary ResourceMark in NativeCall::set_destination_mt_safe
 - 8316497: ColorConvertOp - typo for non-ICC conversions needs one-line fix
 - 8323554: The typos in Javadoc: "@return if "
 - 8322100: Fix GCMIncrementByte4 & GCMIncrementDirect4, and increase overlap testing
 - 8317771: [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma
 - 8323710: (fc) FileChannel.lock creates a FileKey with a poor hashCode after JDK-8321429 (win)
 - 8321561: (fs) Clarify non-atomic behavior of Files.move
 - 8323794: Remove unused jimage compressor plugin configuration
 - 8321137: Reconsider ICStub alignment
 - ... and 98 more: https://git.openjdk.org/valhalla/compare/9ecd7cee...2eb5c583

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

Changes: https://git.openjdk.org/valhalla/pull/1089/files
  Stats: 16248 lines in 383 files changed: 8520 ins; 6460 del; 1268 mod
  Patch: https://git.openjdk.org/valhalla/pull/1089.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1089/head:pull/1089

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


From chagedorn at openjdk.org  Tue Apr 30 09:19:33 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 30 Apr 2024 09:19:33 GMT
Subject: [lworld] Integrated: 8326401: [lworld]
 compiler/valhalla/inlinetypes/TestLWorld.java fails after merge of jdk-22+25
In-Reply-To: <rT7XVasRZ1Pk5A__ptygsDkK5HcuLBEq3NNBYU5wc3w=.d9201de9-0f9e-49e8-b244-b65c26733292@github.com>
References: <rT7XVasRZ1Pk5A__ptygsDkK5HcuLBEq3NNBYU5wc3w=.d9201de9-0f9e-49e8-b244-b65c26733292@github.com>
Message-ID: <VR2bNJ9YdoY6TobP1XCh3D2L7n08OwvPjuRiKFuNEdg=.359b538f-df95-47ca-a116-37ba490d0745@github.com>

On Mon, 29 Apr 2024 06:58:47 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The uncommented IR rule no longer fails with latest `lworld`. I'm therefore simply proposing to re-enable the IR rule again.
> 
> Tested `TestLWorld.java` with tier1-4 flag settings.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 380e8f68
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/380e8f68e0f767bd6881e8e8590584b69f61d9cd
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8326401: [lworld] compiler/valhalla/inlinetypes/TestLWorld.java fails after merge of jdk-22+25

Reviewed-by: thartmann

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

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


From heidinga at openjdk.org  Tue Apr 30 14:19:19 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 30 Apr 2024 14:19:19 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <a4lunRrpGn8OtepUkR98e5WGlbEMhXijLmUmOvSVyp4=.07382625-c856-4380-95ad-c61e9bef39a9@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
 <a4lunRrpGn8OtepUkR98e5WGlbEMhXijLmUmOvSVyp4=.07382625-c856-4380-95ad-c61e9bef39a9@github.com>
Message-ID: <BTYUj54aGyvvPzBBlin1mkIArOUR6n-NsSIKpOLzRaM=.d352b81d-e289-4cdf-96d5-871578f3a086@github.com>

On Mon, 29 Apr 2024 14:41:45 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is the first step in supporting nullable flat fields in JEP 401.
>> Those changes give value fields the optional capability to be associated with a null marker that indicates if the value if the field is null or not. Null markers are integrated in the object layout, and in the field metadata (in both compresses and uncompressed forms).
>> Field accesses in the x86 and the arch64 interpreter have been extended to check the presence of a null marker when reading a field. If present, the null marker is checked in reads and updated on writes.
>> 
>> The field layout logic is becoming more complex (and the complexity will continue to increase in the future with the addition of atomic flat fields and atomic nullable flat fields). So the changeset includes a test framework able to verify the consistency of fields layout using the output of -XX:+PrintFieldLayout. The format of data printed by PrintFieldLayout has been extended and modified to be easier to parse.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing issues spotted during reviews

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 3355:

> 3353:   // access field
> 3354:   switch (bytecode()) {
> 3355:   case Bytecodes::_fast_vputfield: //fall through

Suggestion:

  case Bytecodes::_fast_vputfield:

src/hotspot/cpu/aarch64/templateTable_aarch64.cpp line 3359:

> 3357:       Label is_flat, has_null_marker, done;
> 3358:       __ test_field_has_null_marker(r3, noreg /* temp */, has_null_marker);
> 3359:       __ null_check(r0);

Does `__ null_check(r0);` need to occur first to make sure we consistently null check the receiver object?  Or is the null receiver check handled in the InterpreterRuntime::write_nullale_flat_field helper?

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

> 352:       has_instance_fields = true;
> 353:       LayoutRawBlock* block;
> 354:       // if (fs.field_flags().is_null_free_inline_type()) {

Left over commented code or breadcrumb for future update?

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

> 798:       bool value_has_oops = field_is_known_value_class ? _inline_type_field_klasses->at(fieldinfo.index())->nonstatic_oop_count() > 0 : true;
> 799:       bool is_candidate_for_flattening = fieldinfo.field_flags().is_null_free_inline_type() || (EnableNullableFieldFlattening && field_is_known_value_class && !value_has_oops);
> 800:       // if (!fieldinfo.field_flags().is_null_free_inline_type()) {

Is it worth pulling this into a `array_candidate_for_flattening` helper method?  It's a complex set of conditions and this is the second occurrence of it...

src/hotspot/share/interpreter/interpreterRuntime.cpp line 355:

> 353:   int nm_offset = ik->null_marker_offsets_array()->at(entry->field_index());
> 354:   if (val_h() == nullptr) {
> 355:     obj_h()->byte_field_put(nm_offset, (jbyte)0);

Do we need a barrier here?  When we write the null marker, it is as if we wrote the null marker and then nulled the fields out (which we don't actually do) which makes me think we always need the barrier after writing the null marker to be consistent with the non-null case.

src/hotspot/share/interpreter/interpreterRuntime.cpp line 362:

> 360:     // The interpreter copies values with a bulk operation
> 361:     // To avoid accidently setting the null marker to "null" during
> 362:     // the copying, the null marker is set to non zero in the source object

Is this saying if the null marker is embedded in the value field layout rather than placed separately, we set it to non-null before writing it into the container?  This tripped me up a little bit reading the code but I think it makes sense

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1581317255
PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1581320878
PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1584872488
PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1584879794
PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1584897107
PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1584902626


From heidinga at openjdk.org  Tue Apr 30 14:19:20 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 30 Apr 2024 14:19:20 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <BTYUj54aGyvvPzBBlin1mkIArOUR6n-NsSIKpOLzRaM=.d352b81d-e289-4cdf-96d5-871578f3a086@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
 <a4lunRrpGn8OtepUkR98e5WGlbEMhXijLmUmOvSVyp4=.07382625-c856-4380-95ad-c61e9bef39a9@github.com>
 <BTYUj54aGyvvPzBBlin1mkIArOUR6n-NsSIKpOLzRaM=.d352b81d-e289-4cdf-96d5-871578f3a086@github.com>
Message-ID: <aMG_kUbv5X7ukTYS8r3mWjrJ0CDMA3oBtbmHrAO2TSA=.5980c34f-c9e0-413d-984b-dc05ef6b21c9@github.com>

On Tue, 30 Apr 2024 14:12:04 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing issues spotted during reviews
>
> src/hotspot/share/interpreter/interpreterRuntime.cpp line 362:
> 
>> 360:     // The interpreter copies values with a bulk operation
>> 361:     // To avoid accidently setting the null marker to "null" during
>> 362:     // the copying, the null marker is set to non zero in the source object
> 
> Is this saying if the null marker is embedded in the value field layout rather than placed separately, we set it to non-null before writing it into the container?  This tripped me up a little bit reading the code but I think it makes sense

How does that work for our memory barriers then?  Do we not need a release here as well given the acquire used to read the null marker?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1078#discussion_r1584906915