From fparain at openjdk.org  Wed May  1 13:44:10 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 May 2024 13:44:10 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: <gvPCD2FIZs8ker2g6Ygkr3_0UPP3O4cJ4TMnV6j3dPY=.75f938eb-196a-431f-b5f2-f51df18a39d9@github.com>

On Fri, 26 Apr 2024 17:25:03 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/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?

The receiver object is in r2, which is checked when retrieved with pop_and_check_object(). r0 is the new field value. If the flat field has a null marker, it means it is nullable, so null is a valid value for r0, and the null check must not be performed. If the field doesn't have a null marker, this is a null-free field, and the null check is performed. So I think the null_check(r0) is at the right place.

> 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?

Old code, will be removed in next commit.

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

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


From heidinga at openjdk.org  Wed May  1 13:47:59 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 1 May 2024 13:47:59 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <gvPCD2FIZs8ker2g6Ygkr3_0UPP3O4cJ4TMnV6j3dPY=.75f938eb-196a-431f-b5f2-f51df18a39d9@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>
 <gvPCD2FIZs8ker2g6Ygkr3_0UPP3O4cJ4TMnV6j3dPY=.75f938eb-196a-431f-b5f2-f51df18a39d9@github.com>
Message-ID: <MdN28H9cEoBBrBzC4nFAKevHtMeF0DXqlzfiRhmCJes=.81a2ddfa-9b94-4b03-94de-8fc5c0a65c4c@github.com>

On Wed, 1 May 2024 13:40:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> 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?
>
> The receiver object is in r2, which is checked when retrieved with pop_and_check_object(). r0 is the new field value. If the flat field has a null marker, it means it is nullable, so null is a valid value for r0, and the null check must not be performed. If the field doesn't have a null marker, this is a null-free field, and the null check is performed. So I think the null_check(r0) is at the right place.

You're right.  Thanks for checking.

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

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


From fparain at openjdk.org  Wed May  1 13:53:05 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 May 2024 13:53:05 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: <jqxoTnriVYYH-sjl2WXng5E-wmTKsvy13uW9Ts-fsTI=.cc320bc9-f060-4aa5-9ce6-0211428af292@github.com>

On Tue, 30 Apr 2024 14:08:33 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 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.

In this case, there is a single write from the current thread, so there's no visibility ordering issue like with the non-null case. A concurrently reading thread will check (or has already read) the null marker, and this would be no different than reading a reference field being set to null. So I don't think we need a barrier here, but if you really think there's a potential issue, I can add one.

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

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


From fparain at openjdk.org  Wed May  1 13:57:11 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 May 2024 13:57:11 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <aMG_kUbv5X7ukTYS8r3mWjrJ0CDMA3oBtbmHrAO2TSA=.5980c34f-c9e0-413d-984b-dc05ef6b21c9@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>
 <aMG_kUbv5X7ukTYS8r3mWjrJ0CDMA3oBtbmHrAO2TSA=.5980c34f-c9e0-413d-984b-dc05ef6b21c9@github.com>
Message-ID: <cHc4Be_XlLLj1oZpsyd1HubW5RuTSSfobF04T1SIzJw=.12475da0-51fc-48ec-9170-0590a6e348e0@github.com>

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

>> 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?

This particular case cannot currently happen with JEP 401 model implementation (nullable flat field are limited to single field values until we have atomic updates supported). But it involves the tearing issue the interpreter has in some cases. So, even adding a barrier would not make the code correct. I'd prefer to address the issue of this particular code when fixing the wider interpreter tearing issue.

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

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


From fparain at openjdk.org  Wed May  1 14:02:14 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 May 2024 14:02:14 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: <Mem_znvAIon8by6uSS2jSwAh9QVQzq11HHOxBLVBivA=.f1ab1340-4326-4fce-90ed-ff649a45d47f@github.com>

On Fri, 26 Apr 2024 17:21:16 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/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:

Fixed in next commit.

> 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...

I don't like the duplication either, and having a helper method would make the code easier to read. However, this is a section of code under big transformations, with nullable flat field being added, then next the atomic fields, then the nullable atomic fields. Before refactoring, I'd prefer to wait until all the cases are covered, so we know exactly all the parameters the helper method will require, and if the two cases are still identical or if some divergences appeared.

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

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


From fparain at openjdk.org  Wed May  1 14:59:20 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 May 2024 14:59:20 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v3]
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: <GRpGAGCbWC9AFnUYchLukbeR1Nq-Zh_3ghYHOtyRboI=.38164230-6b99-4d4e-87a1-5937ccb35f95@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:

  More fixes from reviews

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

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

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

  Stats: 28 lines in 3 files changed: 26 ins; 1 del; 1 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 heidinga at openjdk.org  Wed May  1 15:18:01 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 1 May 2024 15:18:01 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v3]
In-Reply-To: <GRpGAGCbWC9AFnUYchLukbeR1Nq-Zh_3ghYHOtyRboI=.38164230-6b99-4d4e-87a1-5937ccb35f95@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
 <GRpGAGCbWC9AFnUYchLukbeR1Nq-Zh_3ghYHOtyRboI=.38164230-6b99-4d4e-87a1-5937ccb35f95@github.com>
Message-ID: <n5UJo9J8IxR-pIfY0CJU-G-xEVocrnpGTv6rfLhNuZU=.2b081385-ad2a-4c2c-ad27-897826142c1e@github.com>

On Wed, 1 May 2024 14:59:20 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:
> 
>   More fixes from reviews

Thanks for the clarifications.  This looks good to me.

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

Marked as reviewed by heidinga (no project role).

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


From heidinga at openjdk.org  Wed May  1 15:18:02 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 1 May 2024 15:18:02 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v2]
In-Reply-To: <jqxoTnriVYYH-sjl2WXng5E-wmTKsvy13uW9Ts-fsTI=.cc320bc9-f060-4aa5-9ce6-0211428af292@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>
 <jqxoTnriVYYH-sjl2WXng5E-wmTKsvy13uW9Ts-fsTI=.cc320bc9-f060-4aa5-9ce6-0211428af292@github.com>
Message-ID: <EsQ5DAM6ETVI_xLwecrYZPPgXyYfysfY3D_5Kz5nu3E=.5018c9b5-546c-42d0-8177-2e6622664e10@github.com>

On Wed, 1 May 2024 13:50:39 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> 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.
>
> In this case, there is a single write from the current thread, so there's no visibility ordering issue like with the non-null case. A concurrently reading thread will check (or has already read) the null marker, and this would be no different than reading a reference field being set to null. So I don't think we need a barrier here, but if you really think there's a potential issue, I can add one.

I think you're right here and we don't need the `release_byte_field_put` here.  Just as we're happy for reads/writes of null references to slowly make their way to other threads, a slow discovery of the null bit is fine given the other value fields are stable before the bit flips.

The barrier you have in place is sufficient for that constraint.

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

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


From fparain at openjdk.org  Wed May  1 15:37:01 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 May 2024 15:37:01 GMT
Subject: [lworld] RFR: 8331006: [lworld] Support of null markers for
 nullable flat fields [v3]
In-Reply-To: <GRpGAGCbWC9AFnUYchLukbeR1Nq-Zh_3ghYHOtyRboI=.38164230-6b99-4d4e-87a1-5937ccb35f95@github.com>
References: <rk2uQ6g3Je_vIjEadtwTYvZSmIJENo1arMb-EnOGr1Y=.95dd2b8b-f946-479f-9b49-0717c77933b6@github.com>
 <GRpGAGCbWC9AFnUYchLukbeR1Nq-Zh_3ghYHOtyRboI=.38164230-6b99-4d4e-87a1-5937ccb35f95@github.com>
Message-ID: <eyJ0C8vBFuCToWGQ2xXhyn7OaaJnKmH3lT0zsjwxBN0=.954438af-586a-4735-b236-19257f4e89dd@github.com>

On Wed, 1 May 2024 14:59:20 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:
> 
>   More fixes from reviews

Mr Simms, Dan,
Thank you for your reviews.
Fred

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

PR Comment: https://git.openjdk.org/valhalla/pull/1078#issuecomment-2088640577


From fparain at openjdk.org  Wed May  1 15:37:03 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 May 2024 15:37:03 GMT
Subject: [lworld] Integrated: 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: <7x-Df85IgBO_LzED23uV2kuAtzpVkKZBfw_QxXPyYhA=.86e51613-c64c-4a87-91da-670afb8e204e@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.

This pull request has now been integrated.

Changeset: eb1df165
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/eb1df16538a32cb9f59db944e24520ea42222d7b
Stats:     2086 lines in 37 files changed: 1891 ins; 13 del; 182 mod

8331006: [lworld] Support of null markers for nullable flat fields

Reviewed-by: dsimms, heidinga

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

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


From mchung at openjdk.org  Wed May  1 16:26:19 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 1 May 2024 16:26:19 GMT
Subject: [lworld] RFR: 8331496: [lworld] Class::isValue,
 Class::isIdentity and new java.lang.reflect APIs should be reflective preview
 API
Message-ID: <8TmIBRLIn2a5WN_Ls47UZKtBRHoNTQoKLAQ8LSoRUwc=.ace3c7a1-d3ee-40c1-9eb8-d2b19957cbd4@github.com>

Mark the reflection APIs added for JEP 401 as reflective preview API.

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

Commit messages:
 - 8331496: [lworld] Class::isValue, Class::isIdentity and new java.lang.reflect APIs should be reflective preview API

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

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


From rriggs at openjdk.org  Wed May  1 16:51:00 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 1 May 2024 16:51:00 GMT
Subject: [lworld] RFR: 8331496: [lworld] Class::isValue,
 Class::isIdentity and new java.lang.reflect APIs should be reflective preview
 API
In-Reply-To: <8TmIBRLIn2a5WN_Ls47UZKtBRHoNTQoKLAQ8LSoRUwc=.ace3c7a1-d3ee-40c1-9eb8-d2b19957cbd4@github.com>
References: <8TmIBRLIn2a5WN_Ls47UZKtBRHoNTQoKLAQ8LSoRUwc=.ace3c7a1-d3ee-40c1-9eb8-d2b19957cbd4@github.com>
Message-ID: <umfCOgwrax1EntuJqxAKtM8NuiOiWFF4R95RoUp6tsI=.7a2cfff7-0eee-44dd-af24-908b76b82fea@github.com>

On Wed, 1 May 2024 16:21:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Mark the reflection APIs added for JEP 401 as reflective preview API.

lgtm.
Thanks for adding the reflective=true to the new method annotations.
That distinction hadn't been a blocker before.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1090#pullrequestreview-2033956520


From vromero at openjdk.org  Wed May  1 20:13:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 May 2024 20:13:41 GMT
Subject: [lworld] Integrated: 8331462: [lworld] javac is setting the ACC_STRICT
 flag for value-based classes
Message-ID: <D2j3fjwLL6vZdypXGH-7EzRDION9xd9kam_IFSn4IFg=.d63d98fa-1fc3-4762-8a67-b577e3e9d309@github.com>

javac is erroneously generating the ACC_STRICT flag for value based classes, so classes annotated with: `@jdk.internal.ValueBased` like `java.lang.Integer` etc has the ACC_STRICT flag set. This flag should only be applied to instance fields of value classes not to any class

TIA

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

Commit messages:
 - removing white space
 - 8331462: [lworld] javac is setting the ACC_STRICT flag for value-based classes

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

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


From vromero at openjdk.org  Wed May  1 20:13:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 May 2024 20:13:42 GMT
Subject: [lworld] Integrated: 8331462: [lworld] javac is setting the ACC_STRICT
 flag for value-based classes
In-Reply-To: <D2j3fjwLL6vZdypXGH-7EzRDION9xd9kam_IFSn4IFg=.d63d98fa-1fc3-4762-8a67-b577e3e9d309@github.com>
References: <D2j3fjwLL6vZdypXGH-7EzRDION9xd9kam_IFSn4IFg=.d63d98fa-1fc3-4762-8a67-b577e3e9d309@github.com>
Message-ID: <M7ttLtV0cueutqYPC2y32iHHzVaViq07DWoT6n2xTW0=.b2ee6c93-5d86-4b91-8b7a-351b32132aa2@github.com>

On Wed, 1 May 2024 20:08:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is erroneously generating the ACC_STRICT flag for value based classes, so classes annotated with: `@jdk.internal.ValueBased` like `java.lang.Integer` etc has the ACC_STRICT flag set. This flag should only be applied to instance fields of value classes not to any class
> 
> TIA

This pull request has now been integrated.

Changeset: 6bb6b080
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6bb6b08039f1c6ae318136ce22cafbf618d590a5
Stats:     103 lines in 2 files changed: 96 ins; 0 del; 7 mod

8331462: [lworld] javac is setting the ACC_STRICT flag for value-based classes

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

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


From mchung at openjdk.org  Wed May  1 21:44:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 1 May 2024 21:44:59 GMT
Subject: [lworld] Integrated: 8331496: [lworld] Class::isValue,
 Class::isIdentity and new java.lang.reflect APIs should be reflective preview
 API
In-Reply-To: <8TmIBRLIn2a5WN_Ls47UZKtBRHoNTQoKLAQ8LSoRUwc=.ace3c7a1-d3ee-40c1-9eb8-d2b19957cbd4@github.com>
References: <8TmIBRLIn2a5WN_Ls47UZKtBRHoNTQoKLAQ8LSoRUwc=.ace3c7a1-d3ee-40c1-9eb8-d2b19957cbd4@github.com>
Message-ID: <7vTJHmKMkmyHc2YMZeZkRKmcveBlHSAh9xRbYOgy8Ik=.6345a5a0-410f-409d-9f5f-17afbc6c2693@github.com>

On Wed, 1 May 2024 16:21:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Mark the reflection APIs added for JEP 401 as reflective preview API.

This pull request has now been integrated.

Changeset: 7a5cdc72
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7a5cdc720091c9a36de65e373ec4b128ad1e7f5e
Stats:     30 lines in 4 files changed: 10 ins; 13 del; 7 mod

8331496: [lworld] Class::isValue, Class::isIdentity and new java.lang.reflect APIs should be reflective preview API

Reviewed-by: rriggs

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

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


From mchung at openjdk.org  Wed May  1 22:34:22 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 1 May 2024 22:34:22 GMT
Subject: [lworld] RFR: 8331521: [lworld] dynamic proxy class does not strictly
 need preload attributes
Message-ID: <0qEEBtMeGaczVqB_gJenBaz3bV2cmxT_BY0gUuPJUDk=.4cce657b-5d11-43d0-802d-5cf6926e23ed@github.com>

This PR takes out the generation of preload attributes in dynamic proxy.

If a proxy interface references any value classes, the value classes are listed in the preload attribute of the interface class.  The classes that are referenced by the proxy interface have already been loaded before the proxy class.  Hence the proxy class can be generated with no preload attributes as it essentially has no effect.

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

Commit messages:
 - 8331521: [lworld] dynamic proxy class does not strictly need preload attributes

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

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


From vromero at openjdk.org  Thu May  2 03:56:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 May 2024 03:56:37 GMT
Subject: [lworld] Integrated: 8331461: [lworld] javac is generating a class
 file with the Preload attribute but with minor version '0'
Message-ID: <is4rpf7GYxPITKFZMSU0J2WjuWpocin0NoSA06_MflE=.01a4eda7-108d-4ef1-b26e-cff81e69de93@github.com>

if we compile:

value class Val {}   and:

class Ident {
    Val val;
}

as in:
`javac -d out --enable-preview -source 23 myTests/Val.java myTests/Ident.java`

Ident.class will have a Preload attribute but its minor version is `0` instead of `65535`, the minor version should indicate that the class file is using preview features.

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

Commit messages:
 - 8331461: [lworld] javac is generating a class file with the Preload attribute but with minor version '0'

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

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


From vromero at openjdk.org  Thu May  2 03:56:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 May 2024 03:56:38 GMT
Subject: [lworld] Integrated: 8331461: [lworld] javac is generating a class
 file with the Preload attribute but with minor version '0'
In-Reply-To: <is4rpf7GYxPITKFZMSU0J2WjuWpocin0NoSA06_MflE=.01a4eda7-108d-4ef1-b26e-cff81e69de93@github.com>
References: <is4rpf7GYxPITKFZMSU0J2WjuWpocin0NoSA06_MflE=.01a4eda7-108d-4ef1-b26e-cff81e69de93@github.com>
Message-ID: <Vp7WU2aYOGDtE-SNc2q5wJlnLMV43yNpYT0Z2MtQ9UY=.c08f1558-eecd-405f-ab38-b877e284a3df@github.com>

On Thu, 2 May 2024 03:51:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> if we compile:
> 
> value class Val {}   and:
> 
> class Ident {
>     Val val;
> }
> 
> as in:
> `javac -d out --enable-preview -source 23 myTests/Val.java myTests/Ident.java`
> 
> Ident.class will have a Preload attribute but its minor version is `0` instead of `65535`, the minor version should indicate that the class file is using preview features.

This pull request has now been integrated.

Changeset: 5951b0c9
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5951b0c9b57321714f18689dd3a03e5cf63d32bb
Stats:     113 lines in 2 files changed: 113 ins; 0 del; 0 mod

8331461: [lworld] javac is generating a class file with the Preload attribute but with minor version '0'

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

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


From dsimms at openjdk.org  Thu May  2 08:03:26 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 2 May 2024 08:03:26 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <5B00UbI39ekohTjgj7jDbCp7CqMePBUVAY3ch-dMFQ8=.fc091549-a93f-457a-9343-ad8adb43e17c@github.com>
References: <5B00UbI39ekohTjgj7jDbCp7CqMePBUVAY3ch-dMFQ8=.fc091549-a93f-457a-9343-ad8adb43e17c@github.com>
Message-ID: <cEV7PBLI5guxtn-JkvC_BmylOcgFvvjBaQ1oe1QYleY=.410e878c-b945-449e-8de4-627c40199aa1@github.com>

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

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

This pull request has now been integrated.

Changeset: 653cf84d
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/653cf84dfbdad2468a553eaad8db42ffa9e5e483
Stats:     16248 lines in 383 files changed: 8520 ins; 6460 del; 1268 mod

Merge jdk

Merge jdk-23+6

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

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


From fparain at openjdk.org  Thu May  2 16:08:17 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 2 May 2024 16:08:17 GMT
Subject: [lworld] RFR: 8331583: [lworld]
 runtime/valhalla/inlinetypes/field_layout/FieldAlignmentTest.java#NoCompressedOops
 fails with compilation errorRemove hard coded Java version number.
Message-ID: <kmajl6XXsE52YHoau9rgpPWMYtyAcuD9WmL8ekUsvLQ=.d9ddc16e-f6e8-4614-8d87-c075692ef134@github.com>

Small fix removing a hard coded Java version number causing test failures after merge with mainline.

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

Commit messages:
 - Remove hard coded Java version number.

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

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


From fparain at openjdk.org  Thu May  2 19:59:07 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 2 May 2024 19:59:07 GMT
Subject: [lworld] RFR: 8331602: [lworld] Test using
 -XX:+EnableNullableFieldFlattening should not be run in product mode
Message-ID: <NfPl6Tu3p4XgtQxPaYv2-_7uLuUuuaZNi9sWBHUG0H8=.949d1a2b-57c3-480d-bb26-6bab2ebee4b7@github.com>

NullableFlatFieldTest and UnsafeTest needs EnableNullableFieldFlattening, which is a develop flag, not available on product build. EnableNullableFieldFlattening is a temporary flag that will be removed once all the VM supports nullable flat fields. For now, those two tests will only be run with debug builds.

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

Commit messages:
 - Restrict tests to debug mode

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

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


From fparain at openjdk.org  Thu May  2 20:09:13 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 2 May 2024 20:09:13 GMT
Subject: [lworld] Integrated: 8331602: [lworld] Test using
 -XX:+EnableNullableFieldFlattening should not be run in product mode
In-Reply-To: <NfPl6Tu3p4XgtQxPaYv2-_7uLuUuuaZNi9sWBHUG0H8=.949d1a2b-57c3-480d-bb26-6bab2ebee4b7@github.com>
References: <NfPl6Tu3p4XgtQxPaYv2-_7uLuUuuaZNi9sWBHUG0H8=.949d1a2b-57c3-480d-bb26-6bab2ebee4b7@github.com>
Message-ID: <VpaReFQsoIxDlqmerGyqBCWKY1-x8pJzFwlEzjyDKqc=.2b2eabec-88a8-4154-9211-2658ceb2083a@github.com>

On Thu, 2 May 2024 19:55:40 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> NullableFlatFieldTest and UnsafeTest needs EnableNullableFieldFlattening, which is a develop flag, not available on product build. EnableNullableFieldFlattening is a temporary flag that will be removed once all the VM supports nullable flat fields. For now, those two tests will only be run with debug builds.

This pull request has now been integrated.

Changeset: e125a279
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e125a279a09a0afb4ca39d14f4dd16b3638f843b
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8331602: [lworld] Test using -XX:+EnableNullableFieldFlattening should not be run in product mode

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

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


From mchung at openjdk.org  Thu May  2 20:17:07 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 2 May 2024 20:17:07 GMT
Subject: [lworld] Integrated: 8331521: [lworld] dynamic proxy class does not
 strictly need preload attributes
In-Reply-To: <0qEEBtMeGaczVqB_gJenBaz3bV2cmxT_BY0gUuPJUDk=.4cce657b-5d11-43d0-802d-5cf6926e23ed@github.com>
References: <0qEEBtMeGaczVqB_gJenBaz3bV2cmxT_BY0gUuPJUDk=.4cce657b-5d11-43d0-802d-5cf6926e23ed@github.com>
Message-ID: <t64iUdVlRfeL8nwT3usQzqyDax4KO96QEi4eUbk4z7s=.fab5399c-717b-457d-93ad-0f8fb448841c@github.com>

On Wed, 1 May 2024 22:29:37 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This PR takes out the generation of preload attributes in dynamic proxy.
> 
> If a proxy interface references any value classes, the value classes are listed in the preload attribute of the interface class.  The classes that are referenced by the proxy interface have already been loaded before the proxy class.  Hence the proxy class can be generated with no preload attributes as it essentially has no effect.

This pull request has now been integrated.

Changeset: 2a9782b7
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2a9782b73fd46e4f038872b03e2da806d7c8c7c4
Stats:     62 lines in 1 file changed: 6 ins; 54 del; 2 mod

8331521: [lworld] dynamic proxy class does not strictly need preload attributes

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

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


From fparain at openjdk.org  Thu May  2 23:00:13 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 2 May 2024 23:00:13 GMT
Subject: [lworld] RFR: 8331583: [lworld]
 runtime/valhalla/inlinetypes/field_layout/FieldAlignmentTest.java fails with
 compilation error
In-Reply-To: <kmajl6XXsE52YHoau9rgpPWMYtyAcuD9WmL8ekUsvLQ=.d9ddc16e-f6e8-4614-8d87-c075692ef134@github.com>
References: <kmajl6XXsE52YHoau9rgpPWMYtyAcuD9WmL8ekUsvLQ=.d9ddc16e-f6e8-4614-8d87-c075692ef134@github.com>
Message-ID: <C6KGPFOHAWyDr-mFxvOI-A0AYcEzJLyjoBQW5tOSoHk=.6625deac-7dde-481d-adc9-4114967a3b35@github.com>

On Thu, 2 May 2024 16:03:48 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix removing a hard coded Java version number causing test failures after merge with mainline.

Tested with tier1, no failure reported.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1094#issuecomment-2091878629


From fparain at openjdk.org  Thu May  2 23:00:13 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 2 May 2024 23:00:13 GMT
Subject: [lworld] Integrated: 8331583: [lworld]
 runtime/valhalla/inlinetypes/field_layout/FieldAlignmentTest.java fails with
 compilation error
In-Reply-To: <kmajl6XXsE52YHoau9rgpPWMYtyAcuD9WmL8ekUsvLQ=.d9ddc16e-f6e8-4614-8d87-c075692ef134@github.com>
References: <kmajl6XXsE52YHoau9rgpPWMYtyAcuD9WmL8ekUsvLQ=.d9ddc16e-f6e8-4614-8d87-c075692ef134@github.com>
Message-ID: <xR1_N80J8Qr862GwftG_jrLMxbEbugC-shCn6RsUflg=.ce5b3737-3b3e-4829-bd8e-2674e120d529@github.com>

On Thu, 2 May 2024 16:03:48 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix removing a hard coded Java version number causing test failures after merge with mainline.

This pull request has now been integrated.

Changeset: 9b8e936d
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9b8e936df21ebad25ec04afc9fa74ad3e29f42cc
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8331583: [lworld] runtime/valhalla/inlinetypes/field_layout/FieldAlignmentTest.java fails with compilation error

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

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


From fparain at openjdk.org  Mon May  6 19:53:22 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 6 May 2024 19:53:22 GMT
Subject: [lworld] RFR: 8331587: [lworld]
 runtime/valhalla/inlinetypes/field_layout/NullMarkersTest.java fails with
 java.lang.RuntimeException: assertEquals: expected 4 to equal 8
Message-ID: <wdhCBcRwFuolz6DKXa04l7eq6_6-cwfWuzRdjaidMdA=.248d697d-42b6-4aea-b53a-33c8bad33e49@github.com>

Changes in the format of field layout dump to include the size of oops. Adjustments in the FieldLayoutAnalyzer to rely on these new entry rather than an argument passed by the caller.

Test with Mach5 tiers 1-3

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

Commit messages:
 - Makes FieldAnalyzer robust against unexpected oop size

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

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


From fparain at openjdk.org  Mon May  6 21:25:59 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 6 May 2024 21:25:59 GMT
Subject: [lworld] Integrated: 8331587: [lworld]
 runtime/valhalla/inlinetypes/field_layout/NullMarkersTest.java fails with
 java.lang.RuntimeException: assertEquals: expected 4 to equal 8
In-Reply-To: <wdhCBcRwFuolz6DKXa04l7eq6_6-cwfWuzRdjaidMdA=.248d697d-42b6-4aea-b53a-33c8bad33e49@github.com>
References: <wdhCBcRwFuolz6DKXa04l7eq6_6-cwfWuzRdjaidMdA=.248d697d-42b6-4aea-b53a-33c8bad33e49@github.com>
Message-ID: <qxbRVt250mPwM44j4fLeON-ozyykpcom2fivx0sdAnI=.c9484532-3a27-4374-a5fc-03c34132f56d@github.com>

On Mon, 6 May 2024 19:48:19 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Changes in the format of field layout dump to include the size of oops. Adjustments in the FieldLayoutAnalyzer to rely on these new entry rather than an argument passed by the caller.
> 
> Test with Mach5 tiers 1-3

This pull request has now been integrated.

Changeset: 3b89acb1
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3b89acb102ddb7b4f318edab5c1a6169b28757c0
Stats:     36 lines in 4 files changed: 13 ins; 9 del; 14 mod

8331587: [lworld] runtime/valhalla/inlinetypes/field_layout/NullMarkersTest.java fails with java.lang.RuntimeException: assertEquals: expected 4 to equal 8

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

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


From bkilambi at openjdk.org  Tue May  7 08:40:28 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 7 May 2024 08:40:28 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16 add
 operation
Message-ID: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>

This commit [1] adds initial support for FP16 operations and adds backend support for FP16 add operation for X86. This task adds backend support for scalar and vector FP16 add operation on aarch64.

[1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad

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

Commit messages:
 - 8330021: AArch64: Add backend support for FP16 add operation

Changes: https://git.openjdk.org/valhalla/pull/1096/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1096&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330021
  Stats: 968 lines in 19 files changed: 271 ins; 4 del; 693 mod
  Patch: https://git.openjdk.org/valhalla/pull/1096.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1096/head:pull/1096

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


From dsimms at openjdk.org  Tue May  7 09:45:23 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 7 May 2024 09:45:23 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <P5y8PzZBxKAxZAEwsXZYND4Hlpz8vD6NFgK0HmA8_Nk=.158f1fd4-c042-4667-904c-e8fdd8f105ce@github.com>

Merge jdk-23+9

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

Commit messages:
 - Fixed triggered missing lock assertion from 8306767
 - Merge branch 'lworld' into lworld_merge_jdk_23_7
 - Logical merge compilation errors
 - Merge tag 'jdk-23+9' into lworld_merge_jdk_23_7
 - 8325304: Several classes in java.util.jar and java.util.zip don't specify the behaviour for null arguments
 - 8325367: Rename nsk_list.h
 - 8323681: SA PointerFinder code should support G1
 - 8325189: Enable this-escape javac warning in java.base
 - 8325302: Files.move(REPLACE_EXISTING) throws NoSuchFileException on deleted target
 - 8325268: Add policy statement to langtools makefiles concerning warnings
 - ... and 231 more: https://git.openjdk.org/valhalla/compare/3b89acb1...bb9f5004

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

Changes: https://git.openjdk.org/valhalla/pull/1098/files
  Stats: 35307 lines in 1861 files changed: 17245 ins; 5221 del; 12841 mod
  Patch: https://git.openjdk.org/valhalla/pull/1098.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1098/head:pull/1098

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


From bkilambi at openjdk.org  Tue May  7 10:27:06 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 7 May 2024 10:27:06 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16
 add operation
In-Reply-To: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
References: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
Message-ID: <ZgC2sjOvDewurdnYtJNxAp2hnG4UhJS52iORjYrz0Mw=.11dc4f07-3c26-442b-80ba-c22c4c44b884@github.com>

On Mon, 6 May 2024 18:28:31 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This commit [1] adds initial support for FP16 operations and adds backend support for FP16 add operation for X86. This task adds backend support for scalar and vector FP16 add operation on aarch64.
> 
> [1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad

test/hotspot/gtest/aarch64/aarch64-asmtest.py line 19:

> 17:         0x7e0, 0xfc0, 0x1f80, 0x3ff0, 0x7e00, 0x7e00,
> 18:         0x8000, 0x81ff, 0xc1ff, 0xc003, 0xc7ff, 0xdfff,
> 19:         0xe03f, 0xe1ff, 0xf801, 0xfc00, 0xfc07, 0xff03,

Removed "0xe10f" from the list as it is not a valid 16-imemdiate. 
Source : https://gist.github.com/dinfuehr/51a01ac58c0b23e4de9aac313ed6a06a

test/hotspot/jtreg/compiler/intrinsics/float16/TestFP16ScalarAdd.java line 99:

> 97:     @IR(applyIfCPUFeature = {"avx512_fp16" , "true"}, counts = {IRNode.CONVF2HFANDS2HF, " >= 1"})
> 98:     @IR(applyIfCPUFeatureAnd = {"fphp", "true", "asimdhp", "true"}, counts = {IRNode.CONVF2HFANDS2HF, " >= 1"})
> 99:     public void test3() {

"test3" and "test4" are not exactly related to FP16 add operation and I can move them to another file if needed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1096#discussion_r1592194879
PR Review Comment: https://git.openjdk.org/valhalla/pull/1096#discussion_r1592188182


From dsimms at openjdk.org  Wed May  8 08:33:22 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 8 May 2024 08:33:22 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <P5y8PzZBxKAxZAEwsXZYND4Hlpz8vD6NFgK0HmA8_Nk=.158f1fd4-c042-4667-904c-e8fdd8f105ce@github.com>
References: <P5y8PzZBxKAxZAEwsXZYND4Hlpz8vD6NFgK0HmA8_Nk=.158f1fd4-c042-4667-904c-e8fdd8f105ce@github.com>
Message-ID: <OQ3hWP8SPYWzu9Cbdqxazy1fl7xYregrua6nswWPBV0=.c54dbec2-2324-4ca6-83b6-6e1a11b36cb3@github.com>

On Tue, 7 May 2024 09:38:30 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+9

This pull request has now been integrated.

Changeset: 2d516373
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2d5163731ae90d4bc1fb7be6b7e29f4a4d47734d
Stats:     35307 lines in 1861 files changed: 17245 ins; 5221 del; 12841 mod

Merge jdk

Merge jdk-23+9

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

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


From chagedorn at openjdk.org  Wed May  8 09:02:44 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 8 May 2024 09:02:44 GMT
Subject: [lworld] RFR: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized
Message-ID: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>

The unique concrete subclass optimization replaces an abstract class with a unique concrete sub class (if there is one). In the test case, `abstractValueClassSingleSubclass` is a field with the abstract value class type `AbstractValueClassSingleSubclass` which has a unique (loaded) concrete value sub class `UniqueValueSubClass`.

In `do_get_xxx()`, we get the declared `ciType` of the field:
https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L143

which is `AbstractValueClassSingleSubclass` (i.e. no unique concrete sub class optimization applied). But for the type, we call `make_from_klass()` which does apply the unique concrete sub class optimization:
https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L173
https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/type.cpp#L3842-L3859

As a result, we create a load that has type `UniqueValueSubClass` while `field_klass` is still abstract. We do not create an `InlineTypeNode` because `is_inlinetype()` returns false for abstract classes:
https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L191-L193

Later, we assert that we've missed a scalarization opportunity based on the concrete inline type load.

The fix is straight forward to improve the fetched declared `ciType` in `do_get_xxx()` by applying the unique concrete sub class optimization to match the improved type. We only need to apply it for abstract inline type classes. In other cases, we do not the improved field type. I've added a method to check this accordingly.

Thanks,
Christian

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

Commit messages:
 - 8330691: [lworld] C2: assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized

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

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


From dsimms at openjdk.org  Wed May  8 09:04:18 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 8 May 2024 09:04:18 GMT
Subject: [lworld] Integrated: Adjust testing
Message-ID: <dPK24wDce2_Tm-15_Bd0J0L2Cja7TF4FUDupCzdm8LI=.cca965e9-2444-4fc7-81ea-dee9290deaac@github.com>

Added new test failures to problem lists

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

Commit messages:
 - Adjust testing

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

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


From dsimms at openjdk.org  Wed May  8 09:04:18 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 8 May 2024 09:04:18 GMT
Subject: [lworld] Integrated: Adjust testing
In-Reply-To: <dPK24wDce2_Tm-15_Bd0J0L2Cja7TF4FUDupCzdm8LI=.cca965e9-2444-4fc7-81ea-dee9290deaac@github.com>
References: <dPK24wDce2_Tm-15_Bd0J0L2Cja7TF4FUDupCzdm8LI=.cca965e9-2444-4fc7-81ea-dee9290deaac@github.com>
Message-ID: <oOUDQ3sdIZFTyzRg1fmvB2ZivvkmuISxuFVgYlE38W4=.16926ce0-e0ab-4a9f-ac53-307cf77e210b@github.com>

On Wed, 8 May 2024 08:57:36 GMT, David Simms <dsimms at openjdk.org> wrote:

> Added new test failures to problem lists

This pull request has now been integrated.

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

Adjust testing

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

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


From thartmann at openjdk.org  Wed May  8 09:10:44 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 8 May 2024 09:10:44 GMT
Subject: [lworld] Integrated: 8331538: [lworld] Fix array handling code in C2
 for JEP 401
Message-ID: <f0GD6y8V3LoagmBV_xOPOUaOqNMG-LDShpM-veRXn4U=.6d604bfa-9158-400e-89cd-be1ffd096290@github.com>

This PR contains several fixes to array handling code in C2 to align with the JEP 401 design.

I also fixed an issue with replay compilation where `ArrayStoreData` was not correctly dumped to the file because it's a subtype of `ReceiverTypeData` which was checked first in `ciMethodData::dump_replay_data`.

Thanks,
Tobias

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

Commit messages:
 - Added a TODO
 - More fixes
 - Problem listed test triggering 8331551
 - Merge branch 'lworld' into JDK-8331538
 - Removed ToDos
 - Move folding code to Ideal()
 - Removed UseArrayMarkWordCheck
 - First prototype

Changes: https://git.openjdk.org/valhalla/pull/1101/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331538
  Stats: 457 lines in 37 files changed: 202 ins; 146 del; 109 mod
  Patch: https://git.openjdk.org/valhalla/pull/1101.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1101/head:pull/1101

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


From thartmann at openjdk.org  Wed May  8 09:10:44 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 8 May 2024 09:10:44 GMT
Subject: [lworld] Integrated: 8331538: [lworld] Fix array handling code in C2
 for JEP 401
In-Reply-To: <f0GD6y8V3LoagmBV_xOPOUaOqNMG-LDShpM-veRXn4U=.6d604bfa-9158-400e-89cd-be1ffd096290@github.com>
References: <f0GD6y8V3LoagmBV_xOPOUaOqNMG-LDShpM-veRXn4U=.6d604bfa-9158-400e-89cd-be1ffd096290@github.com>
Message-ID: <RDI935xt1eoWCvEuJ5IHjEoOVJoZ4UedXPDNU-bEENs=.32ba0579-a8d8-4eca-b138-27f59a5c63e5@github.com>

On Wed, 8 May 2024 09:02:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This PR contains several fixes to array handling code in C2 to align with the JEP 401 design.
> 
> I also fixed an issue with replay compilation where `ArrayStoreData` was not correctly dumped to the file because it's a subtype of `ReceiverTypeData` which was checked first in `ciMethodData::dump_replay_data`.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: eab1e932
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/eab1e932dad26ca2dc30d3440436950ca9fd3fe9
Stats:     457 lines in 37 files changed: 202 ins; 146 del; 109 mod

8331538: [lworld] Fix array handling code in C2 for JEP 401

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

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


From chagedorn at openjdk.org  Wed May  8 09:21:30 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 8 May 2024 09:21:30 GMT
Subject: [lworld] RFR: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized [v2]
In-Reply-To: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
References: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
Message-ID: <jAbirJCxiHOZXZ0FD2zVjwchH2VIWbT385yll377_DU=.18b2dd8b-ff3d-4b88-9d0f-5b20c79e71bf@github.com>

> The unique concrete subclass optimization replaces an abstract class with a unique concrete sub class (if there is one). In the test case, `abstractValueClassSingleSubclass` is a field with the abstract value class type `AbstractValueClassSingleSubclass` which has a unique (loaded) concrete value sub class `UniqueValueSubClass`.
> 
> In `do_get_xxx()`, we get the declared `ciType` of the field:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L143
> 
> which is `AbstractValueClassSingleSubclass` (i.e. no unique concrete sub class optimization applied). But for the type, we call `make_from_klass()` which does apply the unique concrete sub class optimization:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L173
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/type.cpp#L3842-L3859
> 
> As a result, we create a load that has type `UniqueValueSubClass` while `field_klass` is still abstract. We do not create an `InlineTypeNode` because `is_inlinetype()` returns false for abstract classes:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L191-L193
> 
> Later, we assert that we've missed a scalarization opportunity based on the concrete inline type load.
> 
> The fix is straight forward to improve the fetched declared `ciType` in `do_get_xxx()` by applying the unique concrete sub class optimization to match the improved type. We only need to apply it for abstract inline type classes. In other cases, we do not the improved field type. I've added a method to check this accordingly.
> 
> Thanks,
> Christian

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

 - Merge branch 'lworld' into JDK-8330691
 - 8330691: [lworld] C2: assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1099/files
  - new: https://git.openjdk.org/valhalla/pull/1099/files/c0e9eae6..9fa77a26

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

  Stats: 35810 lines in 1887 files changed: 17470 ins; 5376 del; 12964 mod
  Patch: https://git.openjdk.org/valhalla/pull/1099.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1099/head:pull/1099

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


From thartmann at openjdk.org  Wed May  8 10:21:23 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 8 May 2024 10:21:23 GMT
Subject: [lworld] Integrated: [lworld] Re-adjust problem list
Message-ID: <0xeIV90ARfo239O5uOEJhHnNYG7Z86iEwxLMqbzbyuE=.15981b91-2eb2-4363-b8de-c66bd6457b86@github.com>

Undoing the problem listing because:
- `TestZGCUnrolling.java` was already disabled with the changes for [JDK-8331538](https://bugs.openjdk.org/browse/JDK-8331538)
- `TestBasicFunctionality.java` is a large and important test. Only the failing unit test should be disabled. Also, the linked bug is wrong, it should be [JDK-8315003](https://bugs.openjdk.org/browse/JDK-8315003).
- The `TestValueClasses.java` failure seems to be highly intermittent and we should not disable the test completely. I'll investigate with [JDK-8331909](https://bugs.openjdk.org/browse/JDK-8331909) and potentially problem list the unit test.

Thanks,
Tobias

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

Commit messages:
 - [lworld] Re-adjusted problem list

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

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


From thartmann at openjdk.org  Wed May  8 10:21:23 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 8 May 2024 10:21:23 GMT
Subject: [lworld] Integrated: [lworld] Re-adjust problem list
In-Reply-To: <0xeIV90ARfo239O5uOEJhHnNYG7Z86iEwxLMqbzbyuE=.15981b91-2eb2-4363-b8de-c66bd6457b86@github.com>
References: <0xeIV90ARfo239O5uOEJhHnNYG7Z86iEwxLMqbzbyuE=.15981b91-2eb2-4363-b8de-c66bd6457b86@github.com>
Message-ID: <GHoWy2CgCv7FREKG5umVhYey6Cz2h9vZs7xQ3SfeHZc=.5c355eac-264f-441b-8369-fa8d16f8e03b@github.com>

On Wed, 8 May 2024 10:15:06 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Undoing the problem listing because:
> - `TestZGCUnrolling.java` was already disabled with the changes for [JDK-8331538](https://bugs.openjdk.org/browse/JDK-8331538)
> - `TestBasicFunctionality.java` is a large and important test. Only the failing unit test should be disabled. Also, the linked bug is wrong, it should be [JDK-8315003](https://bugs.openjdk.org/browse/JDK-8315003).
> - The `TestValueClasses.java` failure seems to be highly intermittent and we should not disable the test completely. I'll investigate with [JDK-8331909](https://bugs.openjdk.org/browse/JDK-8331909) and potentially problem list the unit test.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

[lworld] Re-adjust problem list

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

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


From chagedorn at openjdk.org  Wed May  8 10:43:30 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 8 May 2024 10:43:30 GMT
Subject: [lworld] RFR: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized [v3]
In-Reply-To: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
References: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
Message-ID: <D5xhXs0SRzkH1QljBHI_bI4UMwUR6x573fxSrzcZsIU=.23093089-11cb-4545-9dcf-3f05833c7368@github.com>

> The unique concrete subclass optimization replaces an abstract class with a unique concrete sub class (if there is one). In the test case, `abstractValueClassSingleSubclass` is a field with the abstract value class type `AbstractValueClassSingleSubclass` which has a unique (loaded) concrete value sub class `UniqueValueSubClass`.
> 
> In `do_get_xxx()`, we get the declared `ciType` of the field:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L143
> 
> which is `AbstractValueClassSingleSubclass` (i.e. no unique concrete sub class optimization applied). But for the type, we call `make_from_klass()` which does apply the unique concrete sub class optimization:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L173
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/type.cpp#L3842-L3859
> 
> As a result, we create a load that has type `UniqueValueSubClass` while `field_klass` is still abstract. We do not create an `InlineTypeNode` because `is_inlinetype()` returns false for abstract classes:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L191-L193
> 
> Later, we assert that we've missed a scalarization opportunity based on the concrete inline type load.
> 
> The fix is straight forward to improve the fetched declared `ciType` in `do_get_xxx()` by applying the unique concrete sub class optimization to match the improved type. We only need to apply it for abstract inline type classes. In other cases, we do not the improved field type. I've added a method to check this accordingly.
> 
> Thanks,
> Christian

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

  Fix comment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1099/files
  - new: https://git.openjdk.org/valhalla/pull/1099/files/9fa77a26..381e208e

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

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

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


From thartmann at openjdk.org  Wed May  8 10:43:33 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 8 May 2024 10:43:33 GMT
Subject: [lworld] RFR: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized [v2]
In-Reply-To: <jAbirJCxiHOZXZ0FD2zVjwchH2VIWbT385yll377_DU=.18b2dd8b-ff3d-4b88-9d0f-5b20c79e71bf@github.com>
References: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
 <jAbirJCxiHOZXZ0FD2zVjwchH2VIWbT385yll377_DU=.18b2dd8b-ff3d-4b88-9d0f-5b20c79e71bf@github.com>
Message-ID: <kxVV_0mwgkzM3ZJFMYQygHgkI0qjWg9Eet-MLG8WMNg=.e90d30af-2c01-4819-9ba5-671880abe5c3@github.com>

On Wed, 8 May 2024 09:21:30 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The unique concrete subclass optimization replaces an abstract class with a unique concrete sub class (if there is one). In the test case, `abstractValueClassSingleSubclass` is a field with the abstract value class type `AbstractValueClassSingleSubclass` which has a unique (loaded) concrete value sub class `UniqueValueSubClass`.
>> 
>> In `do_get_xxx()`, we get the declared `ciType` of the field:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L143
>> 
>> which is `AbstractValueClassSingleSubclass` (i.e. no unique concrete sub class optimization applied). But for the type, we call `make_from_klass()` which does apply the unique concrete sub class optimization:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L173
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/type.cpp#L3842-L3859
>> 
>> As a result, we create a load that has type `UniqueValueSubClass` while `field_klass` is still abstract. We do not create an `InlineTypeNode` because `is_inlinetype()` returns false for abstract classes:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L191-L193
>> 
>> Later, we assert that we've missed a scalarization opportunity based on the concrete inline type load.
>> 
>> The fix is straight forward to improve the fetched declared `ciType` in `do_get_xxx()` by applying the unique concrete sub class optimization to match the improved type. We only need to apply it for abstract inline type classes. In other cases, we do not the improved field type. I've added a method to check this accordingly.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8330691
>  - 8330691: [lworld] C2: assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized

Looks good, thanks for fixing Christian!

Please re-run testing now that the merge and the fix for [JDK-8331538](https://bugs.openjdk.org/browse/JDK-8331538) is in.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 4387:

> 4385:     @Test
> 4386:     public void testUniqueConcreteValueSubKlass(boolean flag) {
> 4387:         // C2 should recognize that even though we do not know whether the underlying inline type of the abstract field

Comment could be made more clear, as we discussed offline.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1099#pullrequestreview-2045289286
PR Review Comment: https://git.openjdk.org/valhalla/pull/1099#discussion_r1593814798


From chagedorn at openjdk.org  Wed May  8 10:43:33 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 8 May 2024 10:43:33 GMT
Subject: [lworld] RFR: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized [v2]
In-Reply-To: <jAbirJCxiHOZXZ0FD2zVjwchH2VIWbT385yll377_DU=.18b2dd8b-ff3d-4b88-9d0f-5b20c79e71bf@github.com>
References: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
 <jAbirJCxiHOZXZ0FD2zVjwchH2VIWbT385yll377_DU=.18b2dd8b-ff3d-4b88-9d0f-5b20c79e71bf@github.com>
Message-ID: <NTUr8o5r9vpsqgE0X4krs1EMhz9jrcu36BXzhOeo7io=.bf237a55-1794-4aaf-9e6c-f4f7a5c9e811@github.com>

On Wed, 8 May 2024 09:21:30 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The unique concrete subclass optimization replaces an abstract class with a unique concrete sub class (if there is one). In the test case, `abstractValueClassSingleSubclass` is a field with the abstract value class type `AbstractValueClassSingleSubclass` which has a unique (loaded) concrete value sub class `UniqueValueSubClass`.
>> 
>> In `do_get_xxx()`, we get the declared `ciType` of the field:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L143
>> 
>> which is `AbstractValueClassSingleSubclass` (i.e. no unique concrete sub class optimization applied). But for the type, we call `make_from_klass()` which does apply the unique concrete sub class optimization:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L173
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/type.cpp#L3842-L3859
>> 
>> As a result, we create a load that has type `UniqueValueSubClass` while `field_klass` is still abstract. We do not create an `InlineTypeNode` because `is_inlinetype()` returns false for abstract classes:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L191-L193
>> 
>> Later, we assert that we've missed a scalarization opportunity based on the concrete inline type load.
>> 
>> The fix is straight forward to improve the fetched declared `ciType` in `do_get_xxx()` by applying the unique concrete sub class optimization to match the improved type. We only need to apply it for abstract inline type classes. In other cases, we do not the improved field type. I've added a method to check this accordingly.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8330691
>  - 8330691: [lworld] C2: assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized

Thanks Tobias for your review! I've merged in your changes and I started testing again.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1099#issuecomment-2100285492


From chagedorn at openjdk.org  Wed May  8 10:43:33 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 8 May 2024 10:43:33 GMT
Subject: [lworld] RFR: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized [v2]
In-Reply-To: <kxVV_0mwgkzM3ZJFMYQygHgkI0qjWg9Eet-MLG8WMNg=.e90d30af-2c01-4819-9ba5-671880abe5c3@github.com>
References: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
 <jAbirJCxiHOZXZ0FD2zVjwchH2VIWbT385yll377_DU=.18b2dd8b-ff3d-4b88-9d0f-5b20c79e71bf@github.com>
 <kxVV_0mwgkzM3ZJFMYQygHgkI0qjWg9Eet-MLG8WMNg=.e90d30af-2c01-4819-9ba5-671880abe5c3@github.com>
Message-ID: <OnrBYlppoKKzPqumhmFrA17sWoi-WxnrKHditbofk3Q=.8dfa1d10-827c-48a3-982f-54b5ad18b321@github.com>

On Wed, 8 May 2024 10:36:52 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' into JDK-8330691
>>  - 8330691: [lworld] C2: assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 4387:
> 
>> 4385:     @Test
>> 4386:     public void testUniqueConcreteValueSubKlass(boolean flag) {
>> 4387:         // C2 should recognize that even though we do not know whether the underlying inline type of the abstract field
> 
> Comment could be made more clear, as we discussed offline.

Thanks for the hint, pushed an update.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1099#discussion_r1593818669


From thartmann at openjdk.org  Wed May  8 14:09:01 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 8 May 2024 14:09:01 GMT
Subject: [lworld] RFR: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized [v3]
In-Reply-To: <D5xhXs0SRzkH1QljBHI_bI4UMwUR6x573fxSrzcZsIU=.23093089-11cb-4545-9dcf-3f05833c7368@github.com>
References: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
 <D5xhXs0SRzkH1QljBHI_bI4UMwUR6x573fxSrzcZsIU=.23093089-11cb-4545-9dcf-3f05833c7368@github.com>
Message-ID: <g6IA_Bf2_30N-rNHfpdpzW-8ic5ww7slSzf66Wryh1s=.afa12670-183b-4a87-b9bd-782398af1508@github.com>

On Wed, 8 May 2024 10:43:30 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The unique concrete subclass optimization replaces an abstract class with a unique concrete sub class (if there is one). In the test case, `abstractValueClassSingleSubclass` is a field with the abstract value class type `AbstractValueClassSingleSubclass` which has a unique (loaded) concrete value sub class `UniqueValueSubClass`.
>> 
>> In `do_get_xxx()`, we get the declared `ciType` of the field:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L143
>> 
>> which is `AbstractValueClassSingleSubclass` (i.e. no unique concrete sub class optimization applied). But for the type, we call `make_from_klass()` which does apply the unique concrete sub class optimization:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L173
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/type.cpp#L3842-L3859
>> 
>> As a result, we create a load that has type `UniqueValueSubClass` while `field_klass` is still abstract. We do not create an `InlineTypeNode` because `is_inlinetype()` returns false for abstract classes:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L191-L193
>> 
>> Later, we assert that we've missed a scalarization opportunity based on the concrete inline type load.
>> 
>> The fix is straight forward to improve the fetched declared `ciType` in `do_get_xxx()` by applying the unique concrete sub class optimization to match the improved type. We only need to apply it for abstract inline type classes. In other cases, we do not the improved field type. I've added a method to check this accordingly.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

Thanks, still good!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1099#issuecomment-2100671497


From vromero at openjdk.org  Thu May  9 00:45:22 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 May 2024 00:45:22 GMT
Subject: [lworld] RFR: 8331606: [lworld] javac should consider some library
 classes as value classes
Message-ID: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>

For some library classes two compiled versions are produced, one is the legacy class file and the other one is a class file representing a value class. The version representing a value class is stored in a separate jar. During compilation of classes using one of these library classes javac loads the vanilla version. But if preview features are enabled, javac should act as if the loaded class was the one representing the value class. So basically javac's class loader needs to massage the flags in the loaded class so that the rest of the compiler pipeline can handle it as a value class. This PR is proposing an annotation to mark these classes so that they can be identified by javac without having to keep an internal list of classes that will need to be maintained,

TIA

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

Commit messages:
 - adding the MigratedValueClass annotation
 - 8331606: [lworld] javac should consider some library classes as value classes

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

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


From vromero at openjdk.org  Thu May  9 02:15:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 May 2024 02:15:38 GMT
Subject: [lworld] RFR: 8331606: [lworld] javac should consider some library
 classes as value classes [v2]
In-Reply-To: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
References: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
Message-ID: <H0I8uCYOiRpCmKG7M3963t1lRBF1KsSMifDOeDHhQIQ=.e8e13528-efeb-45ba-bf28-44de1db9fcc6@github.com>

> For some library classes two compiled versions are produced, one is the legacy class file and the other one is a class file representing a value class. The version representing a value class is stored in a separate jar. During compilation of classes using one of these library classes javac loads the vanilla version. But if preview features are enabled, javac should act as if the loaded class was the one representing the value class. So basically javac's class loader needs to massage the flags in the loaded class so that the rest of the compiler pipeline can handle it as a value class. This PR is proposing an annotation to mark these classes so that they can be identified by javac without having to keep an internal list of classes that will need to be maintained,
> 
> TIA

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

  minor refactorings

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1104/files
  - new: https://git.openjdk.org/valhalla/pull/1104/files/2212ef48..6a32bf99

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

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

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


From bkilambi at openjdk.org  Thu May  9 08:14:05 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 9 May 2024 08:14:05 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16
 add operation
In-Reply-To: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
References: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
Message-ID: <Uxk-6uH0sIs2rOVBRG2Gvm68dyc_NZxcDuj6Q7CT-ck=.2342937c-c98f-4f06-997a-b604fe84cd43@github.com>

On Mon, 6 May 2024 18:28:31 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This commit [1] adds initial support for FP16 operations and adds backend support for FP16 add operation for X86. This task adds backend support for scalar and vector FP16 add operation on aarch64.
> 
> [1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad

Can I please ask for some reviews for this PR? Thank you in advance!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1096#issuecomment-2102172849


From mcimadamore at openjdk.org  Thu May  9 10:23:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 May 2024 10:23:06 GMT
Subject: [lworld] RFR: 8331606: [lworld] javac should consider some library
 classes as value classes [v2]
In-Reply-To: <H0I8uCYOiRpCmKG7M3963t1lRBF1KsSMifDOeDHhQIQ=.e8e13528-efeb-45ba-bf28-44de1db9fcc6@github.com>
References: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
 <H0I8uCYOiRpCmKG7M3963t1lRBF1KsSMifDOeDHhQIQ=.e8e13528-efeb-45ba-bf28-44de1db9fcc6@github.com>
Message-ID: <91dppfKnxfOQm4AXRltemz5L6-y2l7wTYN3wfaRxQWo=.4510a5e9-9396-439f-b4ab-b9ba8df395c1@github.com>

On Thu, 9 May 2024 02:15:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> For some library classes two compiled versions are produced, one is the legacy class file and the other one is a class file representing a value class. The version representing a value class is stored in a separate jar. During compilation of classes using one of these library classes javac loads the vanilla version. But if preview features are enabled, javac should act as if the loaded class was the one representing the value class. So basically javac's class loader needs to massage the flags in the loaded class so that the rest of the compiler pipeline can handle it as a value class. This PR is proposing an annotation to mark these classes so that they can be identified by javac without having to keep an internal list of classes that will need to be maintained,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactorings

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 3180:

> 3178:         if (((flags & ACC_IDENTITY) != 0 && !isMigratedValueClass(flags)) || (majorVersion < V66.major && (flags & INTERFACE) == 0)) {
> 3179:             flags |= IDENTITY_TYPE;
> 3180:         } else if (needsValueFlag(c, flags)) {

isn't this redundant? E.g. isn't VALUE_CLASS set as soon as you see the annotation?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1104#discussion_r1595263866


From mcimadamore at openjdk.org  Thu May  9 10:27:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 May 2024 10:27:05 GMT
Subject: [lworld] RFR: 8331606: [lworld] javac should consider some library
 classes as value classes [v2]
In-Reply-To: <H0I8uCYOiRpCmKG7M3963t1lRBF1KsSMifDOeDHhQIQ=.e8e13528-efeb-45ba-bf28-44de1db9fcc6@github.com>
References: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
 <H0I8uCYOiRpCmKG7M3963t1lRBF1KsSMifDOeDHhQIQ=.e8e13528-efeb-45ba-bf28-44de1db9fcc6@github.com>
Message-ID: <z8a4p_TMBW93q2WRhpgCYvBHDATEUhC1gVMmluxb_oA=.1625d478-3b43-4393-8770-493948dc76ed@github.com>

On Thu, 9 May 2024 02:15:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> For some library classes two compiled versions are produced, one is the legacy class file and the other one is a class file representing a value class. The version representing a value class is stored in a separate jar. During compilation of classes using one of these library classes javac loads the vanilla version. But if preview features are enabled, javac should act as if the loaded class was the one representing the value class. So basically javac's class loader needs to massage the flags in the loaded class so that the rest of the compiler pipeline can handle it as a value class. This PR is proposing an annotation to mark these classes so that they can be identified by javac without having to keep an internal list of classes that will need to be maintained,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactorings

test/langtools/tools/javac/valhalla/value-objects/ValueObjectCompilationTests.java line 311:

> 309:                 }
> 310:                 """);
> 311:         assertFail("compiler.err.type.found.req",

Might be good to try the full set of options:
* --source 23, --enable-preview
* --source 23
* --release 23, --enable-preview
* --release 23

(since when release is specified, the code path is different)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1104#discussion_r1595267776


From vromero at openjdk.org  Thu May  9 14:22:12 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 May 2024 14:22:12 GMT
Subject: [lworld] RFR: 8331606: [lworld] javac should consider some library
 classes as value classes [v2]
In-Reply-To: <91dppfKnxfOQm4AXRltemz5L6-y2l7wTYN3wfaRxQWo=.4510a5e9-9396-439f-b4ab-b9ba8df395c1@github.com>
References: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
 <H0I8uCYOiRpCmKG7M3963t1lRBF1KsSMifDOeDHhQIQ=.e8e13528-efeb-45ba-bf28-44de1db9fcc6@github.com>
 <91dppfKnxfOQm4AXRltemz5L6-y2l7wTYN3wfaRxQWo=.4510a5e9-9396-439f-b4ab-b9ba8df395c1@github.com>
Message-ID: <z_QN3ndmRPUutSYS9euKL57yxIga4abBPQDGOjxmAmY=.4ac3646c-8b70-4f38-8c48-f0a191c8bb36@github.com>

On Thu, 9 May 2024 10:20:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor refactorings
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 3180:
> 
>> 3178:         if (((flags & ACC_IDENTITY) != 0 && !isMigratedValueClass(flags)) || (majorVersion < V66.major && (flags & INTERFACE) == 0)) {
>> 3179:             flags |= IDENTITY_TYPE;
>> 3180:         } else if (needsValueFlag(c, flags)) {
> 
> isn't this redundant? E.g. isn't VALUE_CLASS set as soon as you see the annotation?

no, we need this path for the cases when we load a `real` value class

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1104#discussion_r1595518340


From fparain at openjdk.org  Thu May  9 14:50:21 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 9 May 2024 14:50:21 GMT
Subject: [lworld] RFR: 8326598: [lworld] JVM must support field inheritance for
 value classes
Message-ID: <9Z6BWw82Lc4VUrHJYMGRvkMPZuNn9xR9rIiWjD2aID0=.4453932a-7a71-400e-a1b4-7bbc3f1b80c8@github.com>

Adds field inheritance for value classes.
Layouts of value classes that inherited fields are not always optimal, but fixing them would require a new placement algorithm which is beyond the scope of this CR.
The test is currently limited to the interpreted mode because of issues with CI and C2 tracked by JDK-8331964.

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

Commit messages:
 - Cleanup
 - Restrict test to interpreted mode for now
 - Merge remote-tracking branch 'upstream/lworld' into field_inheritance
 - Fix test after merge
 - Merge remote-tracking branch 'upstream/lworld' into field_inheritance
 - Field inheritance test, VM fixes, layout analyzer improvements
 - Merge remote-tracking branch 'upstream/lworld' into field_inheritance
 - Field inheritance first step

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

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


From vromero at openjdk.org  Thu May  9 15:58:23 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 May 2024 15:58:23 GMT
Subject: [lworld] RFR: 8331606: [lworld] javac should consider some library
 classes as value classes [v3]
In-Reply-To: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
References: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
Message-ID: <uV1ybEAFf10sR5OS6GKK9k-K-NvarU3WdrenC04quK8=.ceb5e12b-9ba9-4024-9747-53012fdf3df5@github.com>

> For some library classes two compiled versions are produced, one is the legacy class file and the other one is a class file representing a value class. The version representing a value class is stored in a separate jar. During compilation of classes using one of these library classes javac loads the vanilla version. But if preview features are enabled, javac should act as if the loaded class was the one representing the value class. So basically javac's class loader needs to massage the flags in the loaded class so that the rest of the compiler pipeline can handle it as a value class. This PR is proposing an annotation to mark these classes so that they can be identified by javac without having to keep an internal list of classes that will need to be maintained,
> 
> TIA

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1104/files
  - new: https://git.openjdk.org/valhalla/pull/1104/files/6a32bf99..9238bee9

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

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

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


From chagedorn at openjdk.org  Fri May 10 08:07:23 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 10 May 2024 08:07:23 GMT
Subject: [lworld] RFR: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized [v3]
In-Reply-To: <D5xhXs0SRzkH1QljBHI_bI4UMwUR6x573fxSrzcZsIU=.23093089-11cb-4545-9dcf-3f05833c7368@github.com>
References: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
 <D5xhXs0SRzkH1QljBHI_bI4UMwUR6x573fxSrzcZsIU=.23093089-11cb-4545-9dcf-3f05833c7368@github.com>
Message-ID: <n1VXVO6Hacfq5AclWkMMJFqUqFmrG5qUSL9YiJlPYuw=.18357ab3-807d-478d-b496-4c8549e718ba@github.com>

On Wed, 8 May 2024 10:43:30 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The unique concrete subclass optimization replaces an abstract class with a unique concrete sub class (if there is one). In the test case, `abstractValueClassSingleSubclass` is a field with the abstract value class type `AbstractValueClassSingleSubclass` which has a unique (loaded) concrete value sub class `UniqueValueSubClass`.
>> 
>> In `do_get_xxx()`, we get the declared `ciType` of the field:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L143
>> 
>> which is `AbstractValueClassSingleSubclass` (i.e. no unique concrete sub class optimization applied). But for the type, we call `make_from_klass()` which does apply the unique concrete sub class optimization:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L173
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/type.cpp#L3842-L3859
>> 
>> As a result, we create a load that has type `UniqueValueSubClass` while `field_klass` is still abstract. We do not create an `InlineTypeNode` because `is_inlinetype()` returns false for abstract classes:
>> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L191-L193
>> 
>> Later, we assert that we've missed a scalarization opportunity based on the concrete inline type load.
>> 
>> The fix is straight forward to improve the fetched declared `ciType` in `do_get_xxx()` by applying the unique concrete sub class optimization to match the improved type. We only need to apply it for abstract inline type classes. In other cases, we do not the improved field type. I've added a method to check this accordingly.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

Thanks Tobias for your re-review! Testing showed no new failures.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1099#issuecomment-2104139328


From mcimadamore at openjdk.org  Fri May 10 15:04:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 May 2024 15:04:18 GMT
Subject: [lworld] RFR: 8331606: [lworld] javac should consider some library
 classes as value classes [v3]
In-Reply-To: <uV1ybEAFf10sR5OS6GKK9k-K-NvarU3WdrenC04quK8=.ceb5e12b-9ba9-4024-9747-53012fdf3df5@github.com>
References: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
 <uV1ybEAFf10sR5OS6GKK9k-K-NvarU3WdrenC04quK8=.ceb5e12b-9ba9-4024-9747-53012fdf3df5@github.com>
Message-ID: <PWdqF0-jp9EPeDXyFkQwiPJlVyYhCFmrORRcekEibPQ=.1dc46bd1-9a65-4a47-9cb5-fcc39dfa12f5@github.com>

On Thu, 9 May 2024 15:58:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> For some library classes two compiled versions are produced, one is the legacy class file and the other one is a class file representing a value class. The version representing a value class is stored in a separate jar. During compilation of classes using one of these library classes javac loads the vanilla version. But if preview features are enabled, javac should act as if the loaded class was the one representing the value class. So basically javac's class loader needs to massage the flags in the loaded class so that the rest of the compiler pipeline can handle it as a value class. This PR is proposing an annotation to mark these classes so that they can be identified by javac without having to keep an internal list of classes that will need to be maintained,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Marked as reviewed by mcimadamore (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1104#pullrequestreview-2050271185


From vromero at openjdk.org  Fri May 10 16:21:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 10 May 2024 16:21:30 GMT
Subject: [lworld] RFR: 8331606: [lworld] javac should consider some library
 classes as value classes [v3]
In-Reply-To: <uV1ybEAFf10sR5OS6GKK9k-K-NvarU3WdrenC04quK8=.ceb5e12b-9ba9-4024-9747-53012fdf3df5@github.com>
References: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
 <uV1ybEAFf10sR5OS6GKK9k-K-NvarU3WdrenC04quK8=.ceb5e12b-9ba9-4024-9747-53012fdf3df5@github.com>
Message-ID: <rI_fbztxmn2uWdr2C4ZZEv36VTazCe24QomKtTEIo_M=.0e481a51-aafc-4ca9-9bf0-4bc5f9a4ed22@github.com>

On Thu, 9 May 2024 15:58:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> For some library classes two compiled versions are produced, one is the legacy class file and the other one is a class file representing a value class. The version representing a value class is stored in a separate jar. During compilation of classes using one of these library classes javac loads the vanilla version. But if preview features are enabled, javac should act as if the loaded class was the one representing the value class. So basically javac's class loader needs to massage the flags in the loaded class so that the rest of the compiler pipeline can handle it as a value class. This PR is proposing an annotation to mark these classes so that they can be identified by javac without having to keep an internal list of classes that will need to be maintained,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

thanks for the comments!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1104#issuecomment-2104881295


From vromero at openjdk.org  Fri May 10 16:24:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 10 May 2024 16:24:58 GMT
Subject: [lworld] Integrated: 8331606: [lworld] javac should consider some
 library classes as value classes
In-Reply-To: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
References: <ActgLPy6PH6XLxW9LTqkEAxmFUGYzKm5TpaLEyKvfyc=.3d2797ee-f233-4bd9-afe9-0974ac117f9d@github.com>
Message-ID: <UWd3fEuwAqvYlzSUtN5a24DRaOwv7tNTLRoHZVNtj-0=.11b039c2-a201-4e08-bce7-412c5f44bd17@github.com>

On Thu, 9 May 2024 00:41:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> For some library classes two compiled versions are produced, one is the legacy class file and the other one is a class file representing a value class. The version representing a value class is stored in a separate jar. During compilation of classes using one of these library classes javac loads the vanilla version. But if preview features are enabled, javac should act as if the loaded class was the one representing the value class. So basically javac's class loader needs to massage the flags in the loaded class so that the rest of the compiler pipeline can handle it as a value class. This PR is proposing an annotation to mark these classes so that they can be identified by javac without having to keep an internal list of classes that will need to be maintained,
> 
> TIA

This pull request has now been integrated.

Changeset: 6c6b4bd9
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6c6b4bd93b71394129f717419d6a34a05014a620
Stats:     176 lines in 19 files changed: 161 ins; 4 del; 11 mod

8331606: [lworld] javac should consider some library classes as value classes

Reviewed-by: mcimadamore

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

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


From chagedorn at openjdk.org  Sun May 12 11:00:18 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Sun, 12 May 2024 11:00:18 GMT
Subject: [lworld] Integrated: 8330691: [lworld] C2:
 assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized
In-Reply-To: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
References: <PW1TBkEXd6DNZZ6-YBd4zSPOgswEoMeIdtzBbyzGUxc=.19f09ad7-d3e8-4c88-9a54-c2edfeb8983b@github.com>
Message-ID: <sYQrNXkng7imPce1fPap55-jo07xWSz9nGiUYGSx1xs=.edb82677-9f2f-4a9d-9c7d-408ad979d937@github.com>

On Wed, 8 May 2024 08:57:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The unique concrete subclass optimization replaces an abstract class with a unique concrete sub class (if there is one). In the test case, `abstractValueClassSingleSubclass` is a field with the abstract value class type `AbstractValueClassSingleSubclass` which has a unique (loaded) concrete value sub class `UniqueValueSubClass`.
> 
> In `do_get_xxx()`, we get the declared `ciType` of the field:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L143
> 
> which is `AbstractValueClassSingleSubclass` (i.e. no unique concrete sub class optimization applied). But for the type, we call `make_from_klass()` which does apply the unique concrete sub class optimization:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L173
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/type.cpp#L3842-L3859
> 
> As a result, we create a load that has type `UniqueValueSubClass` while `field_klass` is still abstract. We do not create an `InlineTypeNode` because `is_inlinetype()` returns false for abstract classes:
> https://github.com/openjdk/valhalla/blob/3b89acb102ddb7b4f318edab5c1a6169b28757c0/src/hotspot/share/opto/parse3.cpp#L191-L193
> 
> Later, we assert that we've missed a scalarization opportunity based on the concrete inline type load.
> 
> The fix is straight forward to improve the fetched declared `ciType` in `do_get_xxx()` by applying the unique concrete sub class optimization to match the improved type. We only need to apply it for abstract inline type classes. In other cases, we do not the improved field type. I've added a method to check this accordingly.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 1d322d52
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1d322d52c4e396898dec4b837e86a7c475bbfd15
Stats:     47 lines in 5 files changed: 47 ins; 0 del; 0 mod

8330691: [lworld] C2: assert(gvn().type(n)->is_zero_type()) failed: Should have been scalarized

Reviewed-by: thartmann

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

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


From vromero at openjdk.org  Tue May 14 18:11:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 May 2024 18:11:30 GMT
Subject: [lworld] Integrated: 8332235: [lworld] introduce internal annotation
 to indicate that the ACC_STRICT flag must be set
Message-ID: <2JJmCx-gl7VPmapFo7dFtIhNW_b6U9va7AMsmI2h_uI=.c76bfff1-ae9b-4194-a4a1-764fa40413bb@github.com>

experimental annotation to indicate the compiler that the annotated field should have the ACC_STRICT flag set

TIA

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

Commit messages:
 - 8332235: [lworld] introduce internal annotation to set the ACC_STRICT field

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

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


From vromero at openjdk.org  Tue May 14 18:11:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 May 2024 18:11:31 GMT
Subject: [lworld] Integrated: 8332235: [lworld] introduce internal annotation
 to indicate that the ACC_STRICT flag must be set
In-Reply-To: <2JJmCx-gl7VPmapFo7dFtIhNW_b6U9va7AMsmI2h_uI=.c76bfff1-ae9b-4194-a4a1-764fa40413bb@github.com>
References: <2JJmCx-gl7VPmapFo7dFtIhNW_b6U9va7AMsmI2h_uI=.c76bfff1-ae9b-4194-a4a1-764fa40413bb@github.com>
Message-ID: <aHj8uMf69Paw2ef-fNtS0R7YjRu2NKXvGHJEs8O2VQw=.21f002d6-2214-493f-9370-382b536c3c72@github.com>

On Tue, 14 May 2024 18:02:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> experimental annotation to indicate the compiler that the annotated field should have the ACC_STRICT flag set
> 
> TIA

This pull request has now been integrated.

Changeset: 48e1a62c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/48e1a62cb8b5c236563f2477aaf097c1f03a14b7
Stats:     80 lines in 4 files changed: 80 ins; 0 del; 0 mod

8332235: [lworld] introduce internal annotation to indicate that the ACC_STRICT flag must be set

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

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


From rotanolexandr842 at gmail.com  Wed May 15 18:55:56 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Wed, 15 May 2024 21:55:56 +0300
Subject: Primitive-parametrized classes covariance with pre-existing
 specialized types
Message-ID: <CAL5bRt9SaDrL_RPLpDyPV9-Pq2Jb5CUySG_Fw7xg9giYs5X32Q@mail.gmail.com>

I have been reading through JEP 402: Enhanced Primitive Boxing, and
"Overriding, overloading, and type arguments inference (
https://openjdk.org/jeps/402#:~:text=Overriding%2C%20overloading%2C%20and%20type%20arguments%20inference)
section has caught my mind. I am here only speaking as a user, as I have
virtually no idea on how new primitives work in valhalla.

I am currently working on some Stream API enhancements and its internals
have become really complicated as time passed, mainly (imo), due to
primitive-specialized pipelines. JEP 402, at first glance, looked like
salvation, but the more I think about it, the more problems I see with
integrating legacy with new features. Specialized stream pipelines are
wired with specialized functional interfaces (ToXFunction,
XPredicate etc.). This (and also some specialized for primitive ops of
streams), make it impossible to harmlessly switch from XStream to Stream<X>
(where X is primitive).

While the second issue (specialized methods) could be addressed separately,
one thing that could certainly help with eventually moving on from
primitive-specialized types induced mess in current APIs is introducing
covariance between generic types and their specialized versions. It is
intuitive that ToLongFunction<T> is essentially the same as Function<T,
long>. I saw a note at the end of the JEP that Long! and long are not fully
interchangeable for some internal for JVM reasons, but the API that these
interfaces provide are exactly the same. I understand that if public APIs
that types provide are similar, that still doesn't mean their behaviour is
the same, but while it does not mean it, it could be the case (and is a
case in huge amounts of situations as when it comes to specialized types).

If such covariance would be present in language, huge amounts of code could
be just clamped as they are no longer needed. For example, whole
IntPipeline could be clamped to IntPipeline extends ReferencePipeline<int>
{ /* proprietary methods of IntStream */ } instead of virtually a second
ReferencePipeline class but specialized for int. This example is just the
thing that is closest to me right now, but I am sure anyone could think of
a way where this could be helpful for them.

I am not really sure how this is implementable in a way that does not
weaken the type system though. We can't just let users write that class A
is covariant to class B<X> or something like that for obvious reasons. The
easiest solution is to just add some compiler rules for a pre-defined
number of types in jdk, but this still will leave all library devs and just
users that had to write specialized types for some reason stranding. The
rules for this covariance could surely be a topic of discussion for more
experienced developers than me, but to have this feature would be a
dramatic step forward in Java.

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

From fparain at openjdk.org  Wed May 15 19:20:38 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 15 May 2024 19:20:38 GMT
Subject: [lworld] Integrated: 8332323: [lworld]
 runtime/valhalla/inlinetypes/ValuePreloadTest.java fails with compilation
 error
Message-ID: <m-3h_Ub18m7z9UnDvOFfqb536vlLxLCFMOHTYmf3GtA=.f8e9cca2-8de8-491f-b5c3-534a660afa6b@github.com>

Simple fix in the way the test is launched.

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

Commit messages:
 - Fix way the test is launched to get the --enable-preview flag

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

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


From fparain at openjdk.org  Wed May 15 19:20:38 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 15 May 2024 19:20:38 GMT
Subject: [lworld] Integrated: 8332323: [lworld]
 runtime/valhalla/inlinetypes/ValuePreloadTest.java fails with compilation
 error
In-Reply-To: <m-3h_Ub18m7z9UnDvOFfqb536vlLxLCFMOHTYmf3GtA=.f8e9cca2-8de8-491f-b5c3-534a660afa6b@github.com>
References: <m-3h_Ub18m7z9UnDvOFfqb536vlLxLCFMOHTYmf3GtA=.f8e9cca2-8de8-491f-b5c3-534a660afa6b@github.com>
Message-ID: <UYaARpmwHYwrLA3d-vWEnXW7TtjEMC3aZ-zfnY3JycE=.1992bca7-6bd4-47a8-aa7a-6320107c9a3d@github.com>

On Wed, 15 May 2024 19:15:07 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Simple fix in the way the test is launched.

This pull request has now been integrated.

Changeset: 7aab2230
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7aab223099e0cc220806f82951a67844b979e792
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8332323: [lworld] runtime/valhalla/inlinetypes/ValuePreloadTest.java fails with compilation error

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

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


From thartmann at openjdk.org  Wed May 15 19:33:20 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 15 May 2024 19:33:20 GMT
Subject: [lworld] RFR: 8331909: [lworld]
 compiler/valhalla/inlinetypes/TestValueClasses.java fails when random value rI
 is zero
Message-ID: <EbYRE_k-PTKJ8X9mKY8k-dG73OKt2er0EgYCysgqP24=.c6160873-1def-4f6c-a91f-2c5dc7e6abc1@github.com>

Some tests fail IR verification if the random value used to initialize fields is zero because C2 will use the default value.

Thanks,
Tobias

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

Commit messages:
 - Rephrased a comment
 - 8331909: [lworld] compiler/valhalla/inlinetypes/TestValueClasses.java fails when random value rI is zero

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

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


From bkilambi at openjdk.org  Thu May 16 09:22:26 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 16 May 2024 09:22:26 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16
 add operation
In-Reply-To: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
References: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
Message-ID: <GyT7p93Ehd_Ax3mxBiHa69fb9lXHC794WHe5LEGUnP8=.8ed4c0da-d0bb-4ca4-98b3-4e0760b0a484@github.com>

On Mon, 6 May 2024 18:28:31 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This commit [1] adds initial support for FP16 operations and adds backend support for FP16 add operation for X86. This task adds backend support for scalar and vector FP16 add operation on aarch64.
> 
> [1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad

Hi @jatin-bhateja @TobiHartmann Can I get some reviews please? Atleast for the c2 specific part. Thank you !

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

PR Comment: https://git.openjdk.org/valhalla/pull/1096#issuecomment-2114663596


From brian.goetz at oracle.com  Thu May 16 12:35:11 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 16 May 2024 12:35:11 +0000
Subject: Primitive-parametrized classes covariance with pre-existing
 specialized types
In-Reply-To: <CAL5bRt9SaDrL_RPLpDyPV9-Pq2Jb5CUySG_Fw7xg9giYs5X32Q@mail.gmail.com>
References: <CAL5bRt9SaDrL_RPLpDyPV9-Pq2Jb5CUySG_Fw7xg9giYs5X32Q@mail.gmail.com>
Message-ID: <AE2959D8-4C07-4287-8514-9E7A6AB853B6@oracle.com>

I am currently working on some Stream API enhancements and its internals have become really complicated as time passed, mainly (imo), due to primitive-specialized pipelines.

Slight correction: the internals were complicated from day 1, for this reason.  This is not something that ?happened over time?; the hand-specialization was part of its fundamental complexity.

JEP 402, at first glance, looked like salvation

You are mistaking JEP 402 for the full sweep of the Valhalla project.  Indeed, Valhalla grew out of the observations of the painfulness of hand specialization (among other challenges).  But before we can get to full generic specialization with both layout and code specialization, we have to cover some fundamentals first.  There are many steps along the way here.  We walk before we can run.

What you are asking for is to blur the distinction between nominal and structural function types, allowing Predicate<T> and Function<T, boolean> to be considered ?the same? in some way.  While this is in some sense natural, this sort of ?anything goes? flexibility that incorporates both nominal and structural subtyping creates new problems, and even if not, is unlikely to move us very far in the direction of ?IntStream is-a Stream<int>?.

Rest assured that we share your goal, but the path to get there is somewhat longer.

, but the more I think about it, the more problems I see with integrating legacy with new features. Specialized stream pipelines are wired with specialized functional interfaces (ToXFunction, XPredicate etc.). This (and also some specialized for primitive ops of streams), make it impossible to harmlessly switch from XStream to Stream<X> (where X is primitive).

While the second issue (specialized methods) could be addressed separately, one thing that could certainly help with eventually moving on from primitive-specialized types induced mess in current APIs is introducing covariance between generic types and their specialized versions. It is intuitive that ToLongFunction<T> is essentially the same as Function<T, long>. I saw a note at the end of the JEP that Long! and long are not fully interchangeable for some internal for JVM reasons, but the API that these interfaces provide are exactly the same. I understand that if public APIs that types provide are similar, that still doesn't mean their behaviour is the same, but while it does not mean it, it could be the case (and is a case in huge amounts of situations as when it comes to specialized types).

If such covariance would be present in language, huge amounts of code could be just clamped as they are no longer needed. For example, whole IntPipeline could be clamped to IntPipeline extends ReferencePipeline<int> { /* proprietary methods of IntStream */ } instead of virtually a second ReferencePipeline class but specialized for int. This example is just the thing that is closest to me right now, but I am sure anyone could think of a way where this could be helpful for them.

I am not really sure how this is implementable in a way that does not weaken the type system though. We can't just let users write that class A is covariant to class B<X> or something like that for obvious reasons. The easiest solution is to just add some compiler rules for a pre-defined number of types in jdk, but this still will leave all library devs and just users that had to write specialized types for some reason stranding. The rules for this covariance could surely be a topic of discussion for more experienced developers than me, but to have this feature would be a dramatic step forward in Java.

Regards

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

From thartmann at openjdk.org  Thu May 16 13:18:56 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 16 May 2024 13:18:56 GMT
Subject: [lworld] RFR: 8331909: [lworld]
 compiler/valhalla/inlinetypes/TestValueClasses.java fails when random value rI
 is zero [v2]
In-Reply-To: <EbYRE_k-PTKJ8X9mKY8k-dG73OKt2er0EgYCysgqP24=.c6160873-1def-4f6c-a91f-2c5dc7e6abc1@github.com>
References: <EbYRE_k-PTKJ8X9mKY8k-dG73OKt2er0EgYCysgqP24=.c6160873-1def-4f6c-a91f-2c5dc7e6abc1@github.com>
Message-ID: <eIB32N9uleGJolGCTEdk-9zMH0z4D5fPcZQI793fXYU=.360f05b8-ca1b-4a7d-b170-24960d6a6ddb@github.com>

> Some tests fail IR verification if the random value used to initialize fields is zero because C2 will use the default value.
> 
> Thanks,
> Tobias

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

  Fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1107/files
  - new: https://git.openjdk.org/valhalla/pull/1107/files/504a8533..6bd11094

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

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

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


From thartmann at openjdk.org  Thu May 16 13:18:57 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 16 May 2024 13:18:57 GMT
Subject: [lworld] Integrated: 8331909: [lworld]
 compiler/valhalla/inlinetypes/TestValueClasses.java fails when random value rI
 is zero
In-Reply-To: <EbYRE_k-PTKJ8X9mKY8k-dG73OKt2er0EgYCysgqP24=.c6160873-1def-4f6c-a91f-2c5dc7e6abc1@github.com>
References: <EbYRE_k-PTKJ8X9mKY8k-dG73OKt2er0EgYCysgqP24=.c6160873-1def-4f6c-a91f-2c5dc7e6abc1@github.com>
Message-ID: <7zUwFDh0QeE5AUSl69_Jlfz0kdykD1EwbvI4i5iSdRM=.2751d5da-6c48-4739-8249-362c6871f5c4@github.com>

On Wed, 15 May 2024 19:29:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Some tests fail IR verification if the random value used to initialize fields is zero because C2 will use the default value.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8331909: [lworld] compiler/valhalla/inlinetypes/TestValueClasses.java fails when random value rI is zero

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

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


From rotanolexandr842 at gmail.com  Thu May 16 13:23:25 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 16 May 2024 16:23:25 +0300
Subject: Primitive-parametrized classes covariance with pre-existing
 specialized types
In-Reply-To: <AE2959D8-4C07-4287-8514-9E7A6AB853B6@oracle.com>
References: <CAL5bRt9SaDrL_RPLpDyPV9-Pq2Jb5CUySG_Fw7xg9giYs5X32Q@mail.gmail.com>
 <AE2959D8-4C07-4287-8514-9E7A6AB853B6@oracle.com>
Message-ID: <CAL5bRt83q-HJ7iabAKgcm5dKJKvkJdS45h9FTQK1CVpiCP2mpA@mail.gmail.com>

>
> While this is in some sense natural, this sort of ?anything goes?
> flexibility that incorporates both nominal and structural subtyping creates
> new problems, and even if not, is unlikely to move us very far in the
> direction of ?IntStream is-a Stream<int>?.

My main concern with transitioning from  Predicate<T> to Function<T,
boolean> (or any other primitive-specialized, predicate is not the biggest
problem, obviously) is that if currently, hypothetically, we have changed
all specialized functional types to generic functional types, even if they
essentially "behave the same", would completely brake
backwards compatibility. Not even talking about binary compatibility, about
which I don't know virtually anything, I could easily think of a scenario
where this change would break source compatibility:

ToIntFunction<T> mapper = ....;
someList.stream().mapToInt(mapper) .... // now won't compile if mapToInt
expects Function<T, int>

That was the main concern that I have tried to express with the
initial letter. I am all for any easier workaround than the one I have
described, but if we want to move to ?IntStream is-a Stream<int>? (and I
guess we really want), some way to convert between specialized and generic
types should be present at least in some form.

On Thu, May 16, 2024 at 3:35?PM Brian Goetz <brian.goetz at oracle.com> wrote:

> I am currently working on some Stream API enhancements and its internals
> have become really complicated as time passed, mainly (imo), due to
> primitive-specialized pipelines.
>
>
> Slight correction: the internals were complicated from day 1, for this
> reason.  This is not something that ?happened over time?; the
> hand-specialization was part of its fundamental complexity.
>
> JEP 402, at first glance, looked like salvation
>
>
> You are mistaking JEP 402 for the full sweep of the Valhalla project.
> Indeed, Valhalla grew out of the observations of the painfulness of hand
> specialization (among other challenges).  But before we can get to full
> generic specialization with both layout and code specialization, we have to
> cover some fundamentals first.  There are many steps along the way here.
> We walk before we can run.
>
> What you are asking for is to blur the distinction between nominal and
> structural function types, allowing Predicate<T> and Function<T, boolean>
> to be considered ?the same? in some way.  While this is in some sense
> natural, this sort of ?anything goes? flexibility that incorporates both
> nominal and structural subtyping creates new problems, and even if not, is
> unlikely to move us very far in the direction of ?IntStream is-a
> Stream<int>?.
>
> Rest assured that we share your goal, but the path to get there is
> somewhat longer.
>
> , but the more I think about it, the more problems I see with integrating
> legacy with new features. Specialized stream pipelines are wired with
> specialized functional interfaces (ToXFunction, XPredicate etc.). This (and
> also some specialized for primitive ops of streams), make it impossible to
> harmlessly switch from XStream to Stream<X> (where X is primitive).
>
> While the second issue (specialized methods) could be addressed
> separately, one thing that could certainly help with eventually moving on
> from primitive-specialized types induced mess in current APIs is
> introducing covariance between generic types and their specialized
> versions. It is intuitive that ToLongFunction<T> is essentially the same as
> Function<T, long>. I saw a note at the end of the JEP that Long! and long
> are not fully interchangeable for some internal for JVM reasons, but the
> API that these interfaces provide are exactly the same. I understand that
> if public APIs that types provide are similar, that still doesn't mean
> their behaviour is the same, but while it does not mean it, it could be the
> case (and is a case in huge amounts of situations as when it comes to
> specialized types).
>
> If such covariance would be present in language, huge amounts of code
> could be just clamped as they are no longer needed. For example, whole
> IntPipeline could be clamped to IntPipeline extends ReferencePipeline<int>
> { /* proprietary methods of IntStream */ } instead of virtually a second
> ReferencePipeline class but specialized for int. This example is just the
> thing that is closest to me right now, but I am sure anyone could think of
> a way where this could be helpful for them.
>
> I am not really sure how this is implementable in a way that does not
> weaken the type system though. We can't just let users write that class A
> is covariant to class B<X> or something like that for obvious reasons. The
> easiest solution is to just add some compiler rules for a pre-defined
> number of types in jdk, but this still will leave all library devs and just
> users that had to write specialized types for some reason stranding. The
> rules for this covariance could surely be a topic of discussion for more
> experienced developers than me, but to have this feature would be a
> dramatic step forward in Java.
>
> Regards
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240516/6983950c/attachment.htm>

From paul.bjorkstrand at gmail.com  Thu May 16 13:52:19 2024
From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand)
Date: Thu, 16 May 2024 08:52:19 -0500
Subject: Primitive-parametrized classes covariance with pre-existing
 specialized types
In-Reply-To: <CAL5bRt83q-HJ7iabAKgcm5dKJKvkJdS45h9FTQK1CVpiCP2mpA@mail.gmail.com>
References: <CAL5bRt9SaDrL_RPLpDyPV9-Pq2Jb5CUySG_Fw7xg9giYs5X32Q@mail.gmail.com>
 <AE2959D8-4C07-4287-8514-9E7A6AB853B6@oracle.com>
 <CAL5bRt83q-HJ7iabAKgcm5dKJKvkJdS45h9FTQK1CVpiCP2mpA@mail.gmail.com>
Message-ID: <CAEs3EtM2+GN=nac1pFS=y1YpfvFiTnpwSBmQ780Xn=fpT0aVhg@mail.gmail.com>

It would compile if Predicate<T> extends Function<T, boolean>. I don't
think that specialized generics would equate to "immediately remove all
hand specializations." With Predicate's wide use, it would probably take a
decade or longer to fully remove it from the ecosystem, and that is
assuming it would be removed at all (how much code still uses HashTable,
when there are now generic replacements?)

// Paul


On Thu, May 16, 2024 at 8:23?AM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> While this is in some sense natural, this sort of ?anything goes?
>> flexibility that incorporates both nominal and structural subtyping creates
>> new problems, and even if not, is unlikely to move us very far in the
>> direction of ?IntStream is-a Stream<int>?.
>
> My main concern with transitioning from  Predicate<T> to Function<T,
> boolean> (or any other primitive-specialized, predicate is not the biggest
> problem, obviously) is that if currently, hypothetically, we have changed
> all specialized functional types to generic functional types, even if they
> essentially "behave the same", would completely brake
> backwards compatibility. Not even talking about binary compatibility, about
> which I don't know virtually anything, I could easily think of a scenario
> where this change would break source compatibility:
>
> ToIntFunction<T> mapper = ....;
> someList.stream().mapToInt(mapper) .... // now won't compile if mapToInt
> expects Function<T, int>
>
> That was the main concern that I have tried to express with the
> initial letter. I am all for any easier workaround than the one I have
> described, but if we want to move to ?IntStream is-a Stream<int>? (and I
> guess we really want), some way to convert between specialized and generic
> types should be present at least in some form.
>
> On Thu, May 16, 2024 at 3:35?PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> I am currently working on some Stream API enhancements and its internals
>> have become really complicated as time passed, mainly (imo), due to
>> primitive-specialized pipelines.
>>
>>
>> Slight correction: the internals were complicated from day 1, for this
>> reason.  This is not something that ?happened over time?; the
>> hand-specialization was part of its fundamental complexity.
>>
>> JEP 402, at first glance, looked like salvation
>>
>>
>> You are mistaking JEP 402 for the full sweep of the Valhalla project.
>> Indeed, Valhalla grew out of the observations of the painfulness of hand
>> specialization (among other challenges).  But before we can get to full
>> generic specialization with both layout and code specialization, we have to
>> cover some fundamentals first.  There are many steps along the way here.
>> We walk before we can run.
>>
>> What you are asking for is to blur the distinction between nominal and
>> structural function types, allowing Predicate<T> and Function<T, boolean>
>> to be considered ?the same? in some way.  While this is in some sense
>> natural, this sort of ?anything goes? flexibility that incorporates both
>> nominal and structural subtyping creates new problems, and even if not, is
>> unlikely to move us very far in the direction of ?IntStream is-a
>> Stream<int>?.
>>
>> Rest assured that we share your goal, but the path to get there is
>> somewhat longer.
>>
>> , but the more I think about it, the more problems I see with integrating
>> legacy with new features. Specialized stream pipelines are wired with
>> specialized functional interfaces (ToXFunction, XPredicate etc.). This (and
>> also some specialized for primitive ops of streams), make it impossible to
>> harmlessly switch from XStream to Stream<X> (where X is primitive).
>>
>> While the second issue (specialized methods) could be addressed
>> separately, one thing that could certainly help with eventually moving on
>> from primitive-specialized types induced mess in current APIs is
>> introducing covariance between generic types and their specialized
>> versions. It is intuitive that ToLongFunction<T> is essentially the same as
>> Function<T, long>. I saw a note at the end of the JEP that Long! and long
>> are not fully interchangeable for some internal for JVM reasons, but the
>> API that these interfaces provide are exactly the same. I understand that
>> if public APIs that types provide are similar, that still doesn't mean
>> their behaviour is the same, but while it does not mean it, it could be the
>> case (and is a case in huge amounts of situations as when it comes to
>> specialized types).
>>
>> If such covariance would be present in language, huge amounts of code
>> could be just clamped as they are no longer needed. For example, whole
>> IntPipeline could be clamped to IntPipeline extends ReferencePipeline<int>
>> { /* proprietary methods of IntStream */ } instead of virtually a second
>> ReferencePipeline class but specialized for int. This example is just the
>> thing that is closest to me right now, but I am sure anyone could think of
>> a way where this could be helpful for them.
>>
>> I am not really sure how this is implementable in a way that does not
>> weaken the type system though. We can't just let users write that class A
>> is covariant to class B<X> or something like that for obvious reasons. The
>> easiest solution is to just add some compiler rules for a pre-defined
>> number of types in jdk, but this still will leave all library devs and just
>> users that had to write specialized types for some reason stranding. The
>> rules for this covariance could surely be a topic of discussion for more
>> experienced developers than me, but to have this feature would be a
>> dramatic step forward in Java.
>>
>> Regards
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240516/4c45260e/attachment.htm>

From bkilambi at openjdk.org  Thu May 16 13:55:28 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 16 May 2024 13:55:28 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16
 add operation [v2]
In-Reply-To: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
References: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
Message-ID: <55vZczWry3u2c2UEnnskkMIkXTNGyKH-UCtKEfq43dg=.f5529874-ea8a-43ab-8436-cffefb6d3d90@github.com>

> This commit [1] adds initial support for FP16 operations and adds backend support for FP16 add operation for X86. This task adds backend support for scalar and vector FP16 add operation on aarch64.
> 
> [1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad

Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:

  Add a missing return statement in the ad file

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1096/files
  - new: https://git.openjdk.org/valhalla/pull/1096/files/1d09ba44..afdd81c6

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

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

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


From rotanolexandr842 at gmail.com  Thu May 16 14:06:05 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 16 May 2024 17:06:05 +0300
Subject: Primitive-parametrized classes covariance with pre-existing
 specialized types
In-Reply-To: <CAEs3EtM2+GN=nac1pFS=y1YpfvFiTnpwSBmQ780Xn=fpT0aVhg@mail.gmail.com>
References: <CAL5bRt9SaDrL_RPLpDyPV9-Pq2Jb5CUySG_Fw7xg9giYs5X32Q@mail.gmail.com>
 <AE2959D8-4C07-4287-8514-9E7A6AB853B6@oracle.com>
 <CAL5bRt83q-HJ7iabAKgcm5dKJKvkJdS45h9FTQK1CVpiCP2mpA@mail.gmail.com>
 <CAEs3EtM2+GN=nac1pFS=y1YpfvFiTnpwSBmQ780Xn=fpT0aVhg@mail.gmail.com>
Message-ID: <CAL5bRt_JE=U5geZbY3ytSsVVB20d-ZraY=+NohvJ=9oM_GzS6Q@mail.gmail.com>

It would compile, but then predicate will no longer be a functional
interface, isn't it? Correct me if I am wrong. There could be workarounds
using default methods though.

Also, both Function and Predicate are in the public API, so changing class
hierarchy could potentially (and will) break behavioural backward
compatibility in if and switch statements, and it will break it silently,
introducing bugs in various unexpected places.

On Thu, May 16, 2024 at 4:53?PM Paul Bjorkstrand <paul.bjorkstrand at gmail.com>
wrote:

> It would compile if Predicate<T> extends Function<T, boolean>. I don't
> think that specialized generics would equate to "immediately remove all
> hand specializations." With Predicate's wide use, it would probably take a
> decade or longer to fully remove it from the ecosystem, and that is
> assuming it would be removed at all (how much code still uses HashTable,
> when there are now generic replacements?)
>
> // Paul
>
>
> On Thu, May 16, 2024 at 8:23?AM Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
>
>> While this is in some sense natural, this sort of ?anything goes?
>>> flexibility that incorporates both nominal and structural subtyping creates
>>> new problems, and even if not, is unlikely to move us very far in the
>>> direction of ?IntStream is-a Stream<int>?.
>>
>> My main concern with transitioning from  Predicate<T> to Function<T,
>> boolean> (or any other primitive-specialized, predicate is not the biggest
>> problem, obviously) is that if currently, hypothetically, we have changed
>> all specialized functional types to generic functional types, even if they
>> essentially "behave the same", would completely brake
>> backwards compatibility. Not even talking about binary compatibility, about
>> which I don't know virtually anything, I could easily think of a scenario
>> where this change would break source compatibility:
>>
>> ToIntFunction<T> mapper = ....;
>> someList.stream().mapToInt(mapper) .... // now won't compile if mapToInt
>> expects Function<T, int>
>>
>> That was the main concern that I have tried to express with the
>> initial letter. I am all for any easier workaround than the one I have
>> described, but if we want to move to ?IntStream is-a Stream<int>? (and I
>> guess we really want), some way to convert between specialized and generic
>> types should be present at least in some form.
>>
>> On Thu, May 16, 2024 at 3:35?PM Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>> I am currently working on some Stream API enhancements and its internals
>>> have become really complicated as time passed, mainly (imo), due to
>>> primitive-specialized pipelines.
>>>
>>>
>>> Slight correction: the internals were complicated from day 1, for this
>>> reason.  This is not something that ?happened over time?; the
>>> hand-specialization was part of its fundamental complexity.
>>>
>>> JEP 402, at first glance, looked like salvation
>>>
>>>
>>> You are mistaking JEP 402 for the full sweep of the Valhalla project.
>>> Indeed, Valhalla grew out of the observations of the painfulness of hand
>>> specialization (among other challenges).  But before we can get to full
>>> generic specialization with both layout and code specialization, we have to
>>> cover some fundamentals first.  There are many steps along the way here.
>>> We walk before we can run.
>>>
>>> What you are asking for is to blur the distinction between nominal and
>>> structural function types, allowing Predicate<T> and Function<T, boolean>
>>> to be considered ?the same? in some way.  While this is in some sense
>>> natural, this sort of ?anything goes? flexibility that incorporates both
>>> nominal and structural subtyping creates new problems, and even if not, is
>>> unlikely to move us very far in the direction of ?IntStream is-a
>>> Stream<int>?.
>>>
>>> Rest assured that we share your goal, but the path to get there is
>>> somewhat longer.
>>>
>>> , but the more I think about it, the more problems I see with
>>> integrating legacy with new features. Specialized stream pipelines are
>>> wired with specialized functional interfaces (ToXFunction,
>>> XPredicate etc.). This (and also some specialized for primitive ops of
>>> streams), make it impossible to harmlessly switch from XStream to Stream<X>
>>> (where X is primitive).
>>>
>>> While the second issue (specialized methods) could be addressed
>>> separately, one thing that could certainly help with eventually moving on
>>> from primitive-specialized types induced mess in current APIs is
>>> introducing covariance between generic types and their specialized
>>> versions. It is intuitive that ToLongFunction<T> is essentially the same as
>>> Function<T, long>. I saw a note at the end of the JEP that Long! and long
>>> are not fully interchangeable for some internal for JVM reasons, but the
>>> API that these interfaces provide are exactly the same. I understand that
>>> if public APIs that types provide are similar, that still doesn't mean
>>> their behaviour is the same, but while it does not mean it, it could be the
>>> case (and is a case in huge amounts of situations as when it comes to
>>> specialized types).
>>>
>>> If such covariance would be present in language, huge amounts of code
>>> could be just clamped as they are no longer needed. For example, whole
>>> IntPipeline could be clamped to IntPipeline extends ReferencePipeline<int>
>>> { /* proprietary methods of IntStream */ } instead of virtually a second
>>> ReferencePipeline class but specialized for int. This example is just the
>>> thing that is closest to me right now, but I am sure anyone could think of
>>> a way where this could be helpful for them.
>>>
>>> I am not really sure how this is implementable in a way that does not
>>> weaken the type system though. We can't just let users write that class A
>>> is covariant to class B<X> or something like that for obvious reasons. The
>>> easiest solution is to just add some compiler rules for a pre-defined
>>> number of types in jdk, but this still will leave all library devs and just
>>> users that had to write specialized types for some reason stranding. The
>>> rules for this covariance could surely be a topic of discussion for more
>>> experienced developers than me, but to have this feature would be a
>>> dramatic step forward in Java.
>>>
>>> Regards
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240516/374d39a1/attachment.htm>

From brian.goetz at oracle.com  Thu May 16 14:48:50 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 16 May 2024 14:48:50 +0000
Subject: Primitive-parametrized classes covariance with pre-existing
 specialized types
In-Reply-To: <CAEs3EtM2+GN=nac1pFS=y1YpfvFiTnpwSBmQ780Xn=fpT0aVhg@mail.gmail.com>
References: <CAL5bRt9SaDrL_RPLpDyPV9-Pq2Jb5CUySG_Fw7xg9giYs5X32Q@mail.gmail.com>
 <AE2959D8-4C07-4287-8514-9E7A6AB853B6@oracle.com>
 <CAL5bRt83q-HJ7iabAKgcm5dKJKvkJdS45h9FTQK1CVpiCP2mpA@mail.gmail.com>
 <CAEs3EtM2+GN=nac1pFS=y1YpfvFiTnpwSBmQ780Xn=fpT0aVhg@mail.gmail.com>
Message-ID: <3CAD4D9E-3A7F-4008-BA15-5699B563776C@oracle.com>

Relating Predicate and Function is not hard (though has challenges).  The real problem is that, while Java supports covariant overrides for method returns, it lacks the dual feature of ?contra variant underrides? for method parameters.

On May 16, 2024, at 9:53?AM, Paul Bjorkstrand <paul.bjorkstrand at gmail.com> wrote:

?
It would compile if Predicate<T> extends Function<T, boolean>. I don't think that specialized generics would equate to "immediately remove all hand specializations." With Predicate's wide use, it would probably take a decade or longer to fully remove it from the ecosystem, and that is assuming it would be removed at all (how much code still uses HashTable, when there are now generic replacements?)

// Paul


On Thu, May 16, 2024 at 8:23?AM Olexandr Rotan <rotanolexandr842 at gmail.com<mailto:rotanolexandr842 at gmail.com>> wrote:
While this is in some sense natural, this sort of ?anything goes? flexibility that incorporates both nominal and structural subtyping creates new problems, and even if not, is unlikely to move us very far in the direction of ?IntStream is-a Stream<int>?.
My main concern with transitioning from  Predicate<T> to Function<T, boolean> (or any other primitive-specialized, predicate is not the biggest problem, obviously) is that if currently, hypothetically, we have changed all specialized functional types to generic functional types, even if they essentially "behave the same", would completely brake backwards compatibility. Not even talking about binary compatibility, about which I don't know virtually anything, I could easily think of a scenario where this change would break source compatibility:

ToIntFunction<T> mapper = ....;
someList.stream().mapToInt(mapper) .... // now won't compile if mapToInt expects Function<T, int>

That was the main concern that I have tried to express with the initial letter. I am all for any easier workaround than the one I have described, but if we want to move to ?IntStream is-a Stream<int>? (and I guess we really want), some way to convert between specialized and generic types should be present at least in some form.

On Thu, May 16, 2024 at 3:35?PM Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:
I am currently working on some Stream API enhancements and its internals have become really complicated as time passed, mainly (imo), due to primitive-specialized pipelines.

Slight correction: the internals were complicated from day 1, for this reason.  This is not something that ?happened over time?; the hand-specialization was part of its fundamental complexity.

JEP 402, at first glance, looked like salvation

You are mistaking JEP 402 for the full sweep of the Valhalla project.  Indeed, Valhalla grew out of the observations of the painfulness of hand specialization (among other challenges).  But before we can get to full generic specialization with both layout and code specialization, we have to cover some fundamentals first.  There are many steps along the way here.  We walk before we can run.

What you are asking for is to blur the distinction between nominal and structural function types, allowing Predicate<T> and Function<T, boolean> to be considered ?the same? in some way.  While this is in some sense natural, this sort of ?anything goes? flexibility that incorporates both nominal and structural subtyping creates new problems, and even if not, is unlikely to move us very far in the direction of ?IntStream is-a Stream<int>?.

Rest assured that we share your goal, but the path to get there is somewhat longer.

, but the more I think about it, the more problems I see with integrating legacy with new features. Specialized stream pipelines are wired with specialized functional interfaces (ToXFunction, XPredicate etc.). This (and also some specialized for primitive ops of streams), make it impossible to harmlessly switch from XStream to Stream<X> (where X is primitive).

While the second issue (specialized methods) could be addressed separately, one thing that could certainly help with eventually moving on from primitive-specialized types induced mess in current APIs is introducing covariance between generic types and their specialized versions. It is intuitive that ToLongFunction<T> is essentially the same as Function<T, long>. I saw a note at the end of the JEP that Long! and long are not fully interchangeable for some internal for JVM reasons, but the API that these interfaces provide are exactly the same. I understand that if public APIs that types provide are similar, that still doesn't mean their behaviour is the same, but while it does not mean it, it could be the case (and is a case in huge amounts of situations as when it comes to specialized types).

If such covariance would be present in language, huge amounts of code could be just clamped as they are no longer needed. For example, whole IntPipeline could be clamped to IntPipeline extends ReferencePipeline<int> { /* proprietary methods of IntStream */ } instead of virtually a second ReferencePipeline class but specialized for int. This example is just the thing that is closest to me right now, but I am sure anyone could think of a way where this could be helpful for them.

I am not really sure how this is implementable in a way that does not weaken the type system though. We can't just let users write that class A is covariant to class B<X> or something like that for obvious reasons. The easiest solution is to just add some compiler rules for a pre-defined number of types in jdk, but this still will leave all library devs and just users that had to write specialized types for some reason stranding. The rules for this covariance could surely be a topic of discussion for more experienced developers than me, but to have this feature would be a dramatic step forward in Java.

Regards

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

From jbossons at gmail.com  Sat May 18 17:24:10 2024
From: jbossons at gmail.com (John Bossons)
Date: Sat, 18 May 2024 13:24:10 -0400
Subject: Most recent JEP 401 description
Message-ID: <CACvEv_yCXOUL1wFA3v7uf2N7T84k3=7w+YBaxQaZM_z1RU6kOg@mail.gmail.com>

Thanks for making this so very clear.

Two questions/issues:
(1) It would be helpful to include more on the properties of abstract value
classes (AVCs) -- perhaps a labelled subsection? A specific question not
dealt with explicitly in the current version: Can an AVC have an instance
field, now that a value class utilizes the Flexible Constructor Bodies JEP?
(The alternative is  repetition of that field definition and accessor in
every subtype, which is potentially error-prone).
(2) It would also be helpful to include some commentary on limitations.
Specifically, although it is clear that the purpose is more efficiently
defined SMALL value objects, (a) How big is 'small'? And (b) will the
compiler accept value types of any size, no matter how deep?

John


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

From brian.goetz at oracle.com  Sun May 19 00:21:34 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 18 May 2024 20:21:34 -0400
Subject: Most recent JEP 401 description
In-Reply-To: <CACvEv_yCXOUL1wFA3v7uf2N7T84k3=7w+YBaxQaZM_z1RU6kOg@mail.gmail.com>
References: <CACvEv_yCXOUL1wFA3v7uf2N7T84k3=7w+YBaxQaZM_z1RU6kOg@mail.gmail.com>
Message-ID: <82a59a07-3eac-4364-93b2-aa9dc63bf236@oracle.com>

Amazingly, yes, value-capable abstract classes can have fields.? We 
thought for many years this would never be possible; the Great 
Initialization Alignment (eliminating `vnew` and `withfield` in favor of 
the `new` and `putfield` approach) made this possible.

The language imposes no restrictions on the number of fields of value 
types.? The VM reserves the right to flatten, or not, based on its 
whims.? One likely whim is that "large" values are usually not worth 
flattening.? But this is invisible to the user; the semantics are the 
same whether or not the object is flattened.

On 5/18/2024 1:24 PM, John Bossons wrote:
> Thanks for making this so very clear.
>
> Two questions/issues:
> (1) It would be helpful to include more on the properties of abstract 
> value classes (AVCs) -- perhaps a labelled subsection? A specific 
> question not dealt with explicitly in the current version: Can an AVC 
> have an instance field, now that a value class utilizes the 
> Flexible?Constructor Bodies JEP? (The alternative is ?repetition of 
> that field definition and accessor in every subtype, which is 
> potentially error-prone).
> (2) It would also be helpful to include some commentary on limitations.
> Specifically, although it is clear that the purpose is more 
> efficiently defined SMALL value objects, (a) How big is 'small'? And 
> (b) will the compiler accept value types of any size, no matter how deep?
>
> John
>
>
> Phone:? (416) 450-3584 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240518/e87de956/attachment.htm>

From jbossons at gmail.com  Sun May 19 04:18:55 2024
From: jbossons at gmail.com (John Bossons)
Date: Sun, 19 May 2024 00:18:55 -0400
Subject: Most recent JEP 401 description
In-Reply-To: <82a59a07-3eac-4364-93b2-aa9dc63bf236@oracle.com>
References: <CACvEv_yCXOUL1wFA3v7uf2N7T84k3=7w+YBaxQaZM_z1RU6kOg@mail.gmail.com>
 <82a59a07-3eac-4364-93b2-aa9dc63bf236@oracle.com>
Message-ID: <CACvEv_xdssM0iyx4bpEt_cFbztLHxCDbd9jMmP7bh75J6+mwxw@mail.gmail.com>

Thanks for the confirmation. Good news!

As to 'no restrictions' re size (horizontal - number of fields), fine. But
what about depth (vertical - fields that are value objects that in turn
contain fields that are value objects etc. all the way down)? No constraint
on depth of nesting?





On Sat, May 18, 2024 at 8:21?PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Amazingly, yes, value-capable abstract classes can have fields.  We
> thought for many years this would never be possible; the Great
> Initialization Alignment (eliminating `vnew` and `withfield` in favor of
> the `new` and `putfield` approach) made this possible.
>
> The language imposes no restrictions on the number of fields of value
> types.  The VM reserves the right to flatten, or not, based on its whims.
> One likely whim is that "large" values are usually not worth flattening.
> But this is invisible to the user; the semantics are the same whether or
> not the object is flattened.
>
> On 5/18/2024 1:24 PM, John Bossons wrote:
>
> Thanks for making this so very clear.
>
> Two questions/issues:
> (1) It would be helpful to include more on the properties of abstract
> value classes (AVCs) -- perhaps a labelled subsection? A specific question
> not dealt with explicitly in the current version: Can an AVC have an
> instance field, now that a value class utilizes the Flexible Constructor
> Bodies JEP? (The alternative is  repetition of that field definition and
> accessor in every subtype, which is potentially error-prone).
> (2) It would also be helpful to include some commentary on limitations.
> Specifically, although it is clear that the purpose is more efficiently
> defined SMALL value objects, (a) How big is 'small'? And (b) will the
> compiler accept value types of any size, no matter how deep?
>
> John
>
>
> 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/20240519/49520ce6/attachment.htm>

From fparain at openjdk.org  Tue May 21 20:10:27 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 21 May 2024 20:10:27 GMT
Subject: [lworld] Integrated: 8326598: [lworld] JVM must support field
 inheritance for value classes
In-Reply-To: <9Z6BWw82Lc4VUrHJYMGRvkMPZuNn9xR9rIiWjD2aID0=.4453932a-7a71-400e-a1b4-7bbc3f1b80c8@github.com>
References: <9Z6BWw82Lc4VUrHJYMGRvkMPZuNn9xR9rIiWjD2aID0=.4453932a-7a71-400e-a1b4-7bbc3f1b80c8@github.com>
Message-ID: <ME10TUaxXd-WOZSpc5OEeh-9mRw1kXDYJypfgywGItE=.eaa37303-8f1a-4365-a2a5-52274fab933e@github.com>

On Wed, 8 May 2024 19:42:31 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Adds field inheritance for value classes.
> Layouts of value classes that inherited fields are not always optimal, but fixing them would require a new placement algorithm which is beyond the scope of this CR.
> The test is currently limited to the interpreted mode because of issues with CI and C2 tracked by JDK-8331964.

This pull request has now been integrated.

Changeset: f2f813da
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f2f813da4f557100e33244df2dc7cd0aff1174f5
Stats:     498 lines in 5 files changed: 361 ins; 39 del; 98 mod

8326598: [lworld] JVM must support field inheritance for value classes

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

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


From brian.goetz at oracle.com  Wed May 22 13:42:59 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 22 May 2024 09:42:59 -0400
Subject: Most recent JEP 401 description
In-Reply-To: <CACvEv_xdssM0iyx4bpEt_cFbztLHxCDbd9jMmP7bh75J6+mwxw@mail.gmail.com>
References: <CACvEv_yCXOUL1wFA3v7uf2N7T84k3=7w+YBaxQaZM_z1RU6kOg@mail.gmail.com>
 <82a59a07-3eac-4364-93b2-aa9dc63bf236@oracle.com>
 <CACvEv_xdssM0iyx4bpEt_cFbztLHxCDbd9jMmP7bh75J6+mwxw@mail.gmail.com>
Message-ID: <2e167ece-5e5e-4e69-ac52-8467f788eccc@oracle.com>

There are no restrictions in the specification.? However, the object 
layout algorithm is already quite complicated, so it is possible there 
will be implementation limitations, at least at first.

On 5/19/2024 12:18 AM, John Bossons wrote:
> Thanks for?the?confirmation. Good news!
>
> As to 'no restrictions' re size (horizontal - number of fields), fine. 
> But what about depth (vertical - fields that are value objects that in 
> turn contain fields that are value objects etc. all the way down)? No 
> constraint on depth of nesting?
>
>
>
>
>
> On Sat, May 18, 2024 at 8:21?PM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>     Amazingly, yes, value-capable abstract classes can have fields.?
>     We thought for many years this would never be possible; the Great
>     Initialization Alignment (eliminating `vnew` and `withfield` in
>     favor of the `new` and `putfield` approach) made this possible.
>
>     The language imposes no restrictions on the number of fields of
>     value types.? The VM reserves the right to flatten, or not, based
>     on its whims.? One likely whim is that "large" values are usually
>     not worth flattening.? But this is invisible to the user; the
>     semantics are the same whether or not the object is flattened.
>
>     On 5/18/2024 1:24 PM, John Bossons wrote:
>>     Thanks for making this so very clear.
>>
>>     Two questions/issues:
>>     (1) It would be helpful to include more on the properties of
>>     abstract value classes (AVCs) -- perhaps a labelled subsection? A
>>     specific question not dealt with explicitly in the current
>>     version: Can an AVC have an instance field, now that a value
>>     class utilizes the Flexible?Constructor Bodies JEP? (The
>>     alternative is ?repetition of that field definition and accessor
>>     in every subtype, which is potentially error-prone).
>>     (2) It would also be helpful to include some commentary on
>>     limitations.
>>     Specifically, although it is clear that the purpose is more
>>     efficiently defined SMALL value objects, (a) How big is 'small'?
>>     And (b) will the compiler accept value types of any size, no
>>     matter how deep?
>>
>>     John
>>
>>
>>     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/20240522/0a297afb/attachment.htm>

From liangchenblue at gmail.com  Wed May 22 14:47:31 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Wed, 22 May 2024 09:47:31 -0500
Subject: Most recent JEP 401 description
In-Reply-To: <2e167ece-5e5e-4e69-ac52-8467f788eccc@oracle.com>
References: <CACvEv_yCXOUL1wFA3v7uf2N7T84k3=7w+YBaxQaZM_z1RU6kOg@mail.gmail.com>
 <82a59a07-3eac-4364-93b2-aa9dc63bf236@oracle.com>
 <CACvEv_xdssM0iyx4bpEt_cFbztLHxCDbd9jMmP7bh75J6+mwxw@mail.gmail.com>
 <2e167ece-5e5e-4e69-ac52-8467f788eccc@oracle.com>
Message-ID: <CABe8uE3nHSg06Y=cv5izqLf4L9g67qxBdaTQcy+-hUu-jmyvbg@mail.gmail.com>

For your information, John Rose has recently written a few essays on layout
of flattened values in the VM:
https://cr.openjdk.org/~jrose/values/flattened-values.html
Also another recent article discussing loose consistency (old "primitive
classes"): https://cr.openjdk.org/~jrose/values/loose-consistency.html

On Wed, May 22, 2024 at 9:37?AM Brian Goetz <brian.goetz at oracle.com> wrote:

> There are no restrictions in the specification.  However, the object
> layout algorithm is already quite complicated, so it is possible there will
> be implementation limitations, at least at first.
>
> On 5/19/2024 12:18 AM, John Bossons wrote:
>
> Thanks for the confirmation. Good news!
>
> As to 'no restrictions' re size (horizontal - number of fields), fine. But
> what about depth (vertical - fields that are value objects that in turn
> contain fields that are value objects etc. all the way down)? No constraint
> on depth of nesting?
>
>
>
>
>
> On Sat, May 18, 2024 at 8:21?PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> Amazingly, yes, value-capable abstract classes can have fields.  We
>> thought for many years this would never be possible; the Great
>> Initialization Alignment (eliminating `vnew` and `withfield` in favor of
>> the `new` and `putfield` approach) made this possible.
>>
>> The language imposes no restrictions on the number of fields of value
>> types.  The VM reserves the right to flatten, or not, based on its whims.
>> One likely whim is that "large" values are usually not worth flattening.
>> But this is invisible to the user; the semantics are the same whether or
>> not the object is flattened.
>>
>> On 5/18/2024 1:24 PM, John Bossons wrote:
>>
>> Thanks for making this so very clear.
>>
>> Two questions/issues:
>> (1) It would be helpful to include more on the properties of abstract
>> value classes (AVCs) -- perhaps a labelled subsection? A specific question
>> not dealt with explicitly in the current version: Can an AVC have an
>> instance field, now that a value class utilizes the Flexible Constructor
>> Bodies JEP? (The alternative is  repetition of that field definition and
>> accessor in every subtype, which is potentially error-prone).
>> (2) It would also be helpful to include some commentary on limitations.
>> Specifically, although it is clear that the purpose is more efficiently
>> defined SMALL value objects, (a) How big is 'small'? And (b) will the
>> compiler accept value types of any size, no matter how deep?
>>
>> John
>>
>>
>> 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/20240522/0915fb31/attachment.htm>

From fparain at openjdk.org  Wed May 22 20:03:29 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 22 May 2024 20:03:29 GMT
Subject: [lworld] RFR: 8332387: [lworld] monitorenter on value class instances
 must throw IdentityException instead of IllegalMonitorStateException
Message-ID: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>

Change the exception thrown by monitorenter when attempted on an instance of a value class.
Monitorexit is not changed according to some discussions about the JVMS changes (it still throws IllegalMonitorStateException).

Tested with Mach5, tier1-3.

Fred

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

Commit messages:
 - Merge remote-tracking branch 'upstream/lworld' into monitor_exception
 - Change monitorenter exception from IMSE to IE when argument is a value

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

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


From heidinga at openjdk.org  Thu May 23 13:49:16 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 23 May 2024 13:49:16 GMT
Subject: [lworld] RFR: 8332387: [lworld] monitorenter on value class
 instances must throw IdentityException instead of IllegalMonitorStateException
In-Reply-To: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
References: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
Message-ID: <ub1zR3R0M_vScC3XxniqH-XbsL6aD9a9bwDlrCw-RbQ=.00627615-1c95-403a-bd97-1fda6ba5bbb2@github.com>

On Wed, 22 May 2024 19:58:01 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Change the exception thrown by monitorenter when attempted on an instance of a value class.
> Monitorexit is not changed according to some discussions about the JVMS changes (it still throws IllegalMonitorStateException).
> 
> Tested with Mach5, tier1-3.
> 
> Fred

Looks straightforward and correct by pattern match =) apart from a minor question

src/hotspot/share/c1/c1_LIR.cpp line 841:

> 839: 
> 840:       do_stub(opLock->_stub);
> 841:       do_stub(opLock->_throw_ie_stub);

Does `_throw_ie_stub` apply to both `lir_lock` & 'lir_unlock`?  I thought only `monitorenter` was being changed.

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

PR Review: https://git.openjdk.org/valhalla/pull/1108#pullrequestreview-2074020257
PR Review Comment: https://git.openjdk.org/valhalla/pull/1108#discussion_r1611724324


From fparain at openjdk.org  Thu May 23 17:24:15 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 May 2024 17:24:15 GMT
Subject: [lworld] RFR: 8332387: [lworld] monitorenter on value class
 instances must throw IdentityException instead of IllegalMonitorStateException
In-Reply-To: <ub1zR3R0M_vScC3XxniqH-XbsL6aD9a9bwDlrCw-RbQ=.00627615-1c95-403a-bd97-1fda6ba5bbb2@github.com>
References: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
 <ub1zR3R0M_vScC3XxniqH-XbsL6aD9a9bwDlrCw-RbQ=.00627615-1c95-403a-bd97-1fda6ba5bbb2@github.com>
Message-ID: <CXEE3XJhGAqLeHMBCQyV3RnXf4Hr-ns1YwSCdbdz4zk=.f0cb700b-d44a-4065-97c8-b2baa13d4a60@github.com>

On Thu, 23 May 2024 13:42:33 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Change the exception thrown by monitorenter when attempted on an instance of a value class.
>> Monitorexit is not changed according to some discussions about the JVMS changes (it still throws IllegalMonitorStateException).
>> 
>> Tested with Mach5, tier1-3.
>> 
>> Fred
>
> src/hotspot/share/c1/c1_LIR.cpp line 841:
> 
>> 839: 
>> 840:       do_stub(opLock->_stub);
>> 841:       do_stub(opLock->_throw_ie_stub);
> 
> Does `_throw_ie_stub` apply to both `lir_lock` & 'lir_unlock`?  I thought only `monitorenter` was being changed.

When creating a LIR_OpLock for lir_unlock (in LIR_List::unlock_object(), c1_LIR.cpp:1576), no stub is provided so _throw_ie_stub is null. And do_stub() does nothing if the pointer passed in argument is null.
Did I miss something?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1108#discussion_r1612064611


From heidinga at openjdk.org  Thu May 23 17:32:13 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 23 May 2024 17:32:13 GMT
Subject: [lworld] RFR: 8332387: [lworld] monitorenter on value class
 instances must throw IdentityException instead of IllegalMonitorStateException
In-Reply-To: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
References: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
Message-ID: <l9ptFHYAbD3ERTuAF-x1tdBJhtE1TH3KsNheMFtdZZY=.679ed9e1-3800-4637-942e-d8677180ff27@github.com>

On Wed, 22 May 2024 19:58:01 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Change the exception thrown by monitorenter when attempted on an instance of a value class.
> Monitorexit is not changed according to some discussions about the JVMS changes (it still throws IllegalMonitorStateException).
> 
> Tested with Mach5, tier1-3.
> 
> Fred

Marked as reviewed by heidinga (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1108#pullrequestreview-2074620706


From heidinga at openjdk.org  Thu May 23 17:32:14 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 23 May 2024 17:32:14 GMT
Subject: [lworld] RFR: 8332387: [lworld] monitorenter on value class
 instances must throw IdentityException instead of IllegalMonitorStateException
In-Reply-To: <CXEE3XJhGAqLeHMBCQyV3RnXf4Hr-ns1YwSCdbdz4zk=.f0cb700b-d44a-4065-97c8-b2baa13d4a60@github.com>
References: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
 <ub1zR3R0M_vScC3XxniqH-XbsL6aD9a9bwDlrCw-RbQ=.00627615-1c95-403a-bd97-1fda6ba5bbb2@github.com>
 <CXEE3XJhGAqLeHMBCQyV3RnXf4Hr-ns1YwSCdbdz4zk=.f0cb700b-d44a-4065-97c8-b2baa13d4a60@github.com>
Message-ID: <uTODDDjjS2E3tuyOV_8HWRLEqmNHpvgRD79rwKD9VlE=.27d96773-749c-43e0-b6c4-d65b1d9ad496@github.com>

On Thu, 23 May 2024 17:21:55 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/c1/c1_LIR.cpp line 841:
>> 
>>> 839: 
>>> 840:       do_stub(opLock->_stub);
>>> 841:       do_stub(opLock->_throw_ie_stub);
>> 
>> Does `_throw_ie_stub` apply to both `lir_lock` & 'lir_unlock`?  I thought only `monitorenter` was being changed.
>
> When creating a LIR_OpLock for lir_unlock (in LIR_List::unlock_object(), c1_LIR.cpp:1576), no stub is provided so _throw_ie_stub is null. And do_stub() does nothing if the pointer passed in argument is null.
> Did I miss something?

You're correct. Thanks for confirming

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1108#discussion_r1612072903


From fparain at openjdk.org  Thu May 23 18:19:27 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 May 2024 18:19:27 GMT
Subject: [lworld] RFR: 8332387: [lworld] monitorenter on value class
 instances must throw IdentityException instead of IllegalMonitorStateException
In-Reply-To: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
References: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
Message-ID: <TLx-5RPvtVNTf1aKeHg219Ho4ZrEx0hlNIEzm9p62bk=.8da94909-853c-4817-8e7d-122c234922a6@github.com>

On Wed, 22 May 2024 19:58:01 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Change the exception thrown by monitorenter when attempted on an instance of a value class.
> Monitorexit is not changed according to some discussions about the JVMS changes (it still throws IllegalMonitorStateException).
> 
> Tested with Mach5, tier1-3.
> 
> Fred

Dan,

Thank you for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1108#issuecomment-2127773321


From fparain at openjdk.org  Thu May 23 18:19:27 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 May 2024 18:19:27 GMT
Subject: [lworld] Integrated: 8332387: [lworld] monitorenter on value class
 instances must throw IdentityException instead of IllegalMonitorStateException
In-Reply-To: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
References: <JVkUTnARybytvrJe1hg_x-VXtN70rmzffTu8fjyaYio=.46c7be43-9125-4299-9b11-4e1058dc8be7@github.com>
Message-ID: <jot_S1p5YUUVJp8SnaHDD8xlQy0dgZJFUJKyj4IX58I=.5be8dc4b-31f2-40ea-8f15-c6e4da52ed02@github.com>

On Wed, 22 May 2024 19:58:01 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Change the exception thrown by monitorenter when attempted on an instance of a value class.
> Monitorexit is not changed according to some discussions about the JVMS changes (it still throws IllegalMonitorStateException).
> 
> Tested with Mach5, tier1-3.
> 
> Fred

This pull request has now been integrated.

Changeset: 0ea02dad
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0ea02dad905376eb52e0f71368363bfc97f2cea1
Stats:     87 lines in 24 files changed: 29 ins; 2 del; 56 mod

8332387: [lworld] monitorenter on value class instances must throw IdentityException instead of IllegalMonitorStateException

Reviewed-by: heidinga

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

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


From thartmann at openjdk.org  Tue May 28 09:47:35 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 28 May 2024 09:47:35 GMT
Subject: [lworld] RFR: 8333037: [lworld] Part 2: Prepare compiler
 implementation and tests for JEP 401
Message-ID: <rNQ937eo-FEPflLugRTIpWDBMKzR3ZuaSgjutcc6T1o=.a7f91b3e-a9ce-43b3-b79f-9c81d48ce804@github.com>

Fixing a few more test and implementation issues that came with or were triggered by the JEP 401 related changes. The remaining issues / ToDo's will be fixed by [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106).

Thanks,
Tobias

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

Commit messages:
 - 8333037: [lworld] Part 2: Prepare compiler implementation and tests for JEP 401

Changes: https://git.openjdk.org/valhalla/pull/1110/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333037
  Stats: 277 lines in 30 files changed: 66 ins; 131 del; 80 mod
  Patch: https://git.openjdk.org/valhalla/pull/1110.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1110/head:pull/1110

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


From thartmann at openjdk.org  Tue May 28 10:46:16 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 28 May 2024 10:46:16 GMT
Subject: [lworld] Integrated: 8333037: [lworld] Part 2: Prepare compiler
 implementation and tests for JEP 401
In-Reply-To: <rNQ937eo-FEPflLugRTIpWDBMKzR3ZuaSgjutcc6T1o=.a7f91b3e-a9ce-43b3-b79f-9c81d48ce804@github.com>
References: <rNQ937eo-FEPflLugRTIpWDBMKzR3ZuaSgjutcc6T1o=.a7f91b3e-a9ce-43b3-b79f-9c81d48ce804@github.com>
Message-ID: <O09w-JFEUkY2_xqRWB2o1cuhHaKf7Rq_QEcPMSW4X54=.cc869774-0acd-4ce3-9a62-feaf48cce329@github.com>

On Tue, 28 May 2024 09:42:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Fixing a few more test and implementation issues that came with or were triggered by the JEP 401 related changes. The remaining issues / ToDo's will be fixed by [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: fcf2f796
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/fcf2f79683aeb005b9991faaafa68e2ca440ec4c
Stats:     277 lines in 30 files changed: 66 ins; 131 del; 80 mod

8333037: [lworld] Part 2: Prepare compiler implementation and tests for JEP 401

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

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


From thartmann at openjdk.org  Tue May 28 13:24:31 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 28 May 2024 13:24:31 GMT
Subject: [lworld] RFR: 8333087: [lworld] Undo problem listing and remove assert
 added due to JDK-8331766
Message-ID: <Sb_CjI33WP1zUYXGAJDrLnreW-SXSHmv8a1qEc81aF4=.88703d41-3f5b-4c68-89ba-06430adad1f0@github.com>

The issue described by [JDK-8331766](https://bugs.openjdk.org/browse/JDK-8331766) does not reproduce anymore. Undo the problem listing and remove the corresponding assert.

Thanks,
Tobias

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

Commit messages:
 - Undo problem listing and remove the assert

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

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


From thartmann at openjdk.org  Tue May 28 15:42:18 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 28 May 2024 15:42:18 GMT
Subject: [lworld] Integrated: 8333087: [lworld] Undo problem listing and remove
 assert added due to JDK-8331766
In-Reply-To: <Sb_CjI33WP1zUYXGAJDrLnreW-SXSHmv8a1qEc81aF4=.88703d41-3f5b-4c68-89ba-06430adad1f0@github.com>
References: <Sb_CjI33WP1zUYXGAJDrLnreW-SXSHmv8a1qEc81aF4=.88703d41-3f5b-4c68-89ba-06430adad1f0@github.com>
Message-ID: <LJd4Bc5z5KGKv2bny3mzqB8y4uy5LzK2beBKnWpIX2I=.33d8a875-b2ca-4aee-a4e0-a8c633327ca9@github.com>

On Tue, 28 May 2024 13:19:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The issue described by [JDK-8331766](https://bugs.openjdk.org/browse/JDK-8331766) does not reproduce anymore. Undo the problem listing and remove the corresponding assert.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8333087: [lworld] Undo problem listing and remove assert added due to JDK-8331766

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

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


From duke at openjdk.org  Fri May 31 17:47:23 2024
From: duke at openjdk.org (Jens Lidestrom)
Date: Fri, 31 May 2024 17:47:23 GMT
Subject: [lworld] RFR: 8331496: [lworld] Class::isValue,
 Class::isIdentity and new java.lang.reflect APIs should be reflective preview
 API
In-Reply-To: <8TmIBRLIn2a5WN_Ls47UZKtBRHoNTQoKLAQ8LSoRUwc=.ace3c7a1-d3ee-40c1-9eb8-d2b19957cbd4@github.com>
References: <8TmIBRLIn2a5WN_Ls47UZKtBRHoNTQoKLAQ8LSoRUwc=.ace3c7a1-d3ee-40c1-9eb8-d2b19957cbd4@github.com>
Message-ID: <gjUhogbe9TsfCPqXjJz4dGCBEn84HIgnLRMmWCREcSE=.59d85643-c712-40e0-8e60-26fa92c219c8@github.com>

On Wed, 1 May 2024 16:21:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Mark the reflection APIs added for JEP 401 as reflective preview API.

src/java.base/share/classes/java/lang/Class.java line 704:

> 702:      * @since Valhalla
> 703:      */
> 704:     @PreviewFeature(feature = PreviewFeature.Feature.VALUE_OBJECTS, reflective=true)

There should probably be spaces around `=`:


reflective = true

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1090#discussion_r1622761352


From fparain at openjdk.org  Fri May 31 21:03:39 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 31 May 2024 21:03:39 GMT
Subject: [lworld] Integrated: 8333376: [lworld]
 runtime/cds/appcds/RewriteBytecodesInlineTest.java fails because of missing
 preview mode
Message-ID: <3N_OQ6A13pUtJSnF9s3rKz5KHVk8pcnNZIrYOFbU8IY=.272afa05-b8c1-42e0-bbef-93bdb34d8e92@github.com>

Change test invocation method to enable preview mode in the VM analyzing the output of the test.

Tested with Mach5 on all platforms.

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

Commit messages:
 - Fix test invocation to enable preview mode

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

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


From fparain at openjdk.org  Fri May 31 21:03:40 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 31 May 2024 21:03:40 GMT
Subject: [lworld] Integrated: 8333376: [lworld]
 runtime/cds/appcds/RewriteBytecodesInlineTest.java fails because of missing
 preview mode
In-Reply-To: <3N_OQ6A13pUtJSnF9s3rKz5KHVk8pcnNZIrYOFbU8IY=.272afa05-b8c1-42e0-bbef-93bdb34d8e92@github.com>
References: <3N_OQ6A13pUtJSnF9s3rKz5KHVk8pcnNZIrYOFbU8IY=.272afa05-b8c1-42e0-bbef-93bdb34d8e92@github.com>
Message-ID: <bHG-Mj1SbzhROpWFLrGlHrv2M0fUTDGwUAm3WtnvWrA=.75bd50bf-0b09-4e6e-b257-34dee1e8aaa8@github.com>

On Fri, 31 May 2024 20:57:38 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Change test invocation method to enable preview mode in the VM analyzing the output of the test.
> 
> Tested with Mach5 on all platforms.

This pull request has now been integrated.

Changeset: 24300107
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/24300107ca1bdb0878873973871a057193afac4a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8333376: [lworld] runtime/cds/appcds/RewriteBytecodesInlineTest.java fails because of missing preview mode

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

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