From qamai at openjdk.org  Fri Aug  1 09:52:33 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 1 Aug 2025 09:52:33 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
Message-ID: <9AdjPfcMo_PPTNaDqRyBBQXsJbmdjeRwS5LzPda_wkY=.7f7b838b-cdcd-4bcb-83d5-2fe6e9496455@github.com>

> Hi,
> 
> Flat accesses prevent scalar replacement because they are mismatched accesses. It is also generally not possible to look through them, because the payload may contain an oop in the form of raw bits. As a result, this PR adds `LoadFlatNode` and `StoreFlatNode`, which act as high-level abstractions for atomic accesses on flat fields. When it is determined that there is no racing access on the flat field (e.g. because the holder object does not escape), these flat access nodes can be expanded into multiple accesses to each flattened fields, otherwise, they will be expanded into a sequence of inferring a payload and accessing memory with that payload.
> 
> I also fix an issue with deoptimization reallocation where we miss assigning the null marker of elements in a nullable flat array.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  small fix StoreFlatNode::size_of

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1518/files
  - new: https://git.openjdk.org/valhalla/pull/1518/files/23828cc7..428b656c

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

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

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

From coleenp at openjdk.org  Fri Aug  1 15:22:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 1 Aug 2025 15:22:36 GMT
Subject: [lworld] RFR: [lworld] Remove redundant DTraceAlloc/Method probes
Message-ID: <6YdvMt4v6E_bxLcdjK3toUTUUnCSOQvANFGEVo7tzS4=.d43baad8-eedf-4fd5-a4d8-9477bb085249@github.com>

Looking through this code, I found this discrepancy.  Tested with some tier1 testing.

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

Commit messages:
 - Remove redundant DTraceAlloc/Method probes.

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

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

From thartmann at openjdk.org  Mon Aug  4 19:45:35 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 4 Aug 2025 19:45:35 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <9AdjPfcMo_PPTNaDqRyBBQXsJbmdjeRwS5LzPda_wkY=.7f7b838b-cdcd-4bcb-83d5-2fe6e9496455@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
 <9AdjPfcMo_PPTNaDqRyBBQXsJbmdjeRwS5LzPda_wkY=.7f7b838b-cdcd-4bcb-83d5-2fe6e9496455@github.com>
Message-ID: <hlKp6ranoH3nnwwV_4h4JFaU__lA31G32HvCZG5MFn0=.ff7bae4d-b982-4e97-8bd5-276e2e11d0e9@github.com>

On Fri, 1 Aug 2025 09:52:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Flat accesses prevent scalar replacement because they are mismatched accesses. It is also generally not possible to look through them, because the payload may contain an oop in the form of raw bits. As a result, this PR adds `LoadFlatNode` and `StoreFlatNode`, which act as high-level abstractions for atomic accesses on flat fields. When it is determined that there is no racing access on the flat field (e.g. because the holder object does not escape), these flat access nodes can be expanded into multiple accesses to each flattened fields, otherwise, they will be expanded into a sequence of inferring a payload and accessing memory with that payload.
>> 
>> I also fix an issue with deoptimization reallocation where we miss assigning the null marker of elements in a nullable flat array.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small fix StoreFlatNode::size_of

Thanks for working on this @merykitty! I haven't reviewed this in yet but noticed a build failure:


[2025-08-04T17:23:31,905Z] /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.cpp: In member function 'void ConnectionGraph::add_final_edges(Node*)':
[2025-08-04T17:23:31,905Z] /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.cpp:1874:25: error: no matching function for call to 'ConnectionGraph::set_escape_state(PointsToNode*&, PointsToNode::EscapeState, const char [24])'
[2025-08-04T17:23:31,905Z]  1874 |         set_escape_state(field_value_ptn, PointsToNode::GlobalEscape, "store into a flat field");
[2025-08-04T17:23:31,905Z]       |         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[2025-08-04T17:23:31,905Z] In file included from /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.cpp:38:
[2025-08-04T17:23:31,905Z] /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.hpp:434:8: note: candidate: 'void ConnectionGraph::set_escape_state(PointsToNode*, PointsToNode::EscapeState)'
[2025-08-04T17:23:31,905Z]   434 |   void set_escape_state(PointsToNode* ptn, PointsToNode::EscapeState esc
[2025-08-04T17:23:31,905Z]       |        ^~~~~~~~~~~~~~~~
[2025-08-04T17:23:31,905Z] /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.hpp:434:8: note:   candidate expects 2 arguments, 3 provided
[2025-08-04T17:23:32,241Z] lib/CompileJvm.gmk:172: recipe for target '/opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/build/linux-x64/hotspot/variant-server/libjvm/objs/static/escape.o' failed
[2025-08-04T17:23:32,241Z] make[3]: *** [/opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/build/linux-x64/hotspot/variant-server/libjvm/objs/static/escape.o] Error 1

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

PR Comment: https://git.openjdk.org/valhalla/pull/1518#issuecomment-3152113964

From liach at openjdk.org  Tue Aug  5 14:12:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:12:29 GMT
Subject: [lworld] RFR: 8360653: [lworld] LayoutIterationTest.java fails
 with -XX:ForceNonTearable=*
In-Reply-To: <uSZPYtwpQQW2sQH0w69cAsJIZl3z0AaG4Abr2nURGpc=.1d983bb0-6d8c-4200-acdb-cf9a2a440897@github.com>
References: <uSZPYtwpQQW2sQH0w69cAsJIZl3z0AaG4Abr2nURGpc=.1d983bb0-6d8c-4200-acdb-cf9a2a440897@github.com>
Message-ID: <-OTFrD7SRDsEA7pZUTN6eCy_hXEUOGvgK0uE5OfWWDI=.04ea2be5-c820-4ae6-9c3f-64e348df474e@github.com>

On Tue, 8 Jul 2025 00:37:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Mark this test as flagless so we will skip it with any layout perturbation.

Guess people don't bother to review this. I will just integrate.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1505#issuecomment-3155390504

From liach at openjdk.org  Tue Aug  5 14:12:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Aug 2025 14:12:29 GMT
Subject: [lworld] Integrated: 8360653: [lworld] LayoutIterationTest.java fails
 with -XX:ForceNonTearable=*
In-Reply-To: <uSZPYtwpQQW2sQH0w69cAsJIZl3z0AaG4Abr2nURGpc=.1d983bb0-6d8c-4200-acdb-cf9a2a440897@github.com>
References: <uSZPYtwpQQW2sQH0w69cAsJIZl3z0AaG4Abr2nURGpc=.1d983bb0-6d8c-4200-acdb-cf9a2a440897@github.com>
Message-ID: <JGuDzJSaAikyd1Wn79s7E0cAYZpIynhZlIp9p-5s1RQ=.53e1cc88-b337-4cf2-a94b-63d821e7d0f4@github.com>

On Tue, 8 Jul 2025 00:37:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Mark this test as flagless so we will skip it with any layout perturbation.

This pull request has now been integrated.

Changeset: 67e6bcc4
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/67e6bcc418721eded34878eb70c7d0a86df338b1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8360653: [lworld] LayoutIterationTest.java fails with -XX:ForceNonTearable=*

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

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

From fparain at openjdk.org  Wed Aug  6 18:33:33 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 6 Aug 2025 18:33:33 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders
In-Reply-To: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
Message-ID: <1j2m-tN1ooL4XvU_pdJ5G4Cbxt7xkjosAIsr91f_lY0=.0d514dc6-86b0-4994-8d4c-7b881f1bfafc@github.com>

On Thu, 31 Jul 2025 20:10:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.

src/hotspot/share/classfile/vmSymbols.hpp line 900:

> 898:   static void migrated_class_names_do(Function f) {
> 899:      for (int i = 0; i < _migrated_class_names_length; i++) {
> 900:        //f->do_symbol(&_migrated_class_names[i]);

Commented line to be removed?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1520#discussion_r2257963156

From coleenp at openjdk.org  Wed Aug  6 21:48:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Aug 2025 21:48:03 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v2]
In-Reply-To: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
Message-ID: <CRCW638JH6jv5NaqAf1pLUrKi3noeyfNh5WEev3I3h0=.011055b0-26cc-4dea-8ea7-68d30fedc158@github.com>

> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  remove commented out code.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1520/files
  - new: https://git.openjdk.org/valhalla/pull/1520/files/0fd70f7e..1b85463c

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

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

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

From qamai at openjdk.org  Thu Aug  7 13:34:54 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 7 Aug 2025 13:34:54 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v3]
In-Reply-To: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
Message-ID: <aXVSCkSXGFnGJO3sVqNKiDEShrzVpZoBAUy6G24ga4o=.414f8352-7a65-4e55-9be4-ee4918077a59@github.com>

> Hi,
> 
> Flat accesses prevent scalar replacement because they are mismatched accesses. It is also generally not possible to look through them, because the payload may contain an oop in the form of raw bits. As a result, this PR adds `LoadFlatNode` and `StoreFlatNode`, which act as high-level abstractions for atomic accesses on flat fields. When it is determined that there is no racing access on the flat field (e.g. because the holder object does not escape), these flat access nodes can be expanded into multiple accesses to each flattened fields, otherwise, they will be expanded into a sequence of inferring a payload and accessing memory with that payload.
> 
> I also fix an issue with deoptimization reallocation where we miss assigning the null marker of elements in a nullable flat array.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix release build

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1518/files
  - new: https://git.openjdk.org/valhalla/pull/1518/files/428b656c..eb23f4e5

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

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

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

From qamai at openjdk.org  Thu Aug  7 13:34:54 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 7 Aug 2025 13:34:54 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <hlKp6ranoH3nnwwV_4h4JFaU__lA31G32HvCZG5MFn0=.ff7bae4d-b982-4e97-8bd5-276e2e11d0e9@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
 <9AdjPfcMo_PPTNaDqRyBBQXsJbmdjeRwS5LzPda_wkY=.7f7b838b-cdcd-4bcb-83d5-2fe6e9496455@github.com>
 <hlKp6ranoH3nnwwV_4h4JFaU__lA31G32HvCZG5MFn0=.ff7bae4d-b982-4e97-8bd5-276e2e11d0e9@github.com>
Message-ID: <cDnmfPYgLrvZ4bFNtS9F_fH_WfJWzSNFBV770HPTT8M=.1d80023c-b2a9-4844-b4a0-6248de952169@github.com>

On Mon, 4 Aug 2025 19:42:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small fix StoreFlatNode::size_of
>
> Thanks for working on this @merykitty! I haven't reviewed this in yet but noticed a build failure:
> 
> 
> [2025-08-04T17:23:31,905Z] /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.cpp: In member function 'void ConnectionGraph::add_final_edges(Node*)':
> [2025-08-04T17:23:31,905Z] /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.cpp:1874:25: error: no matching function for call to 'ConnectionGraph::set_escape_state(PointsToNode*&, PointsToNode::EscapeState, const char [24])'
> [2025-08-04T17:23:31,905Z]  1874 |         set_escape_state(field_value_ptn, PointsToNode::GlobalEscape, "store into a flat field");
> [2025-08-04T17:23:31,905Z]       |         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [2025-08-04T17:23:31,905Z] In file included from /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.cpp:38:
> [2025-08-04T17:23:31,905Z] /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.hpp:434:8: note: candidate: 'void ConnectionGraph::set_escape_state(PointsToNode*, PointsToNode::EscapeState)'
> [2025-08-04T17:23:31,905Z]   434 |   void set_escape_state(PointsToNode* ptn, PointsToNode::EscapeState esc
> [2025-08-04T17:23:31,905Z]       |        ^~~~~~~~~~~~~~~~
> [2025-08-04T17:23:31,905Z] /opt/mach5/mesos/work_dir/slaves/f7f8bd65-a387-4a2b-b519-702f2fefaf87-S170287/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/8d44f2d4-5a02-4ac8-95c1-3a37a1d82705/runs/1b653695-e82f-4430-a41f-d099d041486e/workspace/open/src/hotspot/share/opto/escape.hpp:434:8: note:   candidate expects 2 arguments, 3 provided
> [2025-08-04T17:23:32,241Z] lib/CompileJvm.gmk:172: recipe for target '/opt/mach5/mes...

@TobiHartmann Ah dummy mistake, I missed the `NOT_PRODUCT` guard, fixed it now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1518#issuecomment-3164224324

From forax at univ-mlv.fr  Fri Aug  8 22:53:59 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 9 Aug 2025 00:53:59 +0200 (CEST)
Subject: NPE in javap
Message-ID: <2109714752.9613629.1754693639249.JavaMail.zimbra@univ-eiffel.fr>

This class throw an NPE in javap:

public value class RangeValue {
  private int min;
  private int max;

  public RangeValue(int a, int b) {
    if (a > b) {
      this.min = b;
      this.max = a;
    } else {
      this.min = a;
      this.max = b;
    }
    super();
  }

  public int min() {
    return min;
  }

  public int max() {
    return max;
  }
}


The stacktrace seems to say that ACC_STRICT (on fields) is not supported.

R?mi

---

bash-3.2$ $JAVA_HOME/bin/javap -c -verbose -private target/classes/RangeValue.class
Classfile /Users/forax/git/weather-alert/target/classes/RangeValue.class
  Last modified 9 Aug 2025; size 549 bytes
  SHA-256 checksum 10fcbe0722123c3576c1c9a4814180d3a436510b09c8308083b47b7bfe23d1bd
  Compiled from "RangeValue.java"
public final value class RangeValue
  minor version: 65535
  major version: 69
  flags: (0x0011) ACC_PUBLIC, ACC_FINAL
  this_class: #2                          // RangeValue
  super_class: #11                        // java/lang/Object
  interfaces: 0, fields: 2, methods: 3, attributes: 1
Constant pool:
   #1 = Fieldref           #2.#3          // RangeValue.min:I
   #2 = Class              #4             // RangeValue
   #3 = NameAndType        #5:#6          // min:I
   #4 = Utf8               RangeValue
   #5 = Utf8               min
   #6 = Utf8               I
   #7 = Fieldref           #2.#8          // RangeValue.max:I
   #8 = NameAndType        #9:#6          // max:I
   #9 = Utf8               max
  #10 = Methodref          #11.#12        // java/lang/Object."<init>":()V
  #11 = Class              #13            // java/lang/Object
  #12 = NameAndType        #14:#15        // "<init>":()V
  #13 = Utf8               java/lang/Object
  #14 = Utf8               <init>
  #15 = Utf8               ()V
  #16 = Utf8               (II)V
  #17 = Utf8               Code
  #18 = Utf8               LineNumberTable
  #19 = Utf8               LocalVariableTable
  #20 = Utf8               this
  #21 = Utf8               LRangeValue;
  #22 = Utf8               a
  #23 = Utf8               b
  #24 = Utf8               StackMapTable
  #25 = Utf8               ()I
  #26 = Utf8               SourceFile
  #27 = Utf8               RangeValue.java
{
Error: A serious internal error has occurred: java.lang.NullPointerException
Please file a bug report, and include the following information:
java.lang.NullPointerException
        at java.base/java.util.Objects.requireNonNull(Objects.java:318)
        at java.base/java.lang.reflect.AccessFlag$Location.findInHistory(AccessFlag.java:671)
        at java.base/java.lang.reflect.AccessFlag$Location.flagsMask(AccessFlag.java:707)
        at jdk.jdeps/com.sun.tools.javap.BasicWriter.maskToAccessFlagsReportUnknown(BasicWriter.java:66)
        at jdk.jdeps/com.sun.tools.javap.BasicWriter.flagsReportUnknown(BasicWriter.java:58)
        at jdk.jdeps/com.sun.tools.javap.ClassWriter.writeField(ClassWriter.java:437)
        at jdk.jdeps/com.sun.tools.javap.ClassWriter.writeFields(ClassWriter.java:428)
        at jdk.jdeps/com.sun.tools.javap.ClassWriter.write(ClassWriter.java:261)
        at jdk.jdeps/com.sun.tools.javap.JavapTask.write(JavapTask.java:859)
        at jdk.jdeps/com.sun.tools.javap.JavapTask.writeClass(JavapTask.java:684)
        at jdk.jdeps/com.sun.tools.javap.JavapTask.run(JavapTask.java:628)
        at jdk.jdeps/com.sun.tools.javap.JavapTask.run(JavapTask.java:474)
        at jdk.jdeps/com.sun.tools.javap.Main.main(Main.java:48)

From chen.l.liang at oracle.com  Fri Aug  8 23:01:02 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 8 Aug 2025 23:01:02 +0000
Subject: NPE in javap
In-Reply-To: <2109714752.9613629.1754693639249.JavaMail.zimbra@univ-eiffel.fr>
References: <2109714752.9613629.1754693639249.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <SJ2PR10MB766994E782E5F1C8D6C2D649A22FA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Thanks for the report. This is known as https://bugs.openjdk.org/browse/JDK-8364095, and the proper modeling of preview features is pending on https://github.com/openjdk/jdk/pull/25017.

Chen
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Friday, August 8, 2025 5:53 PM
To: valhalla-dev <valhalla-dev at openjdk.org>
Subject: NPE in javap

This class throw an NPE in javap:

public value class RangeValue {
  private int min;
  private int max;

  public RangeValue(int a, int b) {
    if (a > b) {
      this.min = b;
      this.max = a;
    } else {
      this.min = a;
      this.max = b;
    }
    super();
  }

  public int min() {
    return min;
  }

  public int max() {
    return max;
  }
}


The stacktrace seems to say that ACC_STRICT (on fields) is not supported.

R?mi

---

bash-3.2$ $JAVA_HOME/bin/javap -c -verbose -private target/classes/RangeValue.class
Classfile /Users/forax/git/weather-alert/target/classes/RangeValue.class
  Last modified 9 Aug 2025; size 549 bytes
  SHA-256 checksum 10fcbe0722123c3576c1c9a4814180d3a436510b09c8308083b47b7bfe23d1bd
  Compiled from "RangeValue.java"
public final value class RangeValue
  minor version: 65535
  major version: 69
  flags: (0x0011) ACC_PUBLIC, ACC_FINAL
  this_class: #2                          // RangeValue
  super_class: #11                        // java/lang/Object
  interfaces: 0, fields: 2, methods: 3, attributes: 1
Constant pool:
   #1 = Fieldref           #2.#3          // RangeValue.min:I
   #2 = Class              #4             // RangeValue
   #3 = NameAndType        #5:#6          // min:I
   #4 = Utf8               RangeValue
   #5 = Utf8               min
   #6 = Utf8               I
   #7 = Fieldref           #2.#8          // RangeValue.max:I
   #8 = NameAndType        #9:#6          // max:I
   #9 = Utf8               max
  #10 = Methodref          #11.#12        // java/lang/Object."<init>":()V
  #11 = Class              #13            // java/lang/Object
  #12 = NameAndType        #14:#15        // "<init>":()V
  #13 = Utf8               java/lang/Object
  #14 = Utf8               <init>
  #15 = Utf8               ()V
  #16 = Utf8               (II)V
  #17 = Utf8               Code
  #18 = Utf8               LineNumberTable
  #19 = Utf8               LocalVariableTable
  #20 = Utf8               this
  #21 = Utf8               LRangeValue;
  #22 = Utf8               a
  #23 = Utf8               b
  #24 = Utf8               StackMapTable
  #25 = Utf8               ()I
  #26 = Utf8               SourceFile
  #27 = Utf8               RangeValue.java
{
Error: A serious internal error has occurred: java.lang.NullPointerException
Please file a bug report, and include the following information:
java.lang.NullPointerException
        at java.base/java.util.Objects.requireNonNull(Objects.java:318)
        at java.base/java.lang.reflect.AccessFlag$Location.findInHistory(AccessFlag.java:671)
        at java.base/java.lang.reflect.AccessFlag$Location.flagsMask(AccessFlag.java:707)
        at jdk.jdeps/com.sun.tools.javap.BasicWriter.maskToAccessFlagsReportUnknown(BasicWriter.java:66)
        at jdk.jdeps/com.sun.tools.javap.BasicWriter.flagsReportUnknown(BasicWriter.java:58)
        at jdk.jdeps/com.sun.tools.javap.ClassWriter.writeField(ClassWriter.java:437)
        at jdk.jdeps/com.sun.tools.javap.ClassWriter.writeFields(ClassWriter.java:428)
        at jdk.jdeps/com.sun.tools.javap.ClassWriter.write(ClassWriter.java:261)
        at jdk.jdeps/com.sun.tools.javap.JavapTask.write(JavapTask.java:859)
        at jdk.jdeps/com.sun.tools.javap.JavapTask.writeClass(JavapTask.java:684)
        at jdk.jdeps/com.sun.tools.javap.JavapTask.run(JavapTask.java:628)
        at jdk.jdeps/com.sun.tools.javap.JavapTask.run(JavapTask.java:474)
        at jdk.jdeps/com.sun.tools.javap.Main.main(Main.java:48)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250808/8840db74/attachment.htm>

From coleenp at openjdk.org  Mon Aug 11 17:00:27 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 11 Aug 2025 17:00:27 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v2]
In-Reply-To: <CRCW638JH6jv5NaqAf1pLUrKi3noeyfNh5WEev3I3h0=.011055b0-26cc-4dea-8ea7-68d30fedc158@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
 <CRCW638JH6jv5NaqAf1pLUrKi3noeyfNh5WEev3I3h0=.011055b0-26cc-4dea-8ea7-68d30fedc158@github.com>
Message-ID: <9dOiXpxt3z1lrU4JIY7cm6mK9379WEsGNc8ts4aVj4A=.31317119-ff28-4062-9bf2-ac7a5c2690c3@github.com>

On Wed, 6 Aug 2025 21:48:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
>> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove commented out code.

I don't love having to enumerate all the classes in more than one place, but I also don't want to add another X macro.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1520#issuecomment-3175922640

From heidinga at openjdk.org  Tue Aug 12 20:07:30 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 12 Aug 2025 20:07:30 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v2]
In-Reply-To: <CRCW638JH6jv5NaqAf1pLUrKi3noeyfNh5WEev3I3h0=.011055b0-26cc-4dea-8ea7-68d30fedc158@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
 <CRCW638JH6jv5NaqAf1pLUrKi3noeyfNh5WEev3I3h0=.011055b0-26cc-4dea-8ea7-68d30fedc158@github.com>
Message-ID: <duim3HrXu0SV5y4kzRQQFEuFa3FyjYYjBTgclhBbQ2Y=.3a55d12d-4830-4db7-916b-6813541cf19b@github.com>

On Wed, 6 Aug 2025 21:48:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
>> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove commented out code.

src/hotspot/share/classfile/vmSymbols.cpp line 339:

> 337:   _migrated_class_names[i++] = java_time_chrono_HijrahDate();
> 338:   _migrated_class_names[i++] = java_time_chrono_JapaneseDate();
> 339:   _migrated_class_names[i++] = java_time_chrono_ThaiBuddhistDate();

Should this `assert(i == _migrated_class_names_length);` as a handshake with the size of the set of migrated classes declared in vmSymbols.hpp?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1520#discussion_r2271062996

From heidinga at openjdk.org  Tue Aug 12 20:12:28 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 12 Aug 2025 20:12:28 GMT
Subject: [lworld] RFR: [lworld] Remove redundant DTraceAlloc/Method probes
In-Reply-To: <6YdvMt4v6E_bxLcdjK3toUTUUnCSOQvANFGEVo7tzS4=.d43baad8-eedf-4fd5-a4d8-9477bb085249@github.com>
References: <6YdvMt4v6E_bxLcdjK3toUTUUnCSOQvANFGEVo7tzS4=.d43baad8-eedf-4fd5-a4d8-9477bb085249@github.com>
Message-ID: <OgXO5kMkzfV4uFP7DnZ3iUaNjQtw2jJfPhXO_BJPtUA=.113874ac-288e-4cbe-aecc-484deb951e76@github.com>

On Fri, 1 Aug 2025 12:08:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Looking through this code, I found this discrepancy.  Tested with some tier1 testing.

looks reasonable

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1521#pullrequestreview-3112621101

From coleenp at openjdk.org  Tue Aug 12 20:42:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 12 Aug 2025 20:42:24 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v2]
In-Reply-To: <duim3HrXu0SV5y4kzRQQFEuFa3FyjYYjBTgclhBbQ2Y=.3a55d12d-4830-4db7-916b-6813541cf19b@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
 <CRCW638JH6jv5NaqAf1pLUrKi3noeyfNh5WEev3I3h0=.011055b0-26cc-4dea-8ea7-68d30fedc158@github.com>
 <duim3HrXu0SV5y4kzRQQFEuFa3FyjYYjBTgclhBbQ2Y=.3a55d12d-4830-4db7-916b-6813541cf19b@github.com>
Message-ID: <8giq3ZInPgNNqUMsOyh48QHGxEVSOMfGhR_rjEwIwLE=.af0d9cef-43a0-481f-b554-8a61bb05036c@github.com>

On Tue, 12 Aug 2025 20:04:31 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove commented out code.
>
> src/hotspot/share/classfile/vmSymbols.cpp line 339:
> 
>> 337:   _migrated_class_names[i++] = java_time_chrono_HijrahDate();
>> 338:   _migrated_class_names[i++] = java_time_chrono_JapaneseDate();
>> 339:   _migrated_class_names[i++] = java_time_chrono_ThaiBuddhistDate();
> 
> Should this `assert(i == _migrated_class_names_length);` as a handshake with the size of the set of migrated classes declared in vmSymbols.hpp?

That's a good idea.  I didn't know a better C++ way to initialize these.  I'm sure it exists.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1520#discussion_r2271169394

From coleenp at openjdk.org  Tue Aug 12 20:45:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 12 Aug 2025 20:45:35 GMT
Subject: [lworld] RFR: [lworld] Remove redundant DTraceAlloc/Method probes
In-Reply-To: <6YdvMt4v6E_bxLcdjK3toUTUUnCSOQvANFGEVo7tzS4=.d43baad8-eedf-4fd5-a4d8-9477bb085249@github.com>
References: <6YdvMt4v6E_bxLcdjK3toUTUUnCSOQvANFGEVo7tzS4=.d43baad8-eedf-4fd5-a4d8-9477bb085249@github.com>
Message-ID: <PoVNx-pgPLOsgKkt3JFChmGHLGqZ2b5StQ4yQU1JV1I=.14f99011-007d-4fb2-a494-8bb0ff93810c@github.com>

On Fri, 1 Aug 2025 12:08:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Looking through this code, I found this discrepancy.  Tested with some tier1 testing.

Thanks Dan!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1521#issuecomment-3180959740

From coleenp at openjdk.org  Tue Aug 12 20:45:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 12 Aug 2025 20:45:35 GMT
Subject: [lworld] Integrated: [lworld] Remove redundant DTraceAlloc/Method
 probes
In-Reply-To: <6YdvMt4v6E_bxLcdjK3toUTUUnCSOQvANFGEVo7tzS4=.d43baad8-eedf-4fd5-a4d8-9477bb085249@github.com>
References: <6YdvMt4v6E_bxLcdjK3toUTUUnCSOQvANFGEVo7tzS4=.d43baad8-eedf-4fd5-a4d8-9477bb085249@github.com>
Message-ID: <mjdCsaesLgfjZP6TVbFOPfqUQqZFnSS6MbLrD34_5Y4=.9dccf26e-3620-4b06-a4d3-5edddbaff7f3@github.com>

On Fri, 1 Aug 2025 12:08:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Looking through this code, I found this discrepancy.  Tested with some tier1 testing.

This pull request has now been integrated.

Changeset: 4ce51bf9
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4ce51bf98815703805273fa86162971a9e8c0b9d
Stats:     20 lines in 5 files changed: 0 ins; 17 del; 3 mod

[lworld] Remove redundant DTraceAlloc/Method probes

Reviewed-by: heidinga

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

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

From coleenp at openjdk.org  Tue Aug 12 20:59:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 12 Aug 2025 20:59:46 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v3]
In-Reply-To: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
Message-ID: <E-yDFmX-nedeaLWMwoQj5qYiUgbNS15G1m9PxOH4gF4=.13e81346-0ab3-4978-9abb-6ed5b722995c@github.com>

> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add assert (and test).

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1520/files
  - new: https://git.openjdk.org/valhalla/pull/1520/files/1b85463c..5ac3cac5

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

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

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

From heidinga at openjdk.org  Tue Aug 12 20:59:46 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 12 Aug 2025 20:59:46 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v3]
In-Reply-To: <E-yDFmX-nedeaLWMwoQj5qYiUgbNS15G1m9PxOH4gF4=.13e81346-0ab3-4978-9abb-6ed5b722995c@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
 <E-yDFmX-nedeaLWMwoQj5qYiUgbNS15G1m9PxOH4gF4=.13e81346-0ab3-4978-9abb-6ed5b722995c@github.com>
Message-ID: <rMoXy7FKysu-iXH-YBJMZC7JKnRxlsmOts8-zXBhoYI=.045e3f62-2fab-4659-a4a0-d74079c84c4d@github.com>

On Tue, 12 Aug 2025 20:56:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
>> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assert (and test).

Marked as reviewed by heidinga (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1520#pullrequestreview-3112805233

From coleenp at openjdk.org  Tue Aug 12 21:16:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 12 Aug 2025 21:16:33 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v3]
In-Reply-To: <E-yDFmX-nedeaLWMwoQj5qYiUgbNS15G1m9PxOH4gF4=.13e81346-0ab3-4978-9abb-6ed5b722995c@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
 <E-yDFmX-nedeaLWMwoQj5qYiUgbNS15G1m9PxOH4gF4=.13e81346-0ab3-4978-9abb-6ed5b722995c@github.com>
Message-ID: <5ZHDjLNvHFGzhdVo1CzBKeQRQFO5gtp96Ul_VV3IXJc=.a5fd7830-b607-4407-9ded-296e3c9d9dca@github.com>

On Tue, 12 Aug 2025 20:59:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
>> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assert (and test).

Thanks again, Dan.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1520#issuecomment-3181048451

From coleenp at openjdk.org  Tue Aug 12 21:19:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 12 Aug 2025 21:19:33 GMT
Subject: [lworld] Integrated: 8364483: [lworld] Pre-register migrated classes
 in class loaders
In-Reply-To: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
Message-ID: <l9ZyaiOC7jD3zOBftnAjMM5hG-Uq1t6gu_zW0jYMPT8=.7102c712-7545-40a8-a2d1-257ea6c520bf@github.com>

On Thu, 31 Jul 2025 20:10:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.

This pull request has now been integrated.

Changeset: ed217961
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ed217961906b401d3ef65fa6690f9e3d79a8ddf7
Stats:     129 lines in 5 files changed: 111 ins; 10 del; 8 mod

8364483: [lworld] Pre-register migrated classes in class loaders

Reviewed-by: heidinga

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

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

From duke at openjdk.org  Thu Aug 14 22:03:37 2025
From: duke at openjdk.org (duke)
Date: Thu, 14 Aug 2025 22:03:37 GMT
Subject: [lworld] Withdrawn: 8353236: [lworld] Better documentation for
 Valhalla Unsafe intrinsics
In-Reply-To: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
References: <9c3qoF4kf1D22m6SOm5d_Y5W61lZqZnDTmgkoM-oTNU=.a4de2870-7638-4af0-bb21-26d2ae6045fc@github.com>
Message-ID: <kEOs9t4KKEiC144dho2G4B8FkHBhJNp04dEDr8T-n2E=.1b81c735-a470-4163-8e2b-37da22e39fa0@github.com>

On Wed, 9 Apr 2025 13:18:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch clarifies the meaning of undefined behavior when working with `Unsafe` and specifies the requirements when working with `Unsafe::makePrivateBuffer` and `Unsafe::finishPrivateBuffer`.
> 
> Please take a look and leave your suggestions, thanks a lot.

This pull request has been closed without being integrated.

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

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

From galder at openjdk.org  Fri Aug 15 09:31:47 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Fri, 15 Aug 2025 09:31:47 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call conventions
 for different value class shapes
Message-ID: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>

This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.

**NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.

This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.

The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).

I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:

First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.

The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.

So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.

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

Commit messages:
 - Comment print inlining flag usage
 - Added ForceInline to make sure constructor gets inlined
 - Discovered bug in int[] box
 - Remove hardcoded MyTimeInstant references
 - Add a multi type that works just about
 - Merge branch 'valhalla.lworld' into topic.template-101
 - Comment failing IR test combination
 - Test value class within value class failing but reason unknown
 - Avoid using FieldConstant on uni field test
 - Basic test with multiple fields of boolean
 - ... and 11 more: https://git.openjdk.org/valhalla/compare/67e6bcc4...8adfff69

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

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

From dsimms at openjdk.org  Mon Aug 18 10:15:43 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 18 Aug 2025 10:15:43 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <uLBobbKycM8egaaTmLccBKlvlWFGH3XxlgOA2koC89U=.54358a01-880a-4915-84cc-325fb489d9a7@github.com>

Merge tag 'jdk-25+22' into lworld_merge_jdk_25_22

Added tag jdk-25+22 for changeset 52a5583d

Forward merges (past jdk-25+22):

8357250: assert(shift >= 0 && shift < 4) failed: unexpected compressd klass shift! Vladimir Kozlov* 5/20/25, 10:11_PM
8357143: New test AOTCodeCompressedOopsTest.java fails on platforms without AOT Code Cache support Vladimir Kozlov* 5/19/25, 5:00_PM
8354887: Preserve runtime blobs in AOT code cache Ashutosh Mehra* 5/15/25, 7:18_PM
8356192: Enable AOT code caching only on supported platforms Vladimir Kozlov* 5/12/25, 10:29_PM

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

Commit messages:
 - Merge jdk
 - 8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException
 - 8356407: Part of class verification is skipped in AOT training run
 - 8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer
 - 8244533: Configure should abort on missing short names in Windows
 - 8356126: Duplication handling and optimization of CaptureCallState
 - 8332934: Do loop with continue with subsequent switch leads to incorrect stack maps
 - 8354461: Update tests to disable streaming output for attach tools
 - 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty
 - 8356318: Unexpected VerifyError in AOT training run
 - ... and 127 more: https://git.openjdk.org/valhalla/compare/ed217961...749b1436

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

Changes: https://git.openjdk.org/valhalla/pull/1524/files
  Stats: 24200 lines in 678 files changed: 15564 ins; 5192 del; 3444 mod
  Patch: https://git.openjdk.org/valhalla/pull/1524.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1524/head:pull/1524

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

From dsimms at openjdk.org  Mon Aug 18 12:04:40 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 18 Aug 2025 12:04:40 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <uLBobbKycM8egaaTmLccBKlvlWFGH3XxlgOA2koC89U=.54358a01-880a-4915-84cc-325fb489d9a7@github.com>
References: <uLBobbKycM8egaaTmLccBKlvlWFGH3XxlgOA2koC89U=.54358a01-880a-4915-84cc-325fb489d9a7@github.com>
Message-ID: <7dKn-OhMRMowx4e8rumwX5QGFnk7KJ6-BeOQbXQyU8E=.7f66f236-7e0e-41ac-b827-40d4a702874b@github.com>

On Mon, 18 Aug 2025 10:07:00 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+22' into lworld_merge_jdk_25_22
> 
> Added tag jdk-25+22 for changeset 52a5583d
> 
> Forward merges (past jdk-25+22):
> 
> 8357250: assert(shift >= 0 && shift < 4) failed: unexpected compressd klass shift! Vladimir Kozlov* 5/20/25, 10:11_PM
> 8357143: New test AOTCodeCompressedOopsTest.java fails on platforms without AOT Code Cache support Vladimir Kozlov* 5/19/25, 5:00_PM
> 8354887: Preserve runtime blobs in AOT code cache Ashutosh Mehra* 5/15/25, 7:18_PM
> 8356192: Enable AOT code caching only on supported platforms Vladimir Kozlov* 5/12/25, 10:29_PM

This pull request has now been integrated.

Changeset: 767f79fd
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/767f79fdebb261d7a2f6898fe7a28ede0c4ad79d
Stats:     24200 lines in 678 files changed: 15564 ins; 5192 del; 3444 mod

Merge jdk

Merge jdk-25+22

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

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

From epeter at openjdk.org  Mon Aug 18 14:02:28 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 18 Aug 2025 14:02:28 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call
 conventions for different value class shapes
In-Reply-To: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
References: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
Message-ID: <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>

On Fri, 15 Aug 2025 09:25:32 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.
> 
> **NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.
> 
> This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.
> 
> The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).
> 
> I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:
> 
> First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.
> 
> The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.
> 
> So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.

I know this is in draft state. But I thought I'd have a look since you are trying to use the template framework. That's exciting :)

test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 104:

> 102:         String name() {
> 103:             return "v" + id;
> 104:         }

What is the purpose of the `id` here? Do you ever need it, or just the `name()`?

test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 122:

> 120:         return Template.make("FIELD", (FieldConstant f) -> body(
> 121:             let("FIELD_TYPE", f.type),
> 122:             let("FIELD_VALUE", f.value),

Is this the only place where you use the `value` of `FieldConstant`? Why not just get a `field.type.con()` right here? Maybe I'm missing some part of the design here.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 172:

> 170:         final List<FieldConstant> fields = fieldTypes.stream()
> 171:             .map(fieldType -> FieldConstant.of(fieldId.getAndIncrement(), fieldType))
> 172:             .toList();

Why do you need the constants associated with the fields here?

test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 178:

> 176:             static value class $Box {
> 177:             """,
> 178:             fields(fields),

Wow, I did not know that one could have both a local variable and a method with the same name! Even if Java lets you do it, it seems a bit confusing to me ? Maybe call the method `generateFields`?

test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 210:

> 208:             """
> 209:                 0;
> 210:             }

You should probably rather joint a list of strings with `" + "`, rather than letting the `hashField` add the `+` that may feel a little lost there ?

test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 223:

> 221:             """
> 222:         )).asToken(field);
> 223:     }

Looks like you don't actually need any arguments in the Template here. You are already capturing `field` in the lambda.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 247:

> 245:             return name();
> 246:         }
> 247:     }

We may want to have some sort of array type in the mainline library as well.

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

PR Review: https://git.openjdk.org/valhalla/pull/1522#pullrequestreview-3128424463
PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2282485655
PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2282493883
PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2282462905
PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2282500052
PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2282450236
PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2282440797
PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2282433500

From epeter at openjdk.org  Mon Aug 18 14:02:30 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 18 Aug 2025 14:02:30 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call
 conventions for different value class shapes
In-Reply-To: <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
References: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
 <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
Message-ID: <iWfI14R2VIZ23wtQD7KAbByF7peC6n0ytVJmlta54hU=.a60ef799-88b5-433d-8716-ea21df7f5d50@github.com>

On Mon, 18 Aug 2025 13:47:33 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.
>> 
>> **NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.
>> 
>> This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.
>> 
>> The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).
>> 
>> I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:
>> 
>> First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.
>> 
>> The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.
>> 
>> So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 172:
> 
>> 170:         final List<FieldConstant> fields = fieldTypes.stream()
>> 171:             .map(fieldType -> FieldConstant.of(fieldId.getAndIncrement(), fieldType))
>> 172:             .toList();
> 
> Why do you need the constants associated with the fields here?

And what is the id good for?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2282465670

From epeter at openjdk.org  Mon Aug 18 14:07:28 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 18 Aug 2025 14:07:28 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call
 conventions for different value class shapes
In-Reply-To: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
References: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
Message-ID: <8kWL-NilwULoe0yYILSSRQMwIad2V10GNJ0XuoSpHBg=.b60414ab-0088-4581-bec2-e721c86cedd8@github.com>

On Fri, 15 Aug 2025 09:25:32 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.
> 
> **NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.
> 
> This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.
> 
> The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).
> 
> I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:
> 
> First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.
> 
> The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.
> 
> So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.

And it would be nice to see if we cannot use `DataName` for fields, and `StructuralName` for methods (maybe it is just a small issue with how to use the framework). But it's not a necessity: if you feel like modeling it separately that is also fine.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1522#issuecomment-3197082356

From dsimms at openjdk.org  Mon Aug 18 15:17:05 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 18 Aug 2025 15:17:05 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <CHp6HGu8W6vvPKT8dbFGTVDCUOh78Hgp_QAvEDN7L60=.5a17fc87-83e3-4b34-9349-843b6c9f8f4b@github.com>

Merge tag 'jdk-25+23' into lworld_merge_jdk_25_23

Added tag jdk-25+23 for changeset b8d2bdb4

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

Commit messages:
 - Merge jdk
 - 8355743: G1: Collection set clearing is not recorded as part of "Free Collection Set Time"
 - 8356843: Avoid redundant HashMap.get to obtain old value in Toolkit.setDesktopProperty
 - 8354530: AIX: sporadic unexpected errno when calling setsockopt in Net.joinOrDrop
 - 8356838: AOT incorrectly sets a cached class's loader type to boot
 - 8356693: AOT assembly phase fails with -javaagent
 - 8356971: [JVMCI] Export VM_Version::supports_avx512_simd_sort to JVMCI compiler
 - 8347608: Optimize Java implementation of ML-KEM
 - 8343739: Test java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java failed: Wrong extended key code
 - 8356588: Some nsk/jdi tests can fetch ThreadReference from static field in the debuggee: part 3
 - ... and 130 more: https://git.openjdk.org/valhalla/compare/767f79fd...dd990d89

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

Changes: https://git.openjdk.org/valhalla/pull/1525/files
  Stats: 22983 lines in 975 files changed: 12323 ins; 5808 del; 4852 mod
  Patch: https://git.openjdk.org/valhalla/pull/1525.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1525/head:pull/1525

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

From vromero at openjdk.org  Mon Aug 18 18:19:19 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 18 Aug 2025 18:19:19 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase
Message-ID: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>

Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr

TIA

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

Commit messages:
 - more changes
 - refactoring
 - test changes
 - minor fixes
 - restoring removed class files
 - additional changes
 - additional changes
 - Merge branch 'lworld' into JDK-8359370-v2
 - additional experiments
 - removing all checks from Resolve

Changes: https://git.openjdk.org/valhalla/pull/1523/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359370
  Stats: 375 lines in 23 files changed: 238 ins; 89 del; 48 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From liach at openjdk.org  Mon Aug 18 18:19:20 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Aug 2025 18:19:20 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <MmjEpRUPjkAFzYYZqM3EQK8OYMUiHECa1JvFGUqxwD4=.bb59f6a6-d7c8-4e7e-a032-1f962e4b2175@github.com>

On Fri, 15 Aug 2025 21:38:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1259:

> 1257:                     for (JCTree stat : tree.body.stats) {
> 1258:                         prologueCode.add(stat);
> 1259:                         // gather all the stats in the body until a `super` or `this` invocation is found

I think this comment should explain that super/this invocation is included because its arguments are restricted too.

test/langtools/tools/javac/SuperInit/EarlyIndirectOuterCapture.java line 21:

> 19:         class InnerInnerOuter extends EarlyIndirectOuterCapture {   // not accessible
> 20:             InnerInnerOuter() {
> 21:                 super(new InnerSuperclass() { }); // should this be accepted?, InnerSuperclass is not an inner class of InnerInnerOuter

Probably yes, I think our agreement last time is that local/anonymous classes' captures, including the "outer this", are synthetic.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2280164233
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2280171982

From vromero at openjdk.org  Mon Aug 18 18:19:20 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 18 Aug 2025 18:19:20 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <TsvMQS42k_i6vlPaQdgtbzb41OVn3p3FOjyd6Uc5H0k=.8e5918d5-0e5d-4ce9-b9cd-5e4b223b42bc@github.com>

On Fri, 15 Aug 2025 21:38:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA

test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview1.java line 5:

> 3:  * @bug 8334258
> 4:  * @summary Disallow early assignment if FLEXIBLE_CONSTRUCTORS preview feature is not enabled
> 5:  * @compile/fail/ref=EarlyAssignmentNoPreview1.out --release 24 -XDrawDiagnostics EarlyAssignmentNoPreview1.java

this test along with EarlyAssigmentNoPreview 2 and 3 are failing. But the idea is to integrate this PR after the code for flexible constructor bodies have been merged into lworld, which should make these 3 tests pass

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2283113135

From rriggs at openjdk.org  Tue Aug 19 02:10:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Aug 2025 02:10:53 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v3]
In-Reply-To: <E-yDFmX-nedeaLWMwoQj5qYiUgbNS15G1m9PxOH4gF4=.13e81346-0ab3-4978-9abb-6ed5b722995c@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
 <E-yDFmX-nedeaLWMwoQj5qYiUgbNS15G1m9PxOH4gF4=.13e81346-0ab3-4978-9abb-6ed5b722995c@github.com>
Message-ID: <pOoNETD2BGKhEhsuS9OtT1_P1lZJVFw8OSMzYzhjplw=.9354a77c-2c8c-4e82-a7a3-85ed181ab738@github.com>

On Tue, 12 Aug 2025 20:59:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change preloads and preregisters all classes in the migrated classes lists, in all class loaders.
>> Tested with tier1 locally and with -XX:+PrintSystemDictionaryAtExit.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assert (and test).

The official list of migrated classes is in `make/modules/java.base/gensrc/GensrcValueClasses.gmk`.
How are all these copies of the list of files kept in sync?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1520#issuecomment-3198974709

From dsimms at openjdk.org  Tue Aug 19 06:19:08 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 19 Aug 2025 06:19:08 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <CHp6HGu8W6vvPKT8dbFGTVDCUOh78Hgp_QAvEDN7L60=.5a17fc87-83e3-4b34-9349-843b6c9f8f4b@github.com>
References: <CHp6HGu8W6vvPKT8dbFGTVDCUOh78Hgp_QAvEDN7L60=.5a17fc87-83e3-4b34-9349-843b6c9f8f4b@github.com>
Message-ID: <OMF-WQ0KOtUInxaWNyFWa1VU2qVV_EhGZ3foJM8DiNM=.36c6e6dd-4519-4c74-8adf-d6699e2cab8a@github.com>

On Mon, 18 Aug 2025 15:08:43 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+23' into lworld_merge_jdk_25_23
> 
> Added tag jdk-25+23 for changeset b8d2bdb4

This pull request has now been integrated.

Changeset: e24379fa
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e24379fac04e5f0be38e47ffe7c9ecfbab06c5cf
Stats:     22983 lines in 975 files changed: 12323 ins; 5808 del; 4852 mod

Merge jdk

Merge jdk-25+23

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

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

From dsimms at openjdk.org  Tue Aug 19 09:13:50 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 19 Aug 2025 09:13:50 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <AzmgVtpWswQYLWxRRSRlDe8aJv7gHupLLBTkgaQLoIc=.784ff658-31c0-4618-8b87-72085f695cb7@github.com>

Merge tag 'jdk-25+24' into lworld_merge_jdk_25_24

Added tag jdk-25+24 for changeset b685ea54

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

Commit messages:
 - Merge jdk
 - 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned
 - 8357063: Document preconditions for DecimalDigits methods
 - 8353504: CDS archives are not found when JVM is in non-variant location
 - 8357503: gcbasher fails with java.lang.IllegalArgumentException: Unknown constant pool type
 - 8351993: VectorShuffle access to and from MemorySegments
 - 8357173: Split jtreg test group jdk tier3
 - 8345826: Do not automatically resolve jdk.internal.vm.ci when libgraal is used
 - 8356904: Skip jdk/test/lib/process/TestNativeProcessBuilder on static-jdk
 - 8351907: [XWayland] [OL10] Robot.mousePress() is delivered to wrong place
 - ... and 99 more: https://git.openjdk.org/valhalla/compare/e24379fa...2c8658ce

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

Changes: https://git.openjdk.org/valhalla/pull/1526/files
  Stats: 57110 lines in 787 files changed: 33300 ins; 19672 del; 4138 mod
  Patch: https://git.openjdk.org/valhalla/pull/1526.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1526/head:pull/1526

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

From vromero at openjdk.org  Tue Aug 19 13:27:19 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 19 Aug 2025 13:27:19 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v2]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <1pRLKaeeWll9tp_-MLgLSxSvbhMx8tRs_EEVYUFMyFE=.b878fd95-8124-4471-b071-42024782e19f@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  renaming methods in LocalProxyVarGen

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/399bd510..841bfc04

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

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

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

From heidinga at openjdk.org  Tue Aug 19 13:35:47 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 19 Aug 2025 13:35:47 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders [v3]
In-Reply-To: <pOoNETD2BGKhEhsuS9OtT1_P1lZJVFw8OSMzYzhjplw=.9354a77c-2c8c-4e82-a7a3-85ed181ab738@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
 <E-yDFmX-nedeaLWMwoQj5qYiUgbNS15G1m9PxOH4gF4=.13e81346-0ab3-4978-9abb-6ed5b722995c@github.com>
 <pOoNETD2BGKhEhsuS9OtT1_P1lZJVFw8OSMzYzhjplw=.9354a77c-2c8c-4e82-a7a3-85ed181ab738@github.com>
Message-ID: <Ar3gwLa84QOUhbpNDG8ix-FCdiL0G3aJ_bTVmmF1C2c=.7beffa1d-d0fc-4433-8379-79034b9763d0@github.com>

On Tue, 19 Aug 2025 02:07:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The official list of migrated classes is in `make/modules/java.base/gensrc/GensrcValueClasses.gmk`.
> How are all these copies of the list of files kept in sync?

This is a temporary measure to make up for classfiles that don't have a `LoadedDescriptors` attribute yet.  Those classes - in user class loaders - won't "know" at link time that the box classes have migrated to be values and therefore won't benefit from the calling convention optimizations.  This PR lets us make those classloaders aware of the changed nature of the boxing classes early and ensures they get the benefits of Valhalla.  The other migrated classes are included because "why not" and so keeping the lists in sync isn't a priority.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1520#issuecomment-3200789475

From vromero at openjdk.org  Tue Aug 19 20:54:29 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 19 Aug 2025 20:54:29 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v3]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <ESTLizQMw8xIgHeVn-gJ0S1qEpPgkmsSxCdGm-b7WdQ=.0b8845b3-b42c-4bb8-92f1-cb994fb650af@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - merge with lworld
 - renaming methods in LocalProxyVarGen
 - more changes
 - refactoring
 - test changes
 - minor fixes
 - restoring removed class files
 - additional changes
 - additional changes
 - Merge branch 'lworld' into JDK-8359370-v2
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/e24379fa...48f12d20

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

Changes: https://git.openjdk.org/valhalla/pull/1523/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=02
  Stats: 396 lines in 21 files changed: 238 ins; 91 del; 67 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From galder at openjdk.org  Wed Aug 20 03:59:03 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 20 Aug 2025 03:59:03 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call
 conventions for different value class shapes
In-Reply-To: <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
References: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
 <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
Message-ID: <RSZ8bmCerrzgITr76lxuZnN4QfRZVXbK8ANNeOqlJUc=.c885bfa7-895b-4f3f-9dbc-7871dcfd0cff@github.com>

On Mon, 18 Aug 2025 13:42:10 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.
>> 
>> **NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.
>> 
>> This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.
>> 
>> The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).
>> 
>> I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:
>> 
>> First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.
>> 
>> The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.
>> 
>> So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 223:
> 
>> 221:             """
>> 222:         )).asToken(field);
>> 223:     }
> 
> Looks like you don't actually need any arguments in the Template here. You are already capturing `field` in the lambda.

True.

When to use arguments vs when to just capture variables...etc has been something I've been struggling with.

Initially I didn't think too much about it, but when I started trying to use `dataNames` lambdas and started giving failures, then I tried to move towards arguments and as you can see there are places where things are mixed up.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2286918618

From galder at openjdk.org  Wed Aug 20 04:03:46 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 20 Aug 2025 04:03:46 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call
 conventions for different value class shapes
In-Reply-To: <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
References: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
 <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
Message-ID: <NOstJkbwx9SKAcS6N74XcVRljLNO14vvQJ3tScGtr2Y=.8728a8cd-bddf-4098-a9eb-8c344a48abf3@github.com>

On Mon, 18 Aug 2025 13:44:31 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.
>> 
>> **NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.
>> 
>> This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.
>> 
>> The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).
>> 
>> I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:
>> 
>> First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.
>> 
>> The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.
>> 
>> So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 210:
> 
>> 208:             """
>> 209:                 0;
>> 210:             }
> 
> You should probably rather joint a list of strings with `" + "`, rather than letting the `hashField` add the `+` that may feel a little lost there ?

True. I had in my mind that I needed to return a List of `TemplateToken` but I guess I can just convert those to string and join then for easier to read code.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2286923443

From galder at openjdk.org  Wed Aug 20 04:13:52 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 20 Aug 2025 04:13:52 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call
 conventions for different value class shapes
In-Reply-To: <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
References: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
 <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
Message-ID: <Hc8nv7H4P_hscCOO-aPtxZoj2e8IS8yFKInxzXVwIV0=.4ef675ac-0a3f-472d-a379-070a45b6f44a@github.com>

On Mon, 18 Aug 2025 13:53:36 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This is a **very early draft** for a template-based test (temporarily called `TestOne`) that addresses some of the requirements of JDK-8364421.
>> 
>> **NOTE**: the PR also includes the commits to add template-based testing framework since that's not yet in `lworld`, and also adds https://github.com/openjdk/valhalla/commit/68e4a60c1ff62f4d0b8b31cb0bd729f1d67748e2 so that Boolean types are supported in `checkEQ`.
>> 
>> This test has surfaced [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590) bug, and as I focus on that bug, I thought it'd be a good moment to share what I've done so far with the test and get some feedback.
>> 
>> The test is very simple so far, creating value classes that contain a single field, testing for each of the primitive types. I also started testing having this field be a primitive array type and that's when I encountered [JDK-8365590](https://bugs.openjdk.org/browse/JDK-8365590).
>> 
>> I've tried to create value classes that had multiple fields, but I've hit some obstacles here so I've just added a very basic test:
>> 
>> First, I tried to use data names to create value classes that would have N fields, and have these fields initialized via a constructor, but I couldn't get it to work. So the example present in the test uses external data structures to keep track of these fields, their types, their initial values...etc. I have discussed these issues in more detail with @chhagedorn and bounced some ideas of how to improve data names, but these need to be discussed in more detail.
>> 
>> The second obstacle I found is related to nuances on when value classes with multiple fields will be scalarized, when these classes are part of another value classes. Depending on the combination of fields, they can be considered that they can be flattened or not, so handling this in a test like this would need to track the sizes of each fields, add them up, and decide whether the test should be positive on scalarization or negative. I traced this logic to `FieldLayoutBuilder::compute_inline_class_layout` and the way `_nullable_layout_size_in_bytes` is then used to decide whether to flatten or not. I've been using `PrintFieldLayout` option to see what nullable flat layout values each of these box instances would have.
>> 
>> So, given these complexities of multiple fields, I'm might keep `TestOne` (note: name is temporary) focused on value classes with a single field. And then have another test with multiple fields.
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 104:
> 
>> 102:         String name() {
>> 103:             return "v" + id;
>> 104:         }
> 
> What is the purpose of the `id` here? Do you ever need it, or just the `name()`?

See my comment above

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 122:
> 
>> 120:         return Template.make("FIELD", (FieldConstant f) -> body(
>> 121:             let("FIELD_TYPE", f.type),
>> 122:             let("FIELD_VALUE", f.value),
> 
> Is this the only place where you use the `value` of `FieldConstant`? Why not just get a `field.type.con()` right here? Maybe I'm missing some part of the design here.

See above comment

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2286932563
PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2286932928

From galder at openjdk.org  Wed Aug 20 04:13:52 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 20 Aug 2025 04:13:52 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call
 conventions for different value class shapes
In-Reply-To: <iWfI14R2VIZ23wtQD7KAbByF7peC6n0ytVJmlta54hU=.a60ef799-88b5-433d-8716-ea21df7f5d50@github.com>
References: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
 <QVvJZJ6T6DUWfTw8FPSaoZNpbFPh5x5TpgvbqprB7qs=.7afb8923-12bb-4a93-97e3-915df5d2f16e@github.com>
 <iWfI14R2VIZ23wtQD7KAbByF7peC6n0ytVJmlta54hU=.a60ef799-88b5-433d-8716-ea21df7f5d50@github.com>
Message-ID: <572iNh8QzijuvYYHc7oiXZur6Y5zNapIUG_O5z_VBVc=.47fbaeeb-7877-4732-9c49-6c2c1a5fef6f@github.com>

On Mon, 18 Aug 2025 13:48:16 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/valhalla/inlinetypes/templating/TestOne.java line 172:
>> 
>>> 170:         final List<FieldConstant> fields = fieldTypes.stream()
>>> 171:             .map(fieldType -> FieldConstant.of(fieldId.getAndIncrement(), fieldType))
>>> 172:             .toList();
>> 
>> Why do you need the constants associated with the fields here?
>
> And what is the id good for?

`FieldConstant` is just quick way that I used to model what I couldn't model with `dataNames` in order to construct a `Box` type with 2 boolean fields.

The constants are leftover from a previous approach where I was trying to use them to both initialise a field with it, and then use it as the expected result verify that the test result was the constant that I had assigned in the field. Later on I found there are other ways to compute the expected result in ways that I don't have to track the value around, e.g. setting it to a static gold value or similar.

The id was just a way to number the fields that I added before I recognised I could use the `$` sign. I'm not sure if I still need it even though I'm not using dataNames for multi-field box types but I'll double check.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1522#discussion_r2286931753

From galder at openjdk.org  Wed Aug 20 04:17:44 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 20 Aug 2025 04:17:44 GMT
Subject: [lworld] RFR: [DRAFT] [lworld] Test scalarization and call
 conventions for different value class shapes
In-Reply-To: <8kWL-NilwULoe0yYILSSRQMwIad2V10GNJ0XuoSpHBg=.b60414ab-0088-4581-bec2-e721c86cedd8@github.com>
References: <u0OApNf-SAutfw0v4UNuL-H48SvSRZa9zzXJn510Myw=.92d34a05-cb8e-4995-afda-a3d045576c12@github.com>
 <8kWL-NilwULoe0yYILSSRQMwIad2V10GNJ0XuoSpHBg=.b60414ab-0088-4581-bec2-e721c86cedd8@github.com>
Message-ID: <NqfQY4XaziJXlJrppkTrslmLAlbPU6StJDd5L-n4H6Q=.969143af-6d36-4efe-8037-9ffaa242ad12@github.com>

On Mon, 18 Aug 2025 14:04:41 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> And it would be nice to see if we cannot use DataName for fields, and StructuralName for methods (maybe it is just a small issue with how to use the framework). But it's not a necessity: if you feel like modeling it separately that is also fine.

I did try to use data names to fields and I have been able to use them fine for a single field box types, see `uniFieldTest`. I struggled to use data names for multi field box types, particularly when you have multiple fields of the same type, e.g. 2 boolean fields.

As for structural names, I did not explore them yet. I will look into them and see how they can help here.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1522#issuecomment-3204127028

From dsimms at openjdk.org  Wed Aug 20 07:33:42 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 20 Aug 2025 07:33:42 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <AzmgVtpWswQYLWxRRSRlDe8aJv7gHupLLBTkgaQLoIc=.784ff658-31c0-4618-8b87-72085f695cb7@github.com>
References: <AzmgVtpWswQYLWxRRSRlDe8aJv7gHupLLBTkgaQLoIc=.784ff658-31c0-4618-8b87-72085f695cb7@github.com>
Message-ID: <2omfB6kj11icgPPQXYtudulM-ZSuYsb90nzpL0HBkXI=.87a22ce5-619c-4f6c-9576-93b657576d50@github.com>

> Merge tag 'jdk-25+24' into lworld_merge_jdk_25_24
> 
> Added tag jdk-25+24 for changeset b685ea54

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

  this not available

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1526/files
  - new: https://git.openjdk.org/valhalla/pull/1526/files/2c8658ce..7bd8cafc

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

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

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

From dsimms at openjdk.org  Wed Aug 20 07:33:44 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 20 Aug 2025 07:33:44 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <AzmgVtpWswQYLWxRRSRlDe8aJv7gHupLLBTkgaQLoIc=.784ff658-31c0-4618-8b87-72085f695cb7@github.com>
References: <AzmgVtpWswQYLWxRRSRlDe8aJv7gHupLLBTkgaQLoIc=.784ff658-31c0-4618-8b87-72085f695cb7@github.com>
Message-ID: <XUjKFnFHOIrFit17EXBEfpV61zxwNnLMLc4se5SUGVg=.2fadc645-3a31-4bcc-99a0-125001afee88@github.com>

On Tue, 19 Aug 2025 09:02:30 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+24' into lworld_merge_jdk_25_24
> 
> Added tag jdk-25+24 for changeset b685ea54

This pull request has now been integrated.

Changeset: af03598e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/af03598eb81aee17c0657347fd6439475ca8f7ee
Stats:     57112 lines in 788 files changed: 33300 ins; 19673 del; 4139 mod

Merge jdk

Merge jdk-25+24

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

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

From dsimms at openjdk.org  Wed Aug 20 08:47:24 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 20 Aug 2025 08:47:24 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <jiwGmZjQz53rwxLzFKezByWplUoAsQJNRlbr5RjCQn8=.4cd66a95-7749-4f5b-98e2-d5c2673a112e@github.com>

Merge tag 'jdk-25+25' into lworld_merge_jdk_25_25

Added tag jdk-25+25 for changeset 2e8b195a

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

Commit messages:
 - Merge jdk
 - 8354078: Implement JEP 521: Generational Shenandoah
 - 8354944: Remove unnecessary PartiallyOrderedSet.nodes
 - 8357912: (fs) Remove @since tag from java.nio.file.FileSystems.newFileSystem(Path,ClassLoader)
 - 8357145: CRC/Inflater/Deflater/Adler32 methods that take a ByteBuffer throw UOE if backed by shared memory segment
 - 8357268: Use JavaNioAccess.getBufferAddress rather than DirectBuffer.address()
 - 8356888: (fs) FileSystems.newFileSystem that take an env must specify IllegalArgumentException
 - 8357800: Initialize JvmtiThreadState bool fields with bool literals
 - 8357801: Parallel: Remove deprecated PSVirtualSpace methods
 - 8357842: PandocFilter misses copyright header
 - ... and 83 more: https://git.openjdk.org/valhalla/compare/af03598e...69ee3d57

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

Changes: https://git.openjdk.org/valhalla/pull/1528/files
  Stats: 17191 lines in 481 files changed: 10591 ins; 3970 del; 2630 mod
  Patch: https://git.openjdk.org/valhalla/pull/1528.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1528/head:pull/1528

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

From mhaessig at openjdk.org  Wed Aug 20 16:31:20 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 20 Aug 2025 16:31:20 GMT
Subject: [lworld] RFR: 8360851: [lworld] missing # {method} comment in assembly
 dumping
Message-ID: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>

`CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:

https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796

This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.

Testing:
 - [ ] tier1,tier2,tier3,valhalla-comp-stress

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

Commit messages:
 - Add regression test
 - Fix printing of method tag

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

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

From vromero at openjdk.org  Wed Aug 20 20:57:33 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 20 Aug 2025 20:57:33 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v4]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <UuUOEcIh3Z5FXa4mK4O200zJYHXlXH5-GdhY3FV7PSI=.ab18b262-f470-4b50-830b-0d5f06feec09@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  bug fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/48f12d20..bfd0cdac

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

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

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

From vromero at openjdk.org  Thu Aug 21 01:56:25 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 21 Aug 2025 01:56:25 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v5]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <v8GHTssO511cQC8u5odbGJZCgiNMDLQpajSHwup8bms=.fd687067-b15e-4be6-982c-a08e073a1ce7@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  another bug fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/bfd0cdac..af7939a3

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

  Stats: 27 lines in 7 files changed: 13 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From dsimms at openjdk.org  Thu Aug 21 05:49:43 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 21 Aug 2025 05:49:43 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <jiwGmZjQz53rwxLzFKezByWplUoAsQJNRlbr5RjCQn8=.4cd66a95-7749-4f5b-98e2-d5c2673a112e@github.com>
References: <jiwGmZjQz53rwxLzFKezByWplUoAsQJNRlbr5RjCQn8=.4cd66a95-7749-4f5b-98e2-d5c2673a112e@github.com>
Message-ID: <qaCw-nYBqXoX21zQeeQHLD9QFGy4Tf1F2rIcAC81Tu0=.1ec6f041-9b29-41b4-b225-d75c746bf8aa@github.com>

> Merge tag 'jdk-25+25' into lworld_merge_jdk_25_25
> 
> Added tag jdk-25+25 for changeset 2e8b195a

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

  Adjust Testing

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1528/files
  - new: https://git.openjdk.org/valhalla/pull/1528/files/69ee3d57..dada4480

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

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

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

From dsimms at openjdk.org  Thu Aug 21 05:53:21 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 21 Aug 2025 05:53:21 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <jiwGmZjQz53rwxLzFKezByWplUoAsQJNRlbr5RjCQn8=.4cd66a95-7749-4f5b-98e2-d5c2673a112e@github.com>
References: <jiwGmZjQz53rwxLzFKezByWplUoAsQJNRlbr5RjCQn8=.4cd66a95-7749-4f5b-98e2-d5c2673a112e@github.com>
Message-ID: <pPv6yI2kVvqM9qVA8w4YfxrY6XB4ZESWSv0cuyFecZI=.1500c235-cefa-4a3f-9d40-68480e886d80@github.com>

On Wed, 20 Aug 2025 08:37:39 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+25' into lworld_merge_jdk_25_25
> 
> Added tag jdk-25+25 for changeset 2e8b195a

This pull request has now been integrated.

Changeset: 62e90b5d
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/62e90b5d268b726adb54b8c8816531de5bda868d
Stats:     17199 lines in 481 files changed: 10599 ins; 3970 del; 2630 mod

Merge jdk

Merge jdk-25+25

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

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

From mhaessig at openjdk.org  Thu Aug 21 11:26:54 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 21 Aug 2025 11:26:54 GMT
Subject: [lworld] RFR: 8360851: [lworld] missing # {method} comment in
 assembly dumping [v2]
In-Reply-To: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
References: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
Message-ID: <gnIAJpYp5Zw33iTbanCE4D8bxR67hQK5ZChdvUuigBM=.893bf7be-4421-4f78-b511-4481253a313c@github.com>

> `CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:
> 
> https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796
> 
> This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.
> 
> Testing:
>  - [x] tier1,tier2,tier3,valhalla-comp-stress

Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:

  Problem list regression test for ZGC on aarch64

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1529/files
  - new: https://git.openjdk.org/valhalla/pull/1529/files/32d097bd..4fd05be3

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

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

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

From vromero at openjdk.org  Thu Aug 21 16:58:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 21 Aug 2025 16:58:57 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v6]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <n4dU-4fg3zAW_IV9HgABRDabfgcJW6sgSSQduLdksWs=.93d6c5fd-acff-4bcc-8f9d-e8753bc6d1ab@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  refactorings

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/af7939a3..e55b897a

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

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

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

From dsimms at openjdk.org  Fri Aug 22 09:10:43 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 22 Aug 2025 09:10:43 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <dApbB4UDKy1YGeZ5n49yN8rE6MZokDBsxukTCjvHAHU=.ce275527-fc3e-435a-9858-ffacafbceddb@github.com>

Merge tag 'jdk-25+26' into lworld_merge_jdk_25_26

Added tag jdk-25+26 for changeset c59e44a7

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

Commit messages:
 - Merge jdk
 - 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual
 - 8337666: AArch64: SHA3 GPR intrinsic
 - 8358689: test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build  after JDK-8351594
 - 8358633: Test ThreadPoolExecutorTest::testTimedInvokeAnyNullTimeUnit is broken by JDK-8347491
 - 8358590: JFR: Include min and max in MethodTiming event
 - 8351594: JFR: Rate-limited sampling of Java events
 - 8349369: test/docs/jdk/javadoc/doccheck/checks/jdkCheckLinks.java did not report on missing man page files
 - 8356633: Incorrect use of {@link} in jdk.jshell
 - 8357962: JFR Cooperative Sampling reveals inconsistent interpreter frames as part of JVMTI PopFrame
 - ... and 207 more: https://git.openjdk.org/valhalla/compare/62e90b5d...468e8229

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

Changes: https://git.openjdk.org/valhalla/pull/1530/files
  Stats: 69036 lines in 1073 files changed: 42205 ins; 16729 del; 10102 mod
  Patch: https://git.openjdk.org/valhalla/pull/1530.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1530/head:pull/1530

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

From mchevalier at openjdk.org  Fri Aug 22 14:16:16 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 22 Aug 2025 14:16:16 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances
Message-ID: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>

First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.

# Diagnostic

According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.

The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.

In the original example:

public value class MyNumber {
    private long d0;
    private MyNumber(long d0) { this.d0 = d0; }
    public MyNumber add(long v) { return new MyNumber(d0 + v); }

    private static void loop() {
        MyNumber dec = new MyNumber(123);
        for (int i = 0; i < 1_000_000_000; ++i) {
            dec = dec.add(i);
        }
    }

    public static void main(String[] args) {
        for (int i = 0; i < 10; ++i) {
            loop();
        }
    }
}

OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.

# Solution

Overall, the solution requires to improve our detection of early larval values. Since we keep parsing as-is, let's do that in `ciTypeFlow`. The logic is quite simple: `ciInlineKlass` can be wrapped in `ciWrapper` to mark when they are known to be non-null. We extend `ciWrapper` to also be able to tell when a value is early larval (which also implies non-null since early larval means that `new` happened).

Then, it's almost a state machine! How is "early larval" introduced:
- `new` bytecode
- receiver of a constructor

How larval is removed:
- call to constructor

Other ways to obtain values are safe (I've experimented and it seems the verifier was keeping me from doing something bad):
- returned values are not early larval
- parameters are not early larval
- receiver of everything but constructor are not early larval

And other guarantees:
- calling twice the constructor is not legal
- merging paths with inconsistent state (early larval vs. unrestricted) is also disallowed

Let's detail how to remove the early larval state on a `ciInlineKlass`. When invoking a method on a receiver, we know that the receiver is not early larval after: either it's a constructor (which initialize the object), or it's a regular method, and the verifier makes sure the receiver was already not early larval before. The tricky part is to remove the larval state on all the copies of the reference: when doing something such as

new SomeValueClass
dup
dup
astore 1
invokespecial <init>

we still have a copy of the same reference in local 1 and on the stack. All of them now refers to a non-larval value. To take that into account, one must scan all the cells (locals and stack), and remove the early larval wrapper to all the types sharing the same ident  (see `void ciBaseObject::set_ident(uint id)` and `void ciObjectFactory::init_ident_of(ciBaseObject* obj)`). That is enough since early larval values cannot be contained in another object (since we can't make use of them before reaching unrestricted state, see also [Flexible Constructor Bodies](https://openjdk.org/jeps/513)).

Another trick is about the super constructor invocation in a constructor: is that different from a constructor invocation outside of a constructor. Well yes, but actually no:
- outside a constructor, a constructor invocation leaves the object initialized
- in a constructor, a constructor invocation doesn't make the object initialized because the all constructor is not done. But, calling the base class' constructor ensures that `Object.<init>` is being called, climbing up the hierarchy. Once `Object`'s constructor has been reached, the object is late larval.

In both case, after a constructor invocation, the object is unrestricted (late larval or initialized), and in the case of a value object, immutable, so scalarizable, which is what matters here.

The case of an abstract value class needs a bit of hack. An abstract value class is an `InstanceKlass` and a `ciInstanceKlass`, so we should take care of not doing the aforementioned logic only for `ciInlineKlass`, but also for `ciInstanceKlass` that are not identity classes.

# Tests

Testing is not quite easy. First, there is a microbenchmark.

Running

make test TEST="micro:org.openjdk.bench.valhalla.loops.osr.LarvalDetectionAboveOSR" CONF_NAME=linux-x64

before the fix would give

Iteration   1: 1874.498 ms/op
Iteration   2: 1662.409 ms/op
Iteration   3: 204.573 ms/op
Iteration   4: 201.177 ms/op
Iteration   5: 201.526 ms/op
Iteration   6: 200.718 ms/op
Iteration   7: 198.127 ms/op
Iteration   8: 200.535 ms/op
Iteration   9: 201.079 ms/op
Iteration  10: 203.341 ms/op

and now

Iteration   1: 212.941 ms/op
Iteration   2: 225.214 ms/op
Iteration   3: 204.319 ms/op
Iteration   4: 199.884 ms/op
Iteration   5: 201.875 ms/op
Iteration   6: 202.331 ms/op
Iteration   7: 200.829 ms/op
Iteration   8: 200.794 ms/op
Iteration   9: 200.428 ms/op
Iteration  10: 203.278 ms/op

That's better! For this microbench, we need to do everything that we shouldn't usually do: no warmup, single measure... Indeed, as soon as we do more than OSR, the effect disappear.

Otherwise, it's nice to see that the allocation is not there anymore in OSR. That could be an IR framework test, but alas, IR framework doesn't support OSR so easily. The test is thus running a subprocess and parsing the output quite basically. This should be ported to an IR test once the IR framework supports OSR.

Thanks,
Marc

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

Commit messages:
 - cleanup
 - abstract value class
 - Adjust microbench + parameters are never early larval
 - Less printing for testing
 - Trying
 - working....

Changes: https://git.openjdk.org/valhalla/pull/1531/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1531&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361352
  Stats: 424 lines in 12 files changed: 386 ins; 18 del; 20 mod
  Patch: https://git.openjdk.org/valhalla/pull/1531.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1531/head:pull/1531

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

From mchevalier at openjdk.org  Fri Aug 22 14:37:23 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 22 Aug 2025 14:37:23 GMT
Subject: [lworld] RFR: ProblemList MemoryAccessProviderTest.java and
 TestHotSpotResolvedJavaField.java
Message-ID: <Vf6lqq125Sm_RI-DdmSg92hEYYMh7laQIohty4QltpI=.b0569b35-404d-47cf-8723-f5b7cbd3f672@github.com>

https://bugs.openjdk.org/browse/JDK-8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution"

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

Commit messages:
 - ProblemList-8350208

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

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

From mchevalier at openjdk.org  Fri Aug 22 14:46:06 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 22 Aug 2025 14:46:06 GMT
Subject: [lworld] Integrated: ProblemList MemoryAccessProviderTest.java and
 TestHotSpotResolvedJavaField.java
In-Reply-To: <Vf6lqq125Sm_RI-DdmSg92hEYYMh7laQIohty4QltpI=.b0569b35-404d-47cf-8723-f5b7cbd3f672@github.com>
References: <Vf6lqq125Sm_RI-DdmSg92hEYYMh7laQIohty4QltpI=.b0569b35-404d-47cf-8723-f5b7cbd3f672@github.com>
Message-ID: <Hzw3e60EoQbKDrNDDN-lYkBQwvjZsQFjo3jI1yx6GVc=.573c4922-a0b3-415b-b15d-97819ac587c8@github.com>

On Fri, 22 Aug 2025 14:31:25 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution"

This pull request has now been integrated.

Changeset: 2ea7f81d
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2ea7f81d44b44473a2ef2b9406565d9b58c46a55
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

ProblemList MemoryAccessProviderTest.java and TestHotSpotResolvedJavaField.java

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

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

From thartmann at openjdk.org  Fri Aug 22 14:46:06 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 22 Aug 2025 14:46:06 GMT
Subject: [lworld] RFR: ProblemList MemoryAccessProviderTest.java and
 TestHotSpotResolvedJavaField.java
In-Reply-To: <Vf6lqq125Sm_RI-DdmSg92hEYYMh7laQIohty4QltpI=.b0569b35-404d-47cf-8723-f5b7cbd3f672@github.com>
References: <Vf6lqq125Sm_RI-DdmSg92hEYYMh7laQIohty4QltpI=.b0569b35-404d-47cf-8723-f5b7cbd3f672@github.com>
Message-ID: <bC2Cs5INYtk6CmXyr_lx5ZM56fwevbYRZElUbjElFBY=.5de046a7-6fc9-4fbb-9b33-9b9b73120c92@github.com>

On Fri, 22 Aug 2025 14:31:25 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution"

FTR Un-problem listing will be done by https://bugs.openjdk.org/browse/JDK-8365989.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1532#issuecomment-3214625788

From nlisker at gmail.com  Fri Aug 22 15:28:58 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 22 Aug 2025 18:28:58 +0300
Subject: Update to Null-Restricted and Nullable Types JEP
Message-ID: <CA+0ynh-eN8VF7jKpid5rmQstpkYWCEbM-eRB-YBgvTnt7FwS5w@mail.gmail.com>

Hi,

The Null-Restricted and Nullable Types JEP lists under Prerequisites:
Flexible Constructor Bodies (Second Preview). This feature has been
provided in 25. Should the JEP be updated to indicate its current status?

Thanks,
Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250822/0f367747/attachment.htm>

From chen.l.liang at oracle.com  Fri Aug 22 16:02:19 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 22 Aug 2025 16:02:19 +0000
Subject: Update to Null-Restricted and Nullable Types JEP
In-Reply-To: <CA+0ynh-eN8VF7jKpid5rmQstpkYWCEbM-eRB-YBgvTnt7FwS5w@mail.gmail.com>
References: <CA+0ynh-eN8VF7jKpid5rmQstpkYWCEbM-eRB-YBgvTnt7FwS5w@mail.gmail.com>
Message-ID: <CH3PR10MB7677B0FB151474C9E24A5521A23DA@CH3PR10MB7677.namprd10.prod.outlook.com>

Hi Nir,
Many of the Valhalla JEPs are just out as drafts. They often have many details to be flushed out. All JEPs get reviewed before they are submitted. In this process, outdated references will get corrected, and will get further tweaked when a JEP is targeted for the release they are proposed to target.

Chen
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Nir Lisker <nlisker at gmail.com>
Sent: Friday, August 22, 2025 10:28 AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: Update to Null-Restricted and Nullable Types JEP

Hi,

The Null-Restricted and Nullable Types JEP lists under Prerequisites: Flexible Constructor Bodies (Second Preview). This feature has been provided in 25. Should the JEP be updated to indicate its current status?

Thanks,
Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250822/6cf87fca/attachment-0001.htm>

From vromero at openjdk.org  Fri Aug 22 16:23:48 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 22 Aug 2025 16:23:48 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v7]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <1F1xuH-ifoJIUTK9Knzm1CvWMRghT1DGyNrWeT6t6_k=.c3d7a0e4-a5e5-42f1-a6cb-c3bec5489317@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - fixing bugs: new test cases brought in with latest merge are not accepted
 - merge with lworld
 - refactorings
 - another bug fix
 - bug fix
 - merge with lworld
 - renaming methods in LocalProxyVarGen
 - more changes
 - refactoring
 - test changes
 - ... and 7 more: https://git.openjdk.org/valhalla/compare/62e90b5d...0eb81681

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

Changes: https://git.openjdk.org/valhalla/pull/1523/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=06
  Stats: 486 lines in 26 files changed: 324 ins; 90 del; 72 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From vromero at openjdk.org  Fri Aug 22 16:23:48 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 22 Aug 2025 16:23:48 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v7]
In-Reply-To: <1F1xuH-ifoJIUTK9Knzm1CvWMRghT1DGyNrWeT6t6_k=.c3d7a0e4-a5e5-42f1-a6cb-c3bec5489317@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <1F1xuH-ifoJIUTK9Knzm1CvWMRghT1DGyNrWeT6t6_k=.c3d7a0e4-a5e5-42f1-a6cb-c3bec5489317@github.com>
Message-ID: <1SGBG4BEfCTsleOhmza-_MOxvHGe6HmVCR94n1_q2b0=.b70f7ac7-256b-4b8f-aa3d-79d571970a44@github.com>

On Fri, 22 Aug 2025 16:20:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - fixing bugs: new test cases brought in with latest merge are not accepted
>  - merge with lworld
>  - refactorings
>  - another bug fix
>  - bug fix
>  - merge with lworld
>  - renaming methods in LocalProxyVarGen
>  - more changes
>  - refactoring
>  - test changes
>  - ... and 7 more: https://git.openjdk.org/valhalla/compare/62e90b5d...0eb81681

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 91:

> 89:     private final UnsetFieldsInfo unsetFieldsInfo;
> 90:     private ClassSymbol currentClass = null;
> 91:     private java.util.List<JCVariableDecl> finalOrStrictInstanceFields;

most changes in this one are due to renaming as now we will be tracking non-strict fields too

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2294156402

From vromero at openjdk.org  Fri Aug 22 16:53:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 22 Aug 2025 16:53:03 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v7]
In-Reply-To: <1F1xuH-ifoJIUTK9Knzm1CvWMRghT1DGyNrWeT6t6_k=.c3d7a0e4-a5e5-42f1-a6cb-c3bec5489317@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <1F1xuH-ifoJIUTK9Knzm1CvWMRghT1DGyNrWeT6t6_k=.c3d7a0e4-a5e5-42f1-a6cb-c3bec5489317@github.com>
Message-ID: <VwTS_rKQz4IG96dfaBSbJpIwUP3yT9siLrSsB3P2464=.b909fb44-11f0-4346-936e-9e7dbef83cd8@github.com>

On Fri, 22 Aug 2025 16:23:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - fixing bugs: new test cases brought in with latest merge are not accepted
>  - merge with lworld
>  - refactorings
>  - another bug fix
>  - bug fix
>  - merge with lworld
>  - renaming methods in LocalProxyVarGen
>  - more changes
>  - refactoring
>  - test changes
>  - ... and 7 more: https://git.openjdk.org/valhalla/compare/62e90b5d...0eb81681

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 137:

> 135:                     .filter(t -> t.hasTag(VARDEF))
> 136:                     .map(t -> (JCVariableDecl)t)
> 137:                     .filter(vd -> (vd.sym.isStrict() || vd.sym.isFinal()) && !vd.sym.isStatic())

semantic change

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2294208686

From thartmann at openjdk.org  Fri Aug 22 16:59:30 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 22 Aug 2025 16:59:30 GMT
Subject: [lworld] RFR: 8364579: [lworld] Null oop fields are not correctly
 handled in scalarized returns
Message-ID: <7JEfhk6ucU2eJI6FudAH2T31rXROKKmTymgmRV3YwIQ=.ba38b493-8c13-4e58-95d3-89c2508c5762@github.com>

The test that I wrote for Virtual Thread support (see [JDK-8336845](https://bugs.openjdk.org/browse/JDK-8336845)) triggers various crashes even without Virtual Threads. The problem is that null fields in scalarized returns are not zeroed which makes the GC very unhappy. This affects both x86 as well as AArch64. I added a targeted regression test for this scenario.

I then noticed that the code that handles oop fields in scalarized returns at safepoints does not correctly handle the case when a value object is returned both in scalarized form **and** as oop:
https://github.com/openjdk/valhalla/blob/b2e518b7cf85527b90f34ba63bf5a1b775430cd0/src/hotspot/share/runtime/safepoint.cpp#L793-L803

I fixed this as well, see  changes in `InlineKlass::returned_inline_klass`.

While testing this fix, I found more issues on AArch64. After debugging for a few days straight, I found multiple issues and filed [JDK-8365996](https://bugs.openjdk.org/browse/JDK-8365996) as a follow-up. For now, I disabled the test on AArch64.

Thanks,
Tobias

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

Commit messages:
 - Restrict to x64 for now because there are more bugs on aarchh64
 - Merge branch 'lworld' into JDK-8364579
 - Missed to arg registers on AArch64
 - First draft
 - First draft

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

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

From thartmann at openjdk.org  Fri Aug 22 18:07:09 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 22 Aug 2025 18:07:09 GMT
Subject: [lworld] Integrated: 8364579: [lworld] Null oop fields are not
 correctly handled in scalarized returns
In-Reply-To: <7JEfhk6ucU2eJI6FudAH2T31rXROKKmTymgmRV3YwIQ=.ba38b493-8c13-4e58-95d3-89c2508c5762@github.com>
References: <7JEfhk6ucU2eJI6FudAH2T31rXROKKmTymgmRV3YwIQ=.ba38b493-8c13-4e58-95d3-89c2508c5762@github.com>
Message-ID: <t50a_2gd2ELi9xitok5OucVcq0i_9IO04165wWhyo0E=.954a8d82-fc5f-44db-a81e-03586e30e7dc@github.com>

On Wed, 20 Aug 2025 05:21:17 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The test that I wrote for Virtual Thread support (see [JDK-8336845](https://bugs.openjdk.org/browse/JDK-8336845)) triggers various crashes even without Virtual Threads. The problem is that null fields in scalarized returns are not zeroed which makes the GC very unhappy. This affects both x86 as well as AArch64. I added a targeted regression test for this scenario.
> 
> I then noticed that the code that handles oop fields in scalarized returns at safepoints does not correctly handle the case when a value object is returned both in scalarized form **and** as oop:
> https://github.com/openjdk/valhalla/blob/b2e518b7cf85527b90f34ba63bf5a1b775430cd0/src/hotspot/share/runtime/safepoint.cpp#L793-L803
> 
> I fixed this as well, see  changes in `InlineKlass::returned_inline_klass`.
> 
> While testing this fix, I found more issues on AArch64. After debugging for a few days straight, I found multiple issues and filed [JDK-8365996](https://bugs.openjdk.org/browse/JDK-8365996) as a follow-up. For now, I disabled the test on AArch64.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 68b13b46
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/68b13b46d1f05c22dccb8dc0b5391cc920ceb4fd
Stats:     304 lines in 14 files changed: 273 ins; 5 del; 26 mod

8364579: [lworld] Null oop fields are not correctly handled in scalarized returns

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

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

From vromero at openjdk.org  Fri Aug 22 19:42:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 22 Aug 2025 19:42:50 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v8]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <4fCj2SdfVa90WX1q6hTSr8Gi4RZu-4k8CKhn6h5Ls78=.82006043-0ee9-4601-81f7-55017b971bf7@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  minor refactorings and simplifications

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/0eb81681..31c7b8c2

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

  Stats: 56 lines in 1 file changed: 8 ins; 20 del; 28 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From thartmann at openjdk.org  Mon Aug 25 06:52:15 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 25 Aug 2025 06:52:15 GMT
Subject: [lworld] RFR: 8360851: [lworld] missing # {method} comment in
 assembly dumping [v2]
In-Reply-To: <gnIAJpYp5Zw33iTbanCE4D8bxR67hQK5ZChdvUuigBM=.893bf7be-4421-4f78-b511-4481253a313c@github.com>
References: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
 <gnIAJpYp5Zw33iTbanCE4D8bxR67hQK5ZChdvUuigBM=.893bf7be-4421-4f78-b511-4481253a313c@github.com>
Message-ID: <2JaH92RhOHIR0w3xvEur4D36flXgn8lO-62H0CWD4X8=.fb600935-50b5-48d0-9f16-73a99098da9f@github.com>

On Thu, 21 Aug 2025 11:26:54 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> `CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:
>> 
>> https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796
>> 
>> This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.
>> 
>> Testing:
>>  - [x] tier1,tier2,tier3,valhalla-comp-stress
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Problem list regression test for ZGC on aarch64

Thanks for working on this, Manuel! Fix looks good, just two minor comments.

src/hotspot/share/code/nmethod.cpp line 3792:

> 3790:                      verified_entry_point(),
> 3791:                      inline_entry_point());
> 3792:   if (verified_inline_entry_point() >= block_begin) {

A comment would be good, explaining the special-casing of these two.

test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/MethodTagTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1529#pullrequestreview-3150132313
PR Review Comment: https://git.openjdk.org/valhalla/pull/1529#discussion_r2297262309
PR Review Comment: https://git.openjdk.org/valhalla/pull/1529#discussion_r2297257968

From thartmann at openjdk.org  Mon Aug 25 07:21:08 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 25 Aug 2025 07:21:08 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances
In-Reply-To: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
Message-ID: <VOvteWrGuSq93Xli9i6Q6AArv8IJVVqAXEo-3msMqhg=.3772a2d4-9eae-4860-842f-bfab50b906c6@github.com>

On Fri, 22 Aug 2025 14:07:16 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
> 
> # Diagnostic
> 
> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
> 
> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
> 
> In the original example:
> 
> public value class MyNumber {
>     private long d0;
>     private MyNumber(long d0) { this.d0 = d0; }
>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
> 
>     private static void loop() {
>         MyNumber dec = new MyNumber(123);
>         for (int i = 0; i < 1_000_000_000; ++i) {
>             dec = dec.add(i);
>         }
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 10; ++i) {
>             loop();
>         }
>     }
> }
> 
> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
> 
> # Solution
> 
> Overall, the solution requires to improve our detection of early larval values. Since we keep parsing as-is, let's do that in `ciTypeFlow`. Th...

Thanks for working on this Marc. Analysis and fix look good. I just added a few minor comments.

src/hotspot/share/ci/ciType.cpp line 151:

> 149:   assert(type->is_inlinetype()
> 150:              // An abstract value type is an instance_klass
> 151:              || (type->is_instance_klass() && type->as_instance_klass()->flags().is_abstract() && !type->as_instance_klass()->flags().is_identity())

Just wondering, is the `type->as_instance_klass()->flags().is_abstract()` condition even needed? Same in `ciTypeFlow::get_start_state()`.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/LarvalDetectionAboveOSR.java line 29:

> 27:  * @summary In OSR compilation, value objects coming from above the OSR start
> 28:  * must be correctly found to be early larval so we know they are
> 29:  * immutable, and they can be scalarized.

I suggest to rephrase this: "to be early larval so we know they are immutable" is confusing because early larvals are **mutable**.

test/micro/org/openjdk/bench/valhalla/loops/osr/LarvalDetectionAboveOSR.java line 1:

> 1: package org.openjdk.bench.valhalla.loops.osr;

Copyright header is missing.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1531#pullrequestreview-3150178417
PR Review Comment: https://git.openjdk.org/valhalla/pull/1531#discussion_r2297313229
PR Review Comment: https://git.openjdk.org/valhalla/pull/1531#discussion_r2297293768
PR Review Comment: https://git.openjdk.org/valhalla/pull/1531#discussion_r2297289457

From mhaessig at openjdk.org  Mon Aug 25 07:26:54 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 25 Aug 2025 07:26:54 GMT
Subject: [lworld] RFR: 8360851: [lworld] missing # {method} comment in
 assembly dumping [v3]
In-Reply-To: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
References: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
Message-ID: <yizewF975BQZopre2uJugADqKWdB3FRDBkzlwwpT1RQ=.97d391bb-0c13-4a18-8799-79131dc4a1f9@github.com>

> `CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:
> 
> https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796
> 
> This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.
> 
> Testing:
>  - [x] tier1,tier2,tier3,valhalla-comp-stress

Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:

  Address Tobias' comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1529/files
  - new: https://git.openjdk.org/valhalla/pull/1529/files/4fd05be3..61143ad3

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

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

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

From mhaessig at openjdk.org  Mon Aug 25 07:26:55 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 25 Aug 2025 07:26:55 GMT
Subject: [lworld] RFR: 8360851: [lworld] missing # {method} comment in
 assembly dumping [v2]
In-Reply-To: <gnIAJpYp5Zw33iTbanCE4D8bxR67hQK5ZChdvUuigBM=.893bf7be-4421-4f78-b511-4481253a313c@github.com>
References: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
 <gnIAJpYp5Zw33iTbanCE4D8bxR67hQK5ZChdvUuigBM=.893bf7be-4421-4f78-b511-4481253a313c@github.com>
Message-ID: <zk86qGCV5F5qrkUkelk0jalZjyESfINhoRH1XHMkX9o=.c31a914e-3109-47f9-976c-e466818f4dd2@github.com>

On Thu, 21 Aug 2025 11:26:54 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> `CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:
>> 
>> https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796
>> 
>> This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.
>> 
>> Testing:
>>  - [x] tier1,tier2,tier3,valhalla-comp-stress
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Problem list regression test for ZGC on aarch64

Thank you for looking at this, Tobias. I addressed your two comments.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1529#issuecomment-3219130445

From thartmann at openjdk.org  Mon Aug 25 07:38:02 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 25 Aug 2025 07:38:02 GMT
Subject: [lworld] RFR: 8360851: [lworld] missing # {method} comment in
 assembly dumping [v3]
In-Reply-To: <yizewF975BQZopre2uJugADqKWdB3FRDBkzlwwpT1RQ=.97d391bb-0c13-4a18-8799-79131dc4a1f9@github.com>
References: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
 <yizewF975BQZopre2uJugADqKWdB3FRDBkzlwwpT1RQ=.97d391bb-0c13-4a18-8799-79131dc4a1f9@github.com>
Message-ID: <jYyMTk_BZaH9sP81AlEiv2KAUYt1i9ZcwGzYiUh4bng=.ae2e0f80-5ff4-4715-af05-29f5520d4f2c@github.com>

On Mon, 25 Aug 2025 07:26:54 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> `CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:
>> 
>> https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796
>> 
>> This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.
>> 
>> Testing:
>>  - [x] tier1,tier2,tier3,valhalla-comp-stress
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Tobias' comments

Looks good.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1529#pullrequestreview-3150267576

From mhaessig at openjdk.org  Mon Aug 25 07:52:02 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 25 Aug 2025 07:52:02 GMT
Subject: [lworld] RFR: 8360851: [lworld] missing # {method} comment in
 assembly dumping [v3]
In-Reply-To: <yizewF975BQZopre2uJugADqKWdB3FRDBkzlwwpT1RQ=.97d391bb-0c13-4a18-8799-79131dc4a1f9@github.com>
References: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
 <yizewF975BQZopre2uJugADqKWdB3FRDBkzlwwpT1RQ=.97d391bb-0c13-4a18-8799-79131dc4a1f9@github.com>
Message-ID: <R7mo_hU5iOlMvZeLUtGevgK50M54TQ1Uqu3bE2W2LwU=.0e794aaa-6b89-4a32-ae56-762c22937747@github.com>

On Mon, 25 Aug 2025 07:26:54 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> `CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:
>> 
>> https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796
>> 
>> This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.
>> 
>> Testing:
>>  - [x] tier1,tier2,tier3,valhalla-comp-stress
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Tobias' comments

Thank you for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1529#issuecomment-3219197706

From duke at openjdk.org  Mon Aug 25 07:52:03 2025
From: duke at openjdk.org (duke)
Date: Mon, 25 Aug 2025 07:52:03 GMT
Subject: [lworld] RFR: 8360851: [lworld] missing # {method} comment in
 assembly dumping [v3]
In-Reply-To: <yizewF975BQZopre2uJugADqKWdB3FRDBkzlwwpT1RQ=.97d391bb-0c13-4a18-8799-79131dc4a1f9@github.com>
References: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
 <yizewF975BQZopre2uJugADqKWdB3FRDBkzlwwpT1RQ=.97d391bb-0c13-4a18-8799-79131dc4a1f9@github.com>
Message-ID: <b7S9JhufJd0H8uRP5i3cEicsnTCxCZny9i0s1ioyJiE=.63cf8d0b-62ce-472d-a148-e34aedf6a0ec@github.com>

On Mon, 25 Aug 2025 07:26:54 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> `CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:
>> 
>> https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796
>> 
>> This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.
>> 
>> Testing:
>>  - [x] tier1,tier2,tier3,valhalla-comp-stress
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Tobias' comments

@mhaessig 
Your change (at version 61143ad3839e906729e55d14c6d3cfdef0ae379e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1529#issuecomment-3219202585

From mhaessig at openjdk.org  Mon Aug 25 08:19:04 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 25 Aug 2025 08:19:04 GMT
Subject: [lworld] Integrated: 8360851: [lworld] missing # {method} comment in
 assembly dumping
In-Reply-To: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
References: <qF3EFFMH_ELSC2YMuNKsX7VvoV6yAhm3p1hScgzFW8Q=.ce48892d-12f0-4180-bd32-5d8f7d5def0b@github.com>
Message-ID: <IhBwfJVuZ-X4xfBv5cPfnI9ST_4-BSfgnXudsc9DV1k=.74bd3f10-e4bc-42e4-940e-789c00889945@github.com>

On Wed, 20 Aug 2025 16:24:45 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> `CodeOffsets::Verified_Inline_Entry` and `CodeOffsets::Verified_Inline_Entry` are special among entry point code offsets because they can be disabled with a value of `-1`. The code installation for hotspot deals with this by just setting both to the same value as `CodeOffsets::Verified_Entry` if they are disabled. JVMCI code installation on the other hand, leaves the offsets at `-1`. When printing the assembly of a JVMCI compiled method where both offsets are disabled, the method name is not printed together with the entry point labels. This is due to the disabled entry points having the lowest address due to their negative offset and those disabled entry points thus pointing to an address before the block that is being printed:
> 
> https://github.com/openjdk/valhalla/blob/af03598eb81aee17c0657347fd6439475ca8f7ee/src/hotspot/share/code/nmethod.cpp#L3788-L3796
> 
> This PR fixes this issue by checking if the entry points that can be disabled point into the code block that is being printed. The regression test is botched together from two existing tests, due to my inexperience with JVMCI (but it works). Suggestions for a better test are welcome.
> 
> Testing:
>  - [x] tier1,tier2,tier3,valhalla-comp-stress

This pull request has now been integrated.

Changeset: 5132a63c
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5132a63ca1ddc99dec7b6d3e6c272af97e1f6351
Stats:     192 lines in 3 files changed: 190 ins; 0 del; 2 mod

8360851: [lworld] missing # {method} comment in assembly dumping

Reviewed-by: thartmann

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

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

From mchevalier at openjdk.org  Mon Aug 25 09:11:06 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 25 Aug 2025 09:11:06 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v2]
In-Reply-To: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
Message-ID: <V48asNpkJSsloVQzbp6isUTSWNZ1lccOk2GzmC3B7cw=.819b252b-9967-439c-8ac4-8b228c272719@github.com>

> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
> 
> # Diagnostic
> 
> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
> 
> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
> 
> In the original example:
> 
> public value class MyNumber {
>     private long d0;
>     private MyNumber(long d0) { this.d0 = d0; }
>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
> 
>     private static void loop() {
>         MyNumber dec = new MyNumber(123);
>         for (int i = 0; i < 1_000_000_000; ++i) {
>             dec = dec.add(i);
>         }
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 10; ++i) {
>             loop();
>         }
>     }
> }
> 
> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
> 
> # Solution
> 
> Overall, the solution requires to improve our detection of early larval values. Since we keep parsing as-is, let's do that in `ciTypeFlow`. Th...

Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:

 - Rephrase summary
 - +copyright

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1531/files
  - new: https://git.openjdk.org/valhalla/pull/1531/files/acce992f..183dfe97

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

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

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

From mchevalier at openjdk.org  Mon Aug 25 09:11:06 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 25 Aug 2025 09:11:06 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v2]
In-Reply-To: <VOvteWrGuSq93Xli9i6Q6AArv8IJVVqAXEo-3msMqhg=.3772a2d4-9eae-4860-842f-bfab50b906c6@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <VOvteWrGuSq93Xli9i6Q6AArv8IJVVqAXEo-3msMqhg=.3772a2d4-9eae-4860-842f-bfab50b906c6@github.com>
Message-ID: <10IO7fsHi7fd1PoNKXbljPjVyUL1P91ItbZPeyjOey0=.33ff7f5f-adb5-41a9-95d0-09bab21e8656@github.com>

On Mon, 25 Aug 2025 07:17:16 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Rephrase summary
>>  - +copyright
>
> src/hotspot/share/ci/ciType.cpp line 151:
> 
>> 149:   assert(type->is_inlinetype()
>> 150:              // An abstract value type is an instance_klass
>> 151:              || (type->is_instance_klass() && type->as_instance_klass()->flags().is_abstract() && !type->as_instance_klass()->flags().is_identity())
> 
> Just wondering, is the `type->as_instance_klass()->flags().is_abstract()` condition even needed? Same in `ciTypeFlow::get_start_state()`.

Probably not. An instance class without identity must be an abstract value class. At least, I don't see another way... But just to be sure, I'm running some tests.

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/LarvalDetectionAboveOSR.java line 29:
> 
>> 27:  * @summary In OSR compilation, value objects coming from above the OSR start
>> 28:  * must be correctly found to be early larval so we know they are
>> 29:  * immutable, and they can be scalarized.
> 
> I suggest to rephrase this: "to be early larval so we know they are immutable" is confusing because early larvals are **mutable**.

Wow, yeah, I see what I wanted to say, but it's terrible! I've tried something else, hopefully better.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1531#discussion_r2297532414
PR Review Comment: https://git.openjdk.org/valhalla/pull/1531#discussion_r2297539481

From thartmann at openjdk.org  Mon Aug 25 09:30:07 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 25 Aug 2025 09:30:07 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v2]
In-Reply-To: <10IO7fsHi7fd1PoNKXbljPjVyUL1P91ItbZPeyjOey0=.33ff7f5f-adb5-41a9-95d0-09bab21e8656@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <VOvteWrGuSq93Xli9i6Q6AArv8IJVVqAXEo-3msMqhg=.3772a2d4-9eae-4860-842f-bfab50b906c6@github.com>
 <10IO7fsHi7fd1PoNKXbljPjVyUL1P91ItbZPeyjOey0=.33ff7f5f-adb5-41a9-95d0-09bab21e8656@github.com>
Message-ID: <rJ-OzYWk3dF4aQW4cUBN-aOSlZPcBaq4jUPbPb5rGvA=.0be28b4c-064c-4347-a506-80815c39b26c@github.com>

On Mon, 25 Aug 2025 09:04:32 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/ci/ciType.cpp line 151:
>> 
>>> 149:   assert(type->is_inlinetype()
>>> 150:              // An abstract value type is an instance_klass
>>> 151:              || (type->is_instance_klass() && type->as_instance_klass()->flags().is_abstract() && !type->as_instance_klass()->flags().is_identity())
>> 
>> Just wondering, is the `type->as_instance_klass()->flags().is_abstract()` condition even needed? Same in `ciTypeFlow::get_start_state()`.
>
> Probably not. An instance class without identity must be an abstract value class. At least, I don't see another way... But just to be sure, I'm running some tests.

Right, I think so too. Thanks for checking!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1531#discussion_r2297588486

From thartmann at openjdk.org  Mon Aug 25 09:30:07 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 25 Aug 2025 09:30:07 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v2]
In-Reply-To: <V48asNpkJSsloVQzbp6isUTSWNZ1lccOk2GzmC3B7cw=.819b252b-9967-439c-8ac4-8b228c272719@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <V48asNpkJSsloVQzbp6isUTSWNZ1lccOk2GzmC3B7cw=.819b252b-9967-439c-8ac4-8b228c272719@github.com>
Message-ID: <9vWc22JwxZnDcGOJzvbC3TsHulNy0ybi2lyU86vbTIg=.687a48e5-9d3e-456b-887f-3f8674c862f9@github.com>

On Mon, 25 Aug 2025 09:11:06 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
>> 
>> # Diagnostic
>> 
>> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
>> 
>> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
>> 
>> In the original example:
>> 
>> public value class MyNumber {
>>     private long d0;
>>     private MyNumber(long d0) { this.d0 = d0; }
>>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
>> 
>>     private static void loop() {
>>         MyNumber dec = new MyNumber(123);
>>         for (int i = 0; i < 1_000_000_000; ++i) {
>>             dec = dec.add(i);
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         for (int i = 0; i < 10; ++i) {
>>             loop();
>>         }
>>     }
>> }
>> 
>> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
>> 
>> # Solution
>> 
>> Overall, the solution requires to improve our detection of early larval va...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rephrase summary
>  - +copyright

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

> 28:  * state of value objects coming from above the OSR start, and not consider
> 29:  * everything as potentially early larval. Value objects that are known to be
> 30:  * unrestricted (late larval of fully initialized) are immutable, and can be

Typo? 

Suggestion:

 * unrestricted (late larval or fully initialized) are immutable, and can be

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1531#discussion_r2297587571

From mchevalier at openjdk.org  Mon Aug 25 09:46:46 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 25 Aug 2025 09:46:46 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v3]
In-Reply-To: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
Message-ID: <aVISdxWJ4K0LLHRnlxjg4z-GGEkMqoEMBzcDyhpnVfs=.6275184f-6d36-4ef2-8378-0ef014bdbfdc@github.com>

> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
> 
> # Diagnostic
> 
> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
> 
> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
> 
> In the original example:
> 
> public value class MyNumber {
>     private long d0;
>     private MyNumber(long d0) { this.d0 = d0; }
>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
> 
>     private static void loop() {
>         MyNumber dec = new MyNumber(123);
>         for (int i = 0; i < 1_000_000_000; ++i) {
>             dec = dec.add(i);
>         }
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 10; ++i) {
>             loop();
>         }
>     }
> }
> 
> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
> 
> # Solution
> 
> Overall, the solution requires to improve our detection of early larval values. Since we keep parsing as-is, let's do that in `ciTypeFlow`. Th...

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  Typo

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1531/files
  - new: https://git.openjdk.org/valhalla/pull/1531/files/183dfe97..e418d174

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

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

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

From mchevalier at openjdk.org  Mon Aug 25 11:18:06 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 25 Aug 2025 11:18:06 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v3]
In-Reply-To: <rJ-OzYWk3dF4aQW4cUBN-aOSlZPcBaq4jUPbPb5rGvA=.0be28b4c-064c-4347-a506-80815c39b26c@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <VOvteWrGuSq93Xli9i6Q6AArv8IJVVqAXEo-3msMqhg=.3772a2d4-9eae-4860-842f-bfab50b906c6@github.com>
 <10IO7fsHi7fd1PoNKXbljPjVyUL1P91ItbZPeyjOey0=.33ff7f5f-adb5-41a9-95d0-09bab21e8656@github.com>
 <rJ-OzYWk3dF4aQW4cUBN-aOSlZPcBaq4jUPbPb5rGvA=.0be28b4c-064c-4347-a506-80815c39b26c@github.com>
Message-ID: <PzhZX7NVwnK9UIO9vwIBn6ESAwF0xBMnGngLnjvxcAU=.78215525-e17c-4b38-8220-a21eb6241cc6@github.com>

On Mon, 25 Aug 2025 09:27:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Probably not. An instance class without identity must be an abstract value class. At least, I don't see another way... But just to be sure, I'm running some tests.
>
> Right, I think so too. Thanks for checking!

I've realized that since `ciInlineKlass` is a class derived from `ciInstanceKlass`, `type->is_instance_klass()` is also true for `ciInlineKlass`, which messed up my experiment but I guess it's reasonable.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1531#discussion_r2297830541

From vromero at openjdk.org  Mon Aug 25 12:58:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 25 Aug 2025 12:58:06 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v7]
In-Reply-To: <VwTS_rKQz4IG96dfaBSbJpIwUP3yT9siLrSsB3P2464=.b909fb44-11f0-4346-936e-9e7dbef83cd8@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <1F1xuH-ifoJIUTK9Knzm1CvWMRghT1DGyNrWeT6t6_k=.c3d7a0e4-a5e5-42f1-a6cb-c3bec5489317@github.com>
 <VwTS_rKQz4IG96dfaBSbJpIwUP3yT9siLrSsB3P2464=.b909fb44-11f0-4346-936e-9e7dbef83cd8@github.com>
Message-ID: <azcgyS5LkOnFMX6rdXhco-rgIlQWM5f554FLSmAN_Bc=.c9d884b6-5de4-48cf-a86d-1ebe6e74c384@github.com>

On Fri, 22 Aug 2025 16:50:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - fixing bugs: new test cases brought in with latest merge are not accepted
>>  - merge with lworld
>>  - refactorings
>>  - another bug fix
>>  - bug fix
>>  - merge with lworld
>>  - renaming methods in LocalProxyVarGen
>>  - more changes
>>  - refactoring
>>  - test changes
>>  - ... and 7 more: https://git.openjdk.org/valhalla/compare/62e90b5d...0eb81681
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LocalProxyVarsGen.java line 137:
> 
>> 135:                     .filter(t -> t.hasTag(VARDEF))
>> 136:                     .map(t -> (JCVariableDecl)t)
>> 137:                     .filter(vd -> (vd.sym.isStrict() || vd.sym.isFinal()) && !vd.sym.isStatic())
> 
> semantic change

doing some changes here, I realized there is a bug in the PR, working on it now

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2298029304

From vromero at openjdk.org  Mon Aug 25 19:40:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 25 Aug 2025 19:40:59 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v9]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <W4jymssKAb3-9k-DyxmaAcFfs3iNlhRL3Pl8UNB5i0s=.277a16e5-2d1c-40a0-a2a7-a20fe5c107c1@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  more simplifications and bug fixes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/31c7b8c2..a5f2947d

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

  Stats: 100 lines in 4 files changed: 29 ins; 36 del; 35 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From vromero at openjdk.org  Tue Aug 26 02:07:58 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 26 Aug 2025 02:07:58 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v10]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <FTD3EOWHGRU8DeIYWvWEC4Qd_Q5oTkQ66-rUcnFfpnE=.a0607715-75c3-40b7-bca9-a52d3adeffcb@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  documentation

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/a5f2947d..5cb0f429

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

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

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

From thartmann at openjdk.org  Tue Aug 26 06:32:59 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 26 Aug 2025 06:32:59 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v3]
In-Reply-To: <aVISdxWJ4K0LLHRnlxjg4z-GGEkMqoEMBzcDyhpnVfs=.6275184f-6d36-4ef2-8378-0ef014bdbfdc@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <aVISdxWJ4K0LLHRnlxjg4z-GGEkMqoEMBzcDyhpnVfs=.6275184f-6d36-4ef2-8378-0ef014bdbfdc@github.com>
Message-ID: <BipHLGOS4ebTmqEIEZISvvLSitWE3HH7FjW3TCGTPmk=.b4312035-7dd5-454b-b240-99b5e8ed6e29@github.com>

On Mon, 25 Aug 2025 09:46:46 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
>> 
>> # Diagnostic
>> 
>> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
>> 
>> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
>> 
>> In the original example:
>> 
>> public value class MyNumber {
>>     private long d0;
>>     private MyNumber(long d0) { this.d0 = d0; }
>>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
>> 
>>     private static void loop() {
>>         MyNumber dec = new MyNumber(123);
>>         for (int i = 0; i < 1_000_000_000; ++i) {
>>             dec = dec.add(i);
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         for (int i = 0; i < 10; ++i) {
>>             loop();
>>         }
>>     }
>> }
>> 
>> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
>> 
>> # Solution
>> 
>> Overall, the solution requires to improve our detection of early larval va...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

Marked as reviewed by thartmann (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1531#pullrequestreview-3154116405

From mchevalier at openjdk.org  Tue Aug 26 08:30:23 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 26 Aug 2025 08:30:23 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v4]
In-Reply-To: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
Message-ID: <o16VJibdYEZtm16sxH79BC53_Hn6wppUZHn5Z_yHdQM=.c77e66a1-c34f-4835-81de-9da79b7c2418@github.com>

> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
> 
> # Diagnostic
> 
> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
> 
> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
> 
> In the original example:
> 
> public value class MyNumber {
>     private long d0;
>     private MyNumber(long d0) { this.d0 = d0; }
>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
> 
>     private static void loop() {
>         MyNumber dec = new MyNumber(123);
>         for (int i = 0; i < 1_000_000_000; ++i) {
>             dec = dec.add(i);
>         }
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 10; ++i) {
>             loop();
>         }
>     }
> }
> 
> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
> 
> # Solution
> 
> Overall, the solution requires to improve our detection of early larval values. Since we keep parsing as-is, let's do that in `ciTypeFlow`. Th...

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  Remove is_abstract condition

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1531/files
  - new: https://git.openjdk.org/valhalla/pull/1531/files/e418d174..0a6f0eb2

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

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

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

From mchevalier at openjdk.org  Tue Aug 26 08:30:23 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 26 Aug 2025 08:30:23 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v3]
In-Reply-To: <aVISdxWJ4K0LLHRnlxjg4z-GGEkMqoEMBzcDyhpnVfs=.6275184f-6d36-4ef2-8378-0ef014bdbfdc@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <aVISdxWJ4K0LLHRnlxjg4z-GGEkMqoEMBzcDyhpnVfs=.6275184f-6d36-4ef2-8378-0ef014bdbfdc@github.com>
Message-ID: <9q4fOheZba4EjaOfIekEb0sED3XA7ncmtUGgTIDyC1w=.9512d1a5-4db6-4c09-a49c-240119c35a1b@github.com>

On Mon, 25 Aug 2025 09:46:46 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
>> 
>> # Diagnostic
>> 
>> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
>> 
>> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
>> 
>> In the original example:
>> 
>> public value class MyNumber {
>>     private long d0;
>>     private MyNumber(long d0) { this.d0 = d0; }
>>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
>> 
>>     private static void loop() {
>>         MyNumber dec = new MyNumber(123);
>>         for (int i = 0; i < 1_000_000_000; ++i) {
>>             dec = dec.add(i);
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         for (int i = 0; i < 10; ++i) {
>>             loop();
>>         }
>>     }
>> }
>> 
>> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
>> 
>> # Solution
>> 
>> Overall, the solution requires to improve our detection of early larval va...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

After the successful testing with asserting that the abstract was useless (implied by instanceKlass without identity), I've push the fix. The condition is actually slightly relaxed as it also catches final value classes, and not only abstract value classes, but anyway, we want both.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1531#issuecomment-3223136284

From thartmann at openjdk.org  Tue Aug 26 10:03:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 26 Aug 2025 10:03:52 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v4]
In-Reply-To: <o16VJibdYEZtm16sxH79BC53_Hn6wppUZHn5Z_yHdQM=.c77e66a1-c34f-4835-81de-9da79b7c2418@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <o16VJibdYEZtm16sxH79BC53_Hn6wppUZHn5Z_yHdQM=.c77e66a1-c34f-4835-81de-9da79b7c2418@github.com>
Message-ID: <m0G-1lSM4gnQPS-fqs7CGGeTTlqhbrG8gUbMwVy7Ea8=.14104d9b-bca1-4b98-a3b7-e7336bb77947@github.com>

On Tue, 26 Aug 2025 08:30:23 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
>> 
>> # Diagnostic
>> 
>> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
>> 
>> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
>> 
>> In the original example:
>> 
>> public value class MyNumber {
>>     private long d0;
>>     private MyNumber(long d0) { this.d0 = d0; }
>>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
>> 
>>     private static void loop() {
>>         MyNumber dec = new MyNumber(123);
>>         for (int i = 0; i < 1_000_000_000; ++i) {
>>             dec = dec.add(i);
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         for (int i = 0; i < 10; ++i) {
>>             loop();
>>         }
>>     }
>> }
>> 
>> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
>> 
>> # Solution
>> 
>> Overall, the solution requires to improve our detection of early larval va...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove is_abstract condition

Thanks for verifying. Looks good to me. Ship it! :)

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1531#pullrequestreview-3154907971

From mchevalier at openjdk.org  Tue Aug 26 12:00:57 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 26 Aug 2025 12:00:57 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v4]
In-Reply-To: <o16VJibdYEZtm16sxH79BC53_Hn6wppUZHn5Z_yHdQM=.c77e66a1-c34f-4835-81de-9da79b7c2418@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <o16VJibdYEZtm16sxH79BC53_Hn6wppUZHn5Z_yHdQM=.c77e66a1-c34f-4835-81de-9da79b7c2418@github.com>
Message-ID: <EkAfYKHKxMnp0v6zrU4MHjDcr5ybRQQ3zdsWnVmBm3Y=.d8f590f7-dd77-49aa-a993-74edd539be09@github.com>

On Tue, 26 Aug 2025 08:30:23 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
>> 
>> # Diagnostic
>> 
>> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
>> 
>> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
>> 
>> In the original example:
>> 
>> public value class MyNumber {
>>     private long d0;
>>     private MyNumber(long d0) { this.d0 = d0; }
>>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
>> 
>>     private static void loop() {
>>         MyNumber dec = new MyNumber(123);
>>         for (int i = 0; i < 1_000_000_000; ++i) {
>>             dec = dec.add(i);
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         for (int i = 0; i < 10; ++i) {
>>             loop();
>>         }
>>     }
>> }
>> 
>> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
>> 
>> # Solution
>> 
>> Overall, the solution requires to improve our detection of early larval va...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove is_abstract condition

Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1531#issuecomment-3223880520

From duke at openjdk.org  Tue Aug 26 12:00:57 2025
From: duke at openjdk.org (duke)
Date: Tue, 26 Aug 2025 12:00:57 GMT
Subject: [lworld] RFR: 8361352: [lworld] Weird interaction between OSR and
 value class instances [v4]
In-Reply-To: <o16VJibdYEZtm16sxH79BC53_Hn6wppUZHn5Z_yHdQM=.c77e66a1-c34f-4835-81de-9da79b7c2418@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
 <o16VJibdYEZtm16sxH79BC53_Hn6wppUZHn5Z_yHdQM=.c77e66a1-c34f-4835-81de-9da79b7c2418@github.com>
Message-ID: <bcA_cpNbw5-BTyL60OH0wnTn07LEZuUFATghGBazUTY=.88fee132-1b27-4f4c-872b-4f87e14952f5@github.com>

On Tue, 26 Aug 2025 08:30:23 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
>> 
>> # Diagnostic
>> 
>> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
>> 
>> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
>> 
>> In the original example:
>> 
>> public value class MyNumber {
>>     private long d0;
>>     private MyNumber(long d0) { this.d0 = d0; }
>>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
>> 
>>     private static void loop() {
>>         MyNumber dec = new MyNumber(123);
>>         for (int i = 0; i < 1_000_000_000; ++i) {
>>             dec = dec.add(i);
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         for (int i = 0; i < 10; ++i) {
>>             loop();
>>         }
>>     }
>> }
>> 
>> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
>> 
>> # Solution
>> 
>> Overall, the solution requires to improve our detection of early larval va...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove is_abstract condition

@marc-chevalier 
Your change (at version 0a6f0eb2d45e26e58af70e94aaf8189f83bc0de9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1531#issuecomment-3223882594

From mchevalier at openjdk.org  Tue Aug 26 12:39:03 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 26 Aug 2025 12:39:03 GMT
Subject: [lworld] Integrated: 8361352: [lworld] Weird interaction between OSR
 and value class instances
In-Reply-To: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
References: <QLtodcTjhD9C3sGHR2-uqGWJmOJHokyyjaStPkwv2R8=.e8631cd0-7a45-4926-af70-f070155300ca@github.com>
Message-ID: <pTlme05rAaP4hwcA5r9_opCvJV3Qyn98CBd01uA7o84=.35ad8f18-e023-4d30-b5af-2d16bb5f41de@github.com>

On Fri, 22 Aug 2025 14:07:16 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> First, credit to @TobiHartmann for the diagnostic, and a lot of the solution.
> 
> # Diagnostic
> 
> According to [Strict Field Initialization JEP](https://openjdk.org/jeps/8350458), when a strict field is being initialized, it is not quite immutable, but observally immutable: at first, the field can be only set (during the early larval phase), then it can be only read (late larval or initialized phase), so the last set is the actual value one can ever observe.
> 
> The interesting part is that in early larval phase, a field can be subject to some side effects. When applied to a value object, that means that until it reaches the unrestricted state, it is not yet immutable. While being not theoretically necessary, avoiding scalarization and keeping the value object behind a reference is a convenient way to make sure that side effects are correctly applied. This strategy means that we shouldn't scalarized before reaching the unrestricted state. Normally, in C2, finding out what is early larval or not is the job of bytecode parsing, but in OSR compilation, everything about the StartOSR is not parsed, and thus some objects are soundly assumed that they might be larval, when they actually aren't. In the reported example, that leads to drastic performance difference between OSR and non OSR compilation: the second one is able to eliminate allocations since it knows more precisely when the value object can be scalarized.
> 
> In the original example:
> 
> public value class MyNumber {
>     private long d0;
>     private MyNumber(long d0) { this.d0 = d0; }
>     public MyNumber add(long v) { return new MyNumber(d0 + v); }
> 
>     private static void loop() {
>         MyNumber dec = new MyNumber(123);
>         for (int i = 0; i < 1_000_000_000; ++i) {
>             dec = dec.add(i);
>         }
>     }
> 
>     public static void main(String[] args) {
>         for (int i = 0; i < 10; ++i) {
>             loop();
>         }
>     }
> }
> 
> OSR happens in the loop in `loop`, but here `dec` is not detected to be unrestricted (so immutable, so scalarizable), so the allocation in inlined `add` still needs to happen because we need the buffer for the new `dec`. The first iteration traps at the exit of the loop (unstable if), OSR happens again, followed by a non-OSR compilation, finding correctly that `dec` can be scalarized in the loop, making the third iteration fast.
> 
> # Solution
> 
> Overall, the solution requires to improve our detection of early larval values. Since we keep parsing as-is, let's do that in `ciTypeFlow`. Th...

This pull request has now been integrated.

Changeset: bd1d97b7
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/bd1d97b7605144000a773a80e6dbc2ff923cb691
Stats:     449 lines in 12 files changed: 411 ins; 18 del; 20 mod

8361352: [lworld] Weird interaction between OSR and value class instances

Reviewed-by: thartmann

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

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

From duke at openjdk.org  Wed Aug 27 09:27:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 27 Aug 2025 09:27:56 GMT
Subject: [lworld] RFR: 8366200: Modify existing use of jimage fields to make
 space for preview mode flags
Message-ID: <IBeC6pnLbtz90if3Jm6fWCeb-ApwZ4q1CtF52qrVVnI=.624f708e-ced7-4c29-9daf-3e5a2b1f071c@github.com>

Changes jimage creation to sort any non-empty packages first in the list of package entries.

Changes imageFile.cpp to read only the lowest bit in the flag word so that other bits can later be used for preview mode.

Reviewer notes:
----
Unfortunately I cannot be 100% sure that this change has covered all the cases where the flag word is read. I only found imageFile.cpp looking at it, and all the other jimage tools I know about, such as ImageReader, ignore it completely.

The PR is "safe" in the sense that the value being written to the flag word is unchanged, and the response in imageFile.cpp to a value is unchanged. However getting this PR in does not guarantee there is no more code that does a zero/non-zero test on the flag word.

To check this as best as I can heuristically, I ran a version of the code through CI where the flag value was OR'ed with 0x80000000, meaning it was never zero. If other code were doing a simple zero/non-zero test on the flag it is hoped the this would catch it out.

I have also left any code which iterates the package entries alone (for now) because they might be given older jimage files. In order to usefully process the knowledge that "if there's a non-empty package it's listed first", it might be necessary to make a minor bump to the version number of the file jimage file so this feature can be detected.

---------
### Progress
- [x] Change must not contain extraneous whitespace

### Error
&nbsp;?? The pull request body must not be empty.



### Reviewing
<details><summary>Using <code>git</code></summary>

Checkout this PR locally: \
`$ git fetch https://git.openjdk.org/valhalla.git pull/1534/head:pull/1534` \
`$ git checkout pull/1534`

Update a local copy of the PR: \
`$ git checkout pull/1534` \
`$ git pull https://git.openjdk.org/valhalla.git pull/1534/head`

</details>
<details><summary>Using Skara CLI tools</summary>

Checkout this PR locally: \
`$ git pr checkout 1534`

View PR using the GUI difftool: \
`$ git pr show -t 1534`

</details>
<details><summary>Using diff file</summary>

Download this PR as a diff file: \
<a href="https://git.openjdk.org/valhalla/pull/1534.diff">https://git.openjdk.org/valhalla/pull/1534.diff</a>

</details>

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

Commit messages:
 - 8366200: Modify existing use of jimage fields to make space for preview mode flags

Changes: https://git.openjdk.org/valhalla/pull/1534/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1534&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366200
  Stats: 80 lines in 3 files changed: 44 ins; 15 del; 21 mod
  Patch: https://git.openjdk.org/valhalla/pull/1534.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1534/head:pull/1534

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

From vromero at openjdk.org  Wed Aug 27 12:22:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 27 Aug 2025 12:22:42 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v11]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <p54qzJmBcbpm_ImwUuEYRpJ2DeeevfU53gNsAnERs-s=.def56831-fba9-449f-b13a-5e8c0768b2a4@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - some simplifications
 - minor bug fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/5cb0f429..74945ee9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=10
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=09-10

  Stats: 49 lines in 4 files changed: 6 ins; 18 del; 25 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From duke at openjdk.org  Wed Aug 27 12:49:24 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 27 Aug 2025 12:49:24 GMT
Subject: [lworld] RFR: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
Message-ID: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>

Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.

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

Commit messages:
 - remove dead code

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

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

From coleenp at openjdk.org  Wed Aug 27 12:58:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 12:58:59 GMT
Subject: [lworld] RFR: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
References: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
Message-ID: <1SPsvHCh0ubp57jnzfwl3pfMt1xXxXY5rwsK5VNZThs=.12321911-d13b-477c-bc97-a5c681786617@github.com>

On Wed, 27 Aug 2025 12:44:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.

I see this in mainline openjdk.  Can you remove this there instead?

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

Changes requested by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1535#pullrequestreview-3159678036

From alanb at openjdk.org  Wed Aug 27 13:10:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Aug 2025 13:10:53 GMT
Subject: [lworld] RFR: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <1SPsvHCh0ubp57jnzfwl3pfMt1xXxXY5rwsK5VNZThs=.12321911-d13b-477c-bc97-a5c681786617@github.com>
References: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
 <1SPsvHCh0ubp57jnzfwl3pfMt1xXxXY5rwsK5VNZThs=.12321911-d13b-477c-bc97-a5c681786617@github.com>
Message-ID: <DWYzNO5Pev8L42IgiNqC8tDZZzlSiELgcB76crOMaz0=.e04b4842-4807-44a2-ba90-02bb4d2ddf80@github.com>

On Wed, 27 Aug 2025 12:56:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I see this in mainline openjdk. Can you remove this there instead?

Yes, it would be better to target this to main line.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1535#issuecomment-3228143060

From duke at openjdk.org  Wed Aug 27 13:39:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 27 Aug 2025 13:39:17 GMT
Subject: [lworld] RFR: 8366200: Modify existing use of jimage fields to
 make space for preview mode flags [v2]
In-Reply-To: <IBeC6pnLbtz90if3Jm6fWCeb-ApwZ4q1CtF52qrVVnI=.624f708e-ced7-4c29-9daf-3e5a2b1f071c@github.com>
References: <IBeC6pnLbtz90if3Jm6fWCeb-ApwZ4q1CtF52qrVVnI=.624f708e-ced7-4c29-9daf-3e5a2b1f071c@github.com>
Message-ID: <tcKhd41YW2M0aeaNXPIbxnj_6WATx1wHBSRlpPCvd8o=.f603286b-aca7-4c88-8170-0f945392f40f@github.com>

> Changes jimage creation to sort any non-empty packages first in the list of package entries.
> 
> Changes imageFile.cpp to read only the lowest bit in the flag word so that other bits can later be used for preview mode.
> 
> Reviewer notes:
> ----
> Unfortunately I cannot be 100% sure that this change has covered all the cases where the flag word is read. I only found imageFile.cpp looking at it, and all the other jimage tools I know about, such as ImageReader, ignore it completely.
> 
> The PR is "safe" in the sense that the value being written to the flag word is unchanged, and the response in imageFile.cpp to a value is unchanged. However getting this PR in does not guarantee there is no more code that does a zero/non-zero test on the flag word.
> 
> To check this as best as I can heuristically, I ran a version of the code through CI where the flag value was OR'ed with 0x80000000, meaning it was never zero. If other code were doing a simple zero/non-zero test on the flag it is hoped the this would catch it out.
> 
> I have also left any code which iterates the package entries alone (for now) because they might be given older jimage files. In order to usefully process the knowledge that "if there's a non-empty package it's listed first", it might be necessary to make a minor bump to the version number of the file jimage file so this feature can be detected.
> 
> ---------
> ### Progress
> - [x] Change must not contain extraneous whitespace
> 
> ### Error
> &nbsp;?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/valhalla.git pull/1534/head:pull/1534` \
> `$ git checkout pull/1534`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/1534` \
> `$ git pull https://git.openjdk.org/valhalla.git pull/1534/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 1534`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 1534`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/valhalla/pull/1534.diff">https://git.openjdk.org/valhalla/pull/1534.diff</a>
> 
> </details>

David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - 8366200: Modify existing use of jimage fields to make space for preview mode flags
 - remove dead code

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1534/files
  - new: https://git.openjdk.org/valhalla/pull/1534/files/6cd28426..5ad3d879

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

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

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

From rriggs at openjdk.org  Wed Aug 27 13:45:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Aug 2025 13:45:06 GMT
Subject: [lworld] RFR: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
References: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
Message-ID: <94IeR8QY3CjIjVpwnk3sns9KPTzZ58Isl3qq4BC7-Bw=.9caed973-7590-4233-906b-ee32985d7985@github.com>

On Wed, 27 Aug 2025 12:44:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.

Removing the dead code in the mainline can be done separately. At the moment, the noise created by the dead code is slowing down other work and the latency in sync's from mainline is a pain to deal with.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1535#issuecomment-3228264500

From rriggs at openjdk.org  Wed Aug 27 13:47:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Aug 2025 13:47:51 GMT
Subject: [lworld] RFR: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
References: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
Message-ID: <OkbdKO9_B_I_Jjd_cN2ypVWzYWWSQVKovED4DdRszfk=.eb66cd4a-b5e1-44d6-beea-4878702b5fdc@github.com>

On Wed, 27 Aug 2025 12:44:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.

Removing dead code looks good to me.
It should be done in the mainline too.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1535#pullrequestreview-3159870784

From duke at openjdk.org  Wed Aug 27 14:14:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 27 Aug 2025 14:14:51 GMT
Subject: [lworld] RFR: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <DWYzNO5Pev8L42IgiNqC8tDZZzlSiELgcB76crOMaz0=.e04b4842-4807-44a2-ba90-02bb4d2ddf80@github.com>
References: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
 <1SPsvHCh0ubp57jnzfwl3pfMt1xXxXY5rwsK5VNZThs=.12321911-d13b-477c-bc97-a5c681786617@github.com>
 <DWYzNO5Pev8L42IgiNqC8tDZZzlSiELgcB76crOMaz0=.e04b4842-4807-44a2-ba90-02bb4d2ddf80@github.com>
Message-ID: <8o7yevVxhKnEDBNMpPVjMKCv_Vq1nnJUSQR7Ev426Qs=.cb224ece-a45c-4145-8c9c-c787c69dd718@github.com>

On Wed, 27 Aug 2025 13:08:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I see this in mainline openjdk. Can you remove this there instead?

I can make a 2nd PR for also doing it in mainline, or patch this over once it's settled here (and it's really certain nobody was using the code). Let me know which you prefer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1535#issuecomment-3228382044

From rriggs at openjdk.org  Wed Aug 27 16:43:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Aug 2025 16:43:56 GMT
Subject: [lworld] RFR: 8366200: Modify existing use of jimage fields to
 make space for preview mode flags [v2]
In-Reply-To: <tcKhd41YW2M0aeaNXPIbxnj_6WATx1wHBSRlpPCvd8o=.f603286b-aca7-4c88-8170-0f945392f40f@github.com>
References: <IBeC6pnLbtz90if3Jm6fWCeb-ApwZ4q1CtF52qrVVnI=.624f708e-ced7-4c29-9daf-3e5a2b1f071c@github.com>
 <tcKhd41YW2M0aeaNXPIbxnj_6WATx1wHBSRlpPCvd8o=.f603286b-aca7-4c88-8170-0f945392f40f@github.com>
Message-ID: <9jTqFyIp5chLXhtxIiCGB1tQQKN9B9Dx__bQm7653vM=.462621dd-20a7-4682-ae83-14204e6fee09@github.com>

On Wed, 27 Aug 2025 13:39:17 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Changes jimage creation to sort any non-empty packages first in the list of package entries.
>> 
>> Changes imageFile.cpp to read only the lowest bit in the flag word so that other bits can later be used for preview mode.
>> 
>> Reviewer notes:
>> ----
>> Unfortunately I cannot be 100% sure that this change has covered all the cases where the flag word is read. I only found imageFile.cpp looking at it, and all the other jimage tools I know about, such as ImageReader, ignore it completely.
>> 
>> The PR is "safe" in the sense that the value being written to the flag word is unchanged, and the response in imageFile.cpp to a value is unchanged. However getting this PR in does not guarantee there is no more code that does a zero/non-zero test on the flag word.
>> 
>> To check this as best as I can heuristically, I ran a version of the code through CI where the flag value was OR'ed with 0x80000000, meaning it was never zero. If other code were doing a simple zero/non-zero test on the flag it is hoped the this would catch it out.
>> 
>> I have also left any code which iterates the package entries alone (for now) because they might be given older jimage files. In order to usefully process the knowledge that "if there's a non-empty package it's listed first", it might be necessary to make a minor bump to the version number of the file jimage file so this feature can be detected.
>> 
>> ---------
>> ### Progress
>> - [x] Change must not contain extraneous whitespace
>> 
>> ### Error
>> &nbsp;?? The pull request body must not be empty.
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/valhalla.git pull/1534/head:pull/1534` \
>> `$ git checkout pull/1534`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/1534` \
>> `$ git pull https://git.openjdk.org/valhalla.git pull/1534/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 1534`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 1534`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/valhalla/pull/1534.diff">https://git.openjdk.org/valhalla/pull/1534.diff</a>
>> 
>> </details>
>
> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - 8366200: Modify existing use of jimage fields to make space for preview mode flags
>  - remove dead code

looks ok.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 161:

> 159:         }
> 160: 
> 161:         Stream<PackageReference> sortedRefs() {

Method name: "Refs" is pretty generic, in a class named ResourceTree.
How about sortedPackageRefs().

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1534#pullrequestreview-3160746477
PR Review Comment: https://git.openjdk.org/valhalla/pull/1534#discussion_r2304623892

From coleenp at openjdk.org  Wed Aug 27 19:02:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 27 Aug 2025 19:02:56 GMT
Subject: [lworld] RFR: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
References: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
Message-ID: <voXn8boQTVyMhL8hnfQNjQGdqpN5i0TvqvwLSlNa9yw=.9e0e1178-3cf7-41b4-9a8e-64aeca4541c5@github.com>

On Wed, 27 Aug 2025 12:44:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.

Thanks for also doing this in mainline.

Marked as reviewed by coleenp (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1535#pullrequestreview-3161398473
PR Review: https://git.openjdk.org/valhalla/pull/1535#pullrequestreview-3161399605

From rriggs at openjdk.org  Wed Aug 27 19:46:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Aug 2025 19:46:29 GMT
Subject: [lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and
 ConcurrentHashmap
Message-ID: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>

As observed in [JDK-8366043](https://bugs.openjdk.org/browse/JDK-8366043) [lworld] (LIFE = Legacy Idiom For Equality) causes performance regressions.
Updating HashMap and ConcurrentHashMap to use `java.util.Objects.equals` will make it easier to measure performance of options that remove or modify the use of `==`

Replace constructs like:

-                        ((k = e.key) == key || (key != null && key.equals(k))))
with:
+                        Objects.equals(key, k))


The changes in ConcurrentHashMap are a bit different due to the use of null as a sentinel.

The order of arguments to the .equals methods must remain the same to ensure compatibility.

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

Commit messages:
 - 8366214: [lworld] Use Objects.equals in HashMap and ConcurrentHashmap

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

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

From duke at openjdk.org  Wed Aug 27 21:39:57 2025
From: duke at openjdk.org (duke)
Date: Wed, 27 Aug 2025 21:39:57 GMT
Subject: [lworld] RFR: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
References: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
Message-ID: <4EHmStOkCqDWfalJbtNvxsDmBdi7Rc00Gt-miLVyDK4=.fe678b5a-9a1f-4f08-b502-e59cd7bcd265@github.com>

On Wed, 27 Aug 2025 12:44:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.

@david-beaumont 
Your change (at version 1c6d626ff1c760835178fb306434f37a50dc2746) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1535#issuecomment-3229822954

From liach at openjdk.org  Wed Aug 27 22:26:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 27 Aug 2025 22:26:49 GMT
Subject: [lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and
 ConcurrentHashmap
In-Reply-To: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
References: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
Message-ID: <ELYVM5apJvtLBz03OOXiPiMFF8wo6laqZgXjgmxk-lo=.dc1efb74-8766-4437-ae03-72580d542aa1@github.com>

On Wed, 27 Aug 2025 19:40:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> As observed in [JDK-8366043](https://bugs.openjdk.org/browse/JDK-8366043) [lworld] (LIFE = Legacy Idiom For Equality) causes performance regressions.
> Updating HashMap and ConcurrentHashMap to use `java.util.Objects.equals` will make it easier to measure performance of options that remove or modify the use of `==`
> 
> Replace constructs like:
> 
> -                        ((k = e.key) == key || (key != null && key.equals(k))))
> with:
> +                        Objects.equals(key, k))
> 
> 
> The changes in ConcurrentHashMap are a bit different due to the use of null as a sentinel.
> 
> The order of arguments to the .equals methods must remain the same to ensure compatibility.

src/java.base/share/classes/java/util/HashMap.java line 2026:

> 2024:                 else if (ph < h)
> 2025:                     p = pr;
> 2026:                 else if (Objects.equals(k, (pk = p.key)))

Stylistic: don't need parentheses around `pk = p.key`

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 669:

> 667:                     (k = (e = (Map.Entry<?,?>)o).getKey()) != null &&
> 668:                     (v = e.getValue()) != null &&
> 669:                     (Objects.equals(k, key)) &&

`k.equals(key)` should be sufficient here.

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 682:

> 680:                     K ek;
> 681:                     if (e.hash == h &&
> 682:                         (ek = e.key) != null && Objects.equals(k, ek))

Looking at the code in HashMap, I think you can just use `Objects.equals(k, ek = e.key)`, or just `k.equals(ek = e.key)` because `Object::equals` is supposed to return false on null.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2305408280
PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2305407382
PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2305411815

From duke at openjdk.org  Thu Aug 28 00:47:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 28 Aug 2025 00:47:51 GMT
Subject: [lworld] Integrated: 8366239: Remove 'package_to_module' function from
 imageFile.cpp
In-Reply-To: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
References: <xh_wLXeEbSZsWuYr0QY45dYlsDCBOomilJwuYgZrs6o=.9cddf402-c7e2-453d-804a-7b6f27722241@github.com>
Message-ID: <mm39X71dVhi_LfheLJlaQ7txUG4p5tP3cWJGkDAymZg=.f765ea8c-0283-412d-b713-67ce9573f849@github.com>

On Wed, 27 Aug 2025 12:44:06 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing the 'package_to_module' function from imageFile.cpp and the associated JNI export.
> This code isn't used or referenced from anywhere, and removing it makes adapting the package flags for use with preview mode simpler.

This pull request has now been integrated.

Changeset: 3034909f
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3034909ffb994d37fc3fc7665304370921a97422
Stats:     139 lines in 4 files changed: 0 ins; 133 del; 6 mod

8366239: Remove 'package_to_module' function from imageFile.cpp

Reviewed-by: coleenp, rriggs

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

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

From vromero at openjdk.org  Thu Aug 28 03:15:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 03:15:32 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v12]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <2dkrYm8BIw15vxCD5uUgjzPOnsfZfoGyxu9ewU3DmDg=.1769aeda-35f8-49e9-a7dc-028e0fba25e0@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - code simplifications
 - adding documentation

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/74945ee9..3965918c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=11
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=10-11

  Stats: 53 lines in 1 file changed: 9 ins; 24 del; 20 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From duke at openjdk.org  Thu Aug 28 04:21:57 2025
From: duke at openjdk.org (duke)
Date: Thu, 28 Aug 2025 04:21:57 GMT
Subject: [lworld] Withdrawn: 8359370: [lworld] allow instance fields of
 identity classes to be readable in the prologue phase
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <loRNQjwjafcavxI3yoWQ9kBZUWWK9FWaWREJDNbQ2KA=.2a32fa7c-86ee-4fc6-9ab4-b7cd5821008a@github.com>

On Fri, 20 Jun 2025 23:03:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA

This pull request has been closed without being integrated.

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

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

From vromero at openjdk.org  Thu Aug 28 12:55:05 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 12:55:05 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  minor diff

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/3965918c..ad1fb805

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=12
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=11-12

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

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

From rriggs at openjdk.org  Thu Aug 28 13:20:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 28 Aug 2025 13:20:04 GMT
Subject: [lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and
 ConcurrentHashmap
In-Reply-To: <ELYVM5apJvtLBz03OOXiPiMFF8wo6laqZgXjgmxk-lo=.dc1efb74-8766-4437-ae03-72580d542aa1@github.com>
References: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
 <ELYVM5apJvtLBz03OOXiPiMFF8wo6laqZgXjgmxk-lo=.dc1efb74-8766-4437-ae03-72580d542aa1@github.com>
Message-ID: <pmd5ppNJUUD6aE2a7ynJBvbJajmliWl6uZnrlmRhylU=.034ca0bf-9a13-4f87-9623-dc653a991d67@github.com>

On Wed, 27 Aug 2025 22:18:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As observed in [JDK-8366043](https://bugs.openjdk.org/browse/JDK-8366043) [lworld] (LIFE = Legacy Idiom For Equality) causes performance regressions.
>> Updating HashMap and ConcurrentHashMap to use `java.util.Objects.equals` will make it easier to measure performance of options that remove or modify the use of `==`
>> 
>> Replace constructs like:
>> 
>> -                        ((k = e.key) == key || (key != null && key.equals(k))))
>> with:
>> +                        Objects.equals(key, k))
>> 
>> 
>> The changes in ConcurrentHashMap are a bit different due to the use of null as a sentinel.
>> 
>> The order of arguments to the .equals methods must remain the same to ensure compatibility.
>
> src/java.base/share/classes/java/util/HashMap.java line 2026:
> 
>> 2024:                 else if (ph < h)
>> 2025:                     p = pr;
>> 2026:                 else if (Objects.equals(k, (pk = p.key)))
> 
> Stylistic: don't need parentheses around `pk = p.key`

Stylistically, it calls attention to the assignment in the middle of an expression.

> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 669:
> 
>> 667:                     (k = (e = (Map.Entry<?,?>)o).getKey()) != null &&
>> 668:                     (v = e.getValue()) != null &&
>> 669:                     (Objects.equals(k, key)) &&
> 
> `k.equals(key)` should be sufficient here.

Maintaining consistency with continuation of the return value.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2307390334
PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2307392520

From rriggs at openjdk.org  Thu Aug 28 13:34:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 28 Aug 2025 13:34:59 GMT
Subject: [lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and
 ConcurrentHashmap
In-Reply-To: <ELYVM5apJvtLBz03OOXiPiMFF8wo6laqZgXjgmxk-lo=.dc1efb74-8766-4437-ae03-72580d542aa1@github.com>
References: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
 <ELYVM5apJvtLBz03OOXiPiMFF8wo6laqZgXjgmxk-lo=.dc1efb74-8766-4437-ae03-72580d542aa1@github.com>
Message-ID: <3Fgz1NtEiXdghFV8rJ1TOC3cjFoqrIroqxL9r1j3tfI=.1bd45473-e2e7-4d22-b59e-d6327759983c@github.com>

On Wed, 27 Aug 2025 22:21:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As observed in [JDK-8366043](https://bugs.openjdk.org/browse/JDK-8366043) [lworld] (LIFE = Legacy Idiom For Equality) causes performance regressions.
>> Updating HashMap and ConcurrentHashMap to use `java.util.Objects.equals` will make it easier to measure performance of options that remove or modify the use of `==`
>> 
>> Replace constructs like:
>> 
>> -                        ((k = e.key) == key || (key != null && key.equals(k))))
>> with:
>> +                        Objects.equals(key, k))
>> 
>> 
>> The changes in ConcurrentHashMap are a bit different due to the use of null as a sentinel.
>> 
>> The order of arguments to the .equals methods must remain the same to ensure compatibility.
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 682:
> 
>> 680:                     K ek;
>> 681:                     if (e.hash == h &&
>> 682:                         (ek = e.key) != null && Objects.equals(k, ek))
> 
> Looking at the code in HashMap, I think you can just use `Objects.equals(k, ek = e.key)`, or just `k.equals(ek = e.key)` because `Object::equals` is supposed to return false on null.

HashMap allows null keys and that is handled separately in each case, not by the `equals` method.
"supposed to" is not sufficient when compatibility is concerned.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2307434641

From liach at openjdk.org  Thu Aug 28 13:41:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Aug 2025 13:41:59 GMT
Subject: [lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and
 ConcurrentHashmap
In-Reply-To: <3Fgz1NtEiXdghFV8rJ1TOC3cjFoqrIroqxL9r1j3tfI=.1bd45473-e2e7-4d22-b59e-d6327759983c@github.com>
References: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
 <ELYVM5apJvtLBz03OOXiPiMFF8wo6laqZgXjgmxk-lo=.dc1efb74-8766-4437-ae03-72580d542aa1@github.com>
 <3Fgz1NtEiXdghFV8rJ1TOC3cjFoqrIroqxL9r1j3tfI=.1bd45473-e2e7-4d22-b59e-d6327759983c@github.com>
Message-ID: <JMlvyfSj4esvpSAoIv6dOY9V8251Z4axnsgOwHhGtnw=.f9029456-fb1d-4dcc-8a25-f427b3f59470@github.com>

On Thu, 28 Aug 2025 13:32:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 682:
>> 
>>> 680:                     K ek;
>>> 681:                     if (e.hash == h &&
>>> 682:                         (ek = e.key) != null && Objects.equals(k, ek))
>> 
>> Looking at the code in HashMap, I think you can just use `Objects.equals(k, ek = e.key)`, or just `k.equals(ek = e.key)` because `Object::equals` is supposed to return false on null.
>
> HashMap allows null keys and that is handled separately in each case, not by the `equals` method.
> "supposed to" is not sufficient when compatibility is concerned.

I think your current logic differs when `e.key == null` and `k == null` - previously it evaluates to true, now this test fails.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2307452667

From duke at openjdk.org  Thu Aug 28 14:32:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 28 Aug 2025 14:32:55 GMT
Subject: [lworld] RFR: 8366200: Modify existing use of jimage fields to
 make space for preview mode flags [v2]
In-Reply-To: <9jTqFyIp5chLXhtxIiCGB1tQQKN9B9Dx__bQm7653vM=.462621dd-20a7-4682-ae83-14204e6fee09@github.com>
References: <IBeC6pnLbtz90if3Jm6fWCeb-ApwZ4q1CtF52qrVVnI=.624f708e-ced7-4c29-9daf-3e5a2b1f071c@github.com>
 <tcKhd41YW2M0aeaNXPIbxnj_6WATx1wHBSRlpPCvd8o=.f603286b-aca7-4c88-8170-0f945392f40f@github.com>
 <9jTqFyIp5chLXhtxIiCGB1tQQKN9B9Dx__bQm7653vM=.462621dd-20a7-4682-ae83-14204e6fee09@github.com>
Message-ID: <JAp-zZtf2YKJVdEu_rCmUzHLoJ66ty66qtI_5pq7r9c=.159fc89c-ce40-4e8d-8ec5-612282794d66@github.com>

On Wed, 27 Aug 2025 16:39:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
>> 
>>  - 8366200: Modify existing use of jimage fields to make space for preview mode flags
>>  - remove dead code
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 161:
> 
>> 159:         }
>> 160: 
>> 161:         Stream<PackageReference> sortedRefs() {
> 
> Method name: "Refs" is pretty generic, in a class named ResourceTree.
> How about sortedPackageRefs().

I mean it's in a class called `PackageNode` really (and isn't public), but I take your point.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1534#discussion_r2307595731

From duke at openjdk.org  Thu Aug 28 14:32:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 28 Aug 2025 14:32:55 GMT
Subject: [lworld] Withdrawn: 8366200: Modify existing use of jimage fields to
 make space for preview mode flags
In-Reply-To: <IBeC6pnLbtz90if3Jm6fWCeb-ApwZ4q1CtF52qrVVnI=.624f708e-ced7-4c29-9daf-3e5a2b1f071c@github.com>
References: <IBeC6pnLbtz90if3Jm6fWCeb-ApwZ4q1CtF52qrVVnI=.624f708e-ced7-4c29-9daf-3e5a2b1f071c@github.com>
Message-ID: <ZjmLueoVQnKchzDMdxDGsekJkGs3W386h75yYOW7ZDA=.e7b64bb6-1d1f-46ca-8afd-824e9d08b156@github.com>

On Wed, 27 Aug 2025 01:19:17 GMT, David Beaumont <duke at openjdk.org> wrote:

> Changes jimage creation to sort any non-empty packages first in the list of package entries.
> 
> Changes imageFile.cpp to read only the lowest bit in the flag word so that other bits can later be used for preview mode.
> 
> Reviewer notes:
> ----
> Unfortunately I cannot be 100% sure that this change has covered all the cases where the flag word is read. I only found imageFile.cpp looking at it, and all the other jimage tools I know about, such as ImageReader, ignore it completely.
> 
> The PR is "safe" in the sense that the value being written to the flag word is unchanged, and the response in imageFile.cpp to a value is unchanged. However getting this PR in does not guarantee there is no more code that does a zero/non-zero test on the flag word.
> 
> To check this as best as I can heuristically, I ran a version of the code through CI where the flag value was OR'ed with 0x80000000, meaning it was never zero. If other code were doing a simple zero/non-zero test on the flag it is hoped the this would catch it out.
> 
> I have also left any code which iterates the package entries alone (for now) because they might be given older jimage files. In order to usefully process the knowledge that "if there's a non-empty package it's listed first", it might be necessary to make a minor bump to the version number of the file jimage file so this feature can be detected.
> 
> ---------
> ### Progress
> - [x] Change must not contain extraneous whitespace
> 
> ### Error
> &nbsp;?? The pull request body must not be empty.
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/valhalla.git pull/1534/head:pull/1534` \
> `$ git checkout pull/1534`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/1534` \
> `$ git pull https://git.openjdk.org/valhalla.git pull/1534/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 1534`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 1534`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/valhalla/pull/1534.diff">https://git.openjdk.org/valhalla/pull/1534.diff</a>
> 
> </details>

This pull request has been closed without being integrated.

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

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

From mcimadamore at openjdk.org  Thu Aug 28 16:28:05 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Aug 2025 16:28:05 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
Message-ID: <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>

On Thu, 28 Aug 2025 12:55:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor diff

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1261:

> 1259:                     for (JCTree stat : tree.body.stats) {
> 1260:                         prologueCode.add(stat);
> 1261:                         /* gather all the stats in the body until a `super` or `this` constructor invocation is found,

I understand that you  wanted to simplify the visitor -- but doing a linear pass on the constructor and creating a new list of statements is also kind of expensive -- maybe when we're done with this change we can see if there's a way to set a flag on the visitor to shortcircuit the analysis after the super call is found.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 971:

> 969:     public record SymAndTree(Symbol symbol, JCTree tree) {}
> 970: 
> 971:     public static java.util.List<SymAndTree> symbolsFor(List<JCTree> nodes) {

Is the use of `j.u.List` deliberate here?

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 982:

> 980:     }
> 981: 
> 982:     public static java.util.List<SymAndTree> symbolsFor(JCTree node) {

Can you provide some examples on what this method is supposed to do? E.g. example input and output?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307921664
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307925310
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307929864

From mcimadamore at openjdk.org  Thu Aug 28 16:31:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Aug 2025 16:31:52 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
Message-ID: <TRIjN4f62QEBj93JgpUvkSDY8AnbPeNSwFx_wsC1Qhk=.ae86ae86-9ad0-4988-8264-ce93fabb08f8@github.com>

On Thu, 28 Aug 2025 12:55:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor diff

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1302:

> 1300:         public void visitClassDef(JCClassDecl classDecl) {
> 1301:             super.visitClassDef(classDecl);
> 1302:             classDeclAndLambdaHelper(TreeInfo.symbolsFor(classDecl.defs));

Does this look for early references in all the symbols referenced inside the class?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307939680

From mcimadamore at openjdk.org  Thu Aug 28 16:41:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Aug 2025 16:41:06 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <TRIjN4f62QEBj93JgpUvkSDY8AnbPeNSwFx_wsC1Qhk=.ae86ae86-9ad0-4988-8264-ce93fabb08f8@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <TRIjN4f62QEBj93JgpUvkSDY8AnbPeNSwFx_wsC1Qhk=.ae86ae86-9ad0-4988-8264-ce93fabb08f8@github.com>
Message-ID: <il5Mhy1iuMwVuP3om8AupD1kns0zBHhZ21srHRCQ5Rk=.bbce7cef-7ca5-492d-a3e9-3a9bf21d5864@github.com>

On Thu, 28 Aug 2025 16:29:21 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 diff
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1302:
> 
>> 1300:         public void visitClassDef(JCClassDecl classDecl) {
>> 1301:             super.visitClassDef(classDecl);
>> 1302:             classDeclAndLambdaHelper(TreeInfo.symbolsFor(classDecl.defs));
> 
> Does this look for early references in all the symbols referenced inside the class?

Also, why do we use `symbolsFor` instead of recursing this this visitor?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307951826

From mcimadamore at openjdk.org  Thu Aug 28 16:41:06 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Aug 2025 16:41:06 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
Message-ID: <PQztxKSMv5Bs18n2klHX2UrsO0ZYEhH0ZAq6bX_JcMQ=.74ed3ddf-3b3d-4cc2-ad34-d98b1bba5e41@github.com>

On Thu, 28 Aug 2025 12:55:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor diff

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1309:

> 1307:                 Symbol sym = symAndTree.symbol();
> 1308:                 JCTree tree = TreeInfo.skipParens(symAndTree.tree());
> 1309:                 if (sym.kind == VAR &&

Why doesn't this call analyze symbol?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1420:

> 1418:             Symbol sym = TreeInfo.symbolFor(tree);
> 1419:             if (sym != null) {
> 1420:                 if (!sym.isStatic() && !isMethodArgument(tree)) {

if you have a `sym`, in order to understand if something is a method parameter (not argument?) don't you need to check if `sym.owner == MTH` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1423:

> 1421:                     if (sym.name == names._this || sym.name == names._super) {
> 1422:                         // are we seeing something like `this` or `CurrentClass.this` or `SuperClass.super::foo`?
> 1423:                         if (TreeInfo.isExplicitThisReference(

Do we always report an error when seeing `Foo.this` ? What if we're not inside the prologue of `Foo` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1564:

> 1562:                         if (v.owner.kind == TYP && !v.isStatic() && v.isStrict()) {
> 1563:                             // strict field initializers are inlined in constructor's prologues
> 1564:                             CtorPrologueVisitor ctorPrologueVisitor = new CtorPrologueVisitor(initEnv);

Nice reuse

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307950873
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307957523
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307959699
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307961723

From mcimadamore at openjdk.org  Thu Aug 28 16:46:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Aug 2025 16:46:02 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
Message-ID: <J2lz_vwde-clBcR2Q6aAaN6rn6Khn6Vq_nHsfEO7seo=.44dc2d6b-faec-446a-8edf-13dc32bc78ef@github.com>

On Thu, 28 Aug 2025 12:55:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor diff

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1363:

> 1361:                 try {
> 1362:                     analyzingSelect = true;
> 1363:                     super.visitSelect(tree);

Can't we cut recursion here (instead of using `analyzingSelect` ? That's also what the new `TreeInfo.symbolsFor` does. In general it seems like these two visitors are trying to do similar things but are not 100% aligned?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2307975786

From liach at openjdk.org  Thu Aug 28 16:54:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Aug 2025 16:54:48 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release need
 futher work for Valhalla (IDENTITY and SUPER)
Message-ID: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>

Improve access flag reflection for preview on/off.

In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.

There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.

No new test failures.

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

Commit messages:
 - Stage
 - Stage
 - Trivial
 - Unit test
 - Fix identity flag missing for preview inner classes
 - Stage
 - Fixes
 - Make use of current preview features

Changes: https://git.openjdk.org/valhalla/pull/1533/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1533&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364095
  Stats: 336 lines in 43 files changed: 189 ins; 81 del; 66 mod
  Patch: https://git.openjdk.org/valhalla/pull/1533.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1533/head:pull/1533

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

From liach at openjdk.org  Thu Aug 28 16:54:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Aug 2025 16:54:49 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER)
In-Reply-To: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
Message-ID: <jD5oyUKjYg-2h2tPNvpWr_5gso_BLziAv6F4mimS600=.dcb85178-20ec-4a23-964f-36a276936272@github.com>

On Mon, 25 Aug 2025 22:00:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Improve access flag reflection for preview on/off.
> 
> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
> 
> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
> 
> No new test failures.

src/java.base/share/classes/jdk/internal/classfile/impl/AccessFlagsImpl.java line 58:

> 56:     public Set<AccessFlag> flags() {
> 57:         if (flags == null)
> 58:             flags = AccessFlag.maskToAccessFlags(flagsMask, location, ClassFileFormatVersion.CURRENT_PREVIEW_FEATURES);

Temporary - I will convert this to be CFFV-context-aware later, which is not a trivial change to the ClassFile API.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2307981822

From vromero at openjdk.org  Thu Aug 28 17:25:59 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 17:25:59 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <PQztxKSMv5Bs18n2klHX2UrsO0ZYEhH0ZAq6bX_JcMQ=.74ed3ddf-3b3d-4cc2-ad34-d98b1bba5e41@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <PQztxKSMv5Bs18n2klHX2UrsO0ZYEhH0ZAq6bX_JcMQ=.74ed3ddf-3b3d-4cc2-ad34-d98b1bba5e41@github.com>
Message-ID: <Mx-ePJ05GfDuUDPo_wWZ9mg1JSIEA1T0S5LNEmRBxow=.140c4088-7edd-475b-8782-46b7f71523ff@github.com>

On Thu, 28 Aug 2025 16:36:25 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 diff
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1420:
> 
>> 1418:             Symbol sym = TreeInfo.symbolFor(tree);
>> 1419:             if (sym != null) {
>> 1420:                 if (!sym.isStatic() && !isMethodArgument(tree)) {
> 
> if you have a `sym`, in order to understand if something is a method parameter (not argument?) don't you need to check if `sym.owner == MTH` ?

this is for cases when we have an argument that is for example of the same type as the current class so like:

class Test {
    String s;
    
    Test(Test t) {
        // the owner of s is Test not MTH so we need to check what is the qualifier for s which at the end is the argument
        // `t` so we ignore it
        String s1 = t.s;
        super();
    }
}

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2308053835

From vromero at openjdk.org  Thu Aug 28 17:40:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 17:40:55 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <PQztxKSMv5Bs18n2klHX2UrsO0ZYEhH0ZAq6bX_JcMQ=.74ed3ddf-3b3d-4cc2-ad34-d98b1bba5e41@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <PQztxKSMv5Bs18n2klHX2UrsO0ZYEhH0ZAq6bX_JcMQ=.74ed3ddf-3b3d-4cc2-ad34-d98b1bba5e41@github.com>
Message-ID: <Wm5tz_JOcLzapGNsAwATnR9bKE5pbwo6Me9MDdz6YS0=.c1b5e737-cc1a-49ad-a6c1-2adc012bc849@github.com>

On Thu, 28 Aug 2025 16:37:22 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 diff
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1423:
> 
>> 1421:                     if (sym.name == names._this || sym.name == names._super) {
>> 1422:                         // are we seeing something like `this` or `CurrentClass.this` or `SuperClass.super::foo`?
>> 1423:                         if (TreeInfo.isExplicitThisReference(
> 
> Do we always report an error when seeing `Foo.this` ? What if we're not inside the prologue of `Foo` ?

all the code we analyze in this visitor is in the prologue, this is why we pre-select what code we will see

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2308100999

From vromero at openjdk.org  Thu Aug 28 18:22:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 18:22:52 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
Message-ID: <UOOBVnoopm2cvkOYAfOun84tHydXygcZweeR4C1Kaes=.5ef22ca8-cd9d-4534-94f6-e5fb10391a2a@github.com>

On Thu, 28 Aug 2025 16:23:22 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 diff
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 971:
> 
>> 969:     public record SymAndTree(Symbol symbol, JCTree tree) {}
>> 970: 
>> 971:     public static java.util.List<SymAndTree> symbolsFor(List<JCTree> nodes) {
> 
> Is the use of `j.u.List` deliberate here?

yes, I think the `addAll` method is faster than our list

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2308109661

From vromero at openjdk.org  Thu Aug 28 20:16:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 20:16:55 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v14]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <8KXMiidaq89DVvhLYQK_d5E8axCf79J0Fz7Jw6ohpSE=.2f37cfee-fad7-46a6-bd04-ff3963eb4dad@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/ad1fb805..29fc914e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=13
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=12-13

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

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

From vromero at openjdk.org  Thu Aug 28 20:23:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 20:23:02 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <J2lz_vwde-clBcR2Q6aAaN6rn6Khn6Vq_nHsfEO7seo=.44dc2d6b-faec-446a-8edf-13dc32bc78ef@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <J2lz_vwde-clBcR2Q6aAaN6rn6Khn6Vq_nHsfEO7seo=.44dc2d6b-faec-446a-8edf-13dc32bc78ef@github.com>
Message-ID: <BsIGf8y7HFIqivqAF84H9gFbdXeQ7zXnbu_UDgFJ248=.b7f2a9c9-0281-4514-a518-869c0472ad95@github.com>

On Thu, 28 Aug 2025 16:43:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor diff
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1363:
> 
>> 1361:                 try {
>> 1362:                     analyzingSelect = true;
>> 1363:                     super.visitSelect(tree);
> 
> Can't we cut recursion here (instead of using `analyzingSelect` ? That's also what the new `TreeInfo.symbolsFor` does. In general it seems like these two visitors are trying to do similar things but are not 100% aligned?

if one has a complex select like for example: `new SuperInitFails(){}.x` it is still necessary to look inside and see if there are some forbidden accesses

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2308451043

From vromero at openjdk.org  Thu Aug 28 20:27:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 20:27:06 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  removing unnecessary imports

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/29fc914e..48a47133

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=14
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=13-14

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

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

From vromero at openjdk.org  Thu Aug 28 20:27:07 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 20:27:07 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v14]
In-Reply-To: <8KXMiidaq89DVvhLYQK_d5E8axCf79J0Fz7Jw6ohpSE=.2f37cfee-fad7-46a6-bd04-ff3963eb4dad@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <8KXMiidaq89DVvhLYQK_d5E8axCf79J0Fz7Jw6ohpSE=.2f37cfee-fad7-46a6-bd04-ff3963eb4dad@github.com>
Message-ID: <n6WqTr_JfXMPacpUAR98A7SzvBMdFAvY-x_yju-aArQ=.a3e3059c-3708-4601-b366-4c3b5825e6d8@github.com>

On Thu, 28 Aug 2025 20:16:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

added a new iteration that removes the new visitor at TreeInfo, thanks for the comments so far!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1523#issuecomment-3234833482

From vromero at openjdk.org  Thu Aug 28 20:35:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Aug 2025 20:35:51 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
Message-ID: <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>

On Thu, 28 Aug 2025 16:21:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor diff
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1261:
> 
>> 1259:                     for (JCTree stat : tree.body.stats) {
>> 1260:                         prologueCode.add(stat);
>> 1261:                         /* gather all the stats in the body until a `super` or `this` constructor invocation is found,
> 
> I understand that you  wanted to simplify the visitor -- but doing a linear pass on the constructor and creating a new list of statements is also kind of expensive -- maybe when we're done with this change we can see if there's a way to set a flag on the visitor to shortcircuit the analysis after the super call is found.

I think I like the trade-off, we could try to infer if a constructor invocation corresponds to the class we are interested in. Like for example analyzing the symbol associated to a `super` or `this` invocation. But for erroneous invocations the symbol could be null. So what to do when we find a null symbol? We would have no clues I think.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2308478876

From coleenp at openjdk.org  Thu Aug 28 21:18:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 28 Aug 2025 21:18:00 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER)
In-Reply-To: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
Message-ID: <hL12NblxUZZKU23Q8X3mnvMppUCYULg42OAlFvO5P5Y=.a54ecce0-e1c4-4908-a1f4-72278b294d72@github.com>

On Mon, 25 Aug 2025 22:00:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Improve access flag reflection for preview on/off.
> 
> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
> 
> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
> 
> No new test failures.

test/langtools/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerAnnotationTest.java line 29:

> 27:  * @summary Testing InnerClasses_attribute of inner annotations in inner annotation.
> 28:  * @library /tools/lib /tools/javac/lib ../lib
> 29:  * @enablePreview

I think you should update the copyrights in these files.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2308570640

From liach at openjdk.org  Thu Aug 28 23:03:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Aug 2025 23:03:11 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
Message-ID: <Avfg0PVdwWlAtuLdVYsESArMco0tGSu4tyCKvDi7-vs=.2c44ae60-27e7-48e3-a94f-d7a0df1630c1@github.com>

> Improve access flag reflection for preview on/off.
> 
> In this process, I noted javac is incorrectly injecting ACC_IDENTITY to 69.0 class' `InnerClasses` attribute and fixed that.
> 
> There is still some inconsistency, such as implying ACC_IDENTITY when preview is on for classes. Don't know if we have discussed on this yet.
> 
> No new test failures.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Years

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1533/files
  - new: https://git.openjdk.org/valhalla/pull/1533/files/f2f3d44f..62ed7b13

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

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

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

From liach at openjdk.org  Thu Aug 28 23:03:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Aug 2025 23:03:12 GMT
Subject: [lworld] RFR: 8364095: [lworld] AccessFlags location and release
 need futher work for Valhalla (IDENTITY and SUPER) [v2]
In-Reply-To: <hL12NblxUZZKU23Q8X3mnvMppUCYULg42OAlFvO5P5Y=.a54ecce0-e1c4-4908-a1f4-72278b294d72@github.com>
References: <0qaCEzpMQCNH2ZdJsJqm0r3CSrhzvWLQWwjrVCXTjcs=.0260c0ed-607c-4946-8ec7-ed233287d188@github.com>
 <hL12NblxUZZKU23Q8X3mnvMppUCYULg42OAlFvO5P5Y=.a54ecce0-e1c4-4908-a1f4-72278b294d72@github.com>
Message-ID: <VWwnt5hcnglmu7QMvpmi1bG9gf3jSm2Uzj_ieeAcM2c=.6b383758-8db7-4fc1-9b80-05c0ac0a8c61@github.com>

On Thu, 28 Aug 2025 21:14:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Years
>
> test/langtools/tools/javac/classfiles/attributes/innerclasses/InnerAnnotationsInInnerAnnotationTest.java line 29:
> 
>> 27:  * @summary Testing InnerClasses_attribute of inner annotations in inner annotation.
>> 28:  * @library /tools/lib /tools/javac/lib ../lib
>> 29:  * @enablePreview
> 
> I think you should update the copyrights in these files.

Good point. [Updated the copyright script](https://github.com/openjdk/jdk/pull/26998) to work for valhalla and done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1533#discussion_r2308719125

From rriggs at openjdk.org  Fri Aug 29 03:23:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 29 Aug 2025 03:23:54 GMT
Subject: [lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and
 ConcurrentHashmap
In-Reply-To: <JMlvyfSj4esvpSAoIv6dOY9V8251Z4axnsgOwHhGtnw=.f9029456-fb1d-4dcc-8a25-f427b3f59470@github.com>
References: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
 <ELYVM5apJvtLBz03OOXiPiMFF8wo6laqZgXjgmxk-lo=.dc1efb74-8766-4437-ae03-72580d542aa1@github.com>
 <3Fgz1NtEiXdghFV8rJ1TOC3cjFoqrIroqxL9r1j3tfI=.1bd45473-e2e7-4d22-b59e-d6327759983c@github.com>
 <JMlvyfSj4esvpSAoIv6dOY9V8251Z4axnsgOwHhGtnw=.f9029456-fb1d-4dcc-8a25-f427b3f59470@github.com>
Message-ID: <b7FC9CT6NGmZyeV3DpDHk0vjkmGwY6yYvmF6BgDtFbQ=.86707465-0d39-4680-b405-0310d185ba50@github.com>

On Thu, 28 Aug 2025 13:38:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> HashMap allows null keys and that is handled separately in each case, not by the `equals` method.
>> "supposed to" is not sufficient when compatibility is concerned.
>
> I think your current logic differs when `e.key == null` and `k == null` - previously it evaluates to true, now this test fails.

True, but to get here `k != null`. (line 678)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2309028558

From liach at openjdk.org  Fri Aug 29 04:10:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 29 Aug 2025 04:10:59 GMT
Subject: [lworld] RFR: 8366214: [lworld] Use Objects.equals in HashMap and
 ConcurrentHashmap
In-Reply-To: <b7FC9CT6NGmZyeV3DpDHk0vjkmGwY6yYvmF6BgDtFbQ=.86707465-0d39-4680-b405-0310d185ba50@github.com>
References: <ir9FyNvCzXm0bk72lW9C_tY2EsVIC5E2L8m3vbkjfQo=.812d0d1c-6d7d-4127-98b6-a2e6e8b49633@github.com>
 <ELYVM5apJvtLBz03OOXiPiMFF8wo6laqZgXjgmxk-lo=.dc1efb74-8766-4437-ae03-72580d542aa1@github.com>
 <3Fgz1NtEiXdghFV8rJ1TOC3cjFoqrIroqxL9r1j3tfI=.1bd45473-e2e7-4d22-b59e-d6327759983c@github.com>
 <JMlvyfSj4esvpSAoIv6dOY9V8251Z4axnsgOwHhGtnw=.f9029456-fb1d-4dcc-8a25-f427b3f59470@github.com>
 <b7FC9CT6NGmZyeV3DpDHk0vjkmGwY6yYvmF6BgDtFbQ=.86707465-0d39-4680-b405-0310d185ba50@github.com>
Message-ID: <3kpSUFagzbOsJGeqfIG9c9TvqGy8ZUzZ0oCkX0fFRmQ=.6c54bbec-9106-4b03-851c-6f5ff4204d1c@github.com>

On Fri, 29 Aug 2025 03:20:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I think your current logic differs when `e.key == null` and `k == null` - previously it evaluates to true, now this test fails.
>
> True, but to get here `k != null`. (line 678)

Indeed, forgot this file is CHM; thought this one was the regular HM.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1536#discussion_r2309080557

From mcimadamore at openjdk.org  Fri Aug 29 10:18:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 10:18:57 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
Message-ID: <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>

On Thu, 28 Aug 2025 20:33:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1261:
>> 
>>> 1259:                     for (JCTree stat : tree.body.stats) {
>>> 1260:                         prologueCode.add(stat);
>>> 1261:                         /* gather all the stats in the body until a `super` or `this` constructor invocation is found,
>> 
>> I understand that you  wanted to simplify the visitor -- but doing a linear pass on the constructor and creating a new list of statements is also kind of expensive -- maybe when we're done with this change we can see if there's a way to set a flag on the visitor to shortcircuit the analysis after the super call is found.
>
> I think I like the trade-off, we could try to infer if a constructor invocation corresponds to the class we are interested in. Like for example analyzing the symbol associated to a `super` or `this` invocation. But for erroneous invocations the symbol could be null. So what to do when we find a null symbol? We would have no clues I think.

let's wait until we address the other comments first. What I had in mind (but can be addressed in a separate PR) was maybe have a general visitor for prologue -- e.g. an helper visitor class that only visits things inside the prologue. Then you can extend that helper visitor here, to do what you need to do.

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1363:
>> 
>>> 1361:                 try {
>>> 1362:                     analyzingSelect = true;
>>> 1363:                     super.visitSelect(tree);
>> 
>> Can't we cut recursion here (instead of using `analyzingSelect` ? That's also what the new `TreeInfo.symbolsFor` does. In general it seems like these two visitors are trying to do similar things but are not 100% aligned?
>
> if one has a complex select like for example: `new SuperInitFails(){}.x` it is still necessary to look inside and see if there are some forbidden accesses

Ok, the issue might then be that, while looking inside `SuperInitFails` you find a plain early access to a field (e.g. an ident) and we end up skipping it because `analyzingSelect` is set. At the very least we should unset inside classes (maybe lambdas too).

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1420:
>> 
>>> 1418:             Symbol sym = TreeInfo.symbolFor(tree);
>>> 1419:             if (sym != null) {
>>> 1420:                 if (!sym.isStatic() && !isMethodArgument(tree)) {
>> 
>> if you have a `sym`, in order to understand if something is a method parameter (not argument?) don't you need to check if `sym.owner == MTH` ?
>
> this is for cases when we have an argument that is for example of the same type as the current class so like:
> 
> class Test {
>     String s;
>     
>     Test(Test t) {
>         // the owner of s is Test not MTH so we need to check what is the qualifier for s which at the end is the argument
>         // `t` so we ignore it
>         String s1 = t.s;
>         super();
>     }
> }

yes, so isn't just checking owner.kind != TYP enough? (e.g. "not a field")

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1423:
>> 
>>> 1421:                     if (sym.name == names._this || sym.name == names._super) {
>>> 1422:                         // are we seeing something like `this` or `CurrentClass.this` or `SuperClass.super::foo`?
>>> 1423:                         if (TreeInfo.isExplicitThisReference(
>> 
>> Do we always report an error when seeing `Foo.this` ? What if we're not inside the prologue of `Foo` ?
>
> all the code we analyze in this visitor is in the prologue, this is why we pre-select what code we will see

I understand -- but in the prologue of Foo we can have a Bar.this where Bar is some enclosing class?


class Foo {
        class Bar {
            Bar() { Object o = Foo.this; super();}
        }
}

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309775683
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309762993
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309770322
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309768254

From mcimadamore at openjdk.org  Fri Aug 29 10:39:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 10:39:02 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
Message-ID: <hoIStNRs4dW0NkHijMrzu04pUvqmBDn96O0gdpir4NE=.bf06f3aa-11a0-4913-8aa7-1f68991d0c25@github.com>

On Thu, 28 Aug 2025 20:27:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing unnecessary imports

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1010:

> 1008:                 return node.type.tsym;
> 1009:             return null;
> 1010:         case TYPECAST:

Is this still needed?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309817479

From mcimadamore at openjdk.org  Fri Aug 29 10:49:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 10:49:51 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
Message-ID: <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>

On Thu, 28 Aug 2025 20:27:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing unnecessary imports

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1449:

> 1447:                              * not allowed in the prologue
> 1448:                              */
> 1449:                             if (insideLambdaOrClassDef ||

I'm not entirely convinced about these checks. They seem to lead to very strange asymmetries:


import java.util.function.*;

class Test3 {

    int x = 4;
    int y;

    Test3() {
        System.out.println(x); //error
        Supplier<Integer> s1 = () -> x; // error
        y = 2;
        System.out.println(y); // ok
        Supplier<Integer> s2 = () -> y; // error
        super();
    }
}


I understand that references to `x` are invalid here -- `x` is not a strict field, so it will be initialized _after_ the prologue. So the first couple of references are errors, fine.

But in the last couple, we have that `print(x)` is good, but the reference from the lambda is flagged as an error. I'm not sure what's the rationale here? After all the lambda is defined _after_ `y` has been assigned, so what are we trying to protect against?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309840429

From mcimadamore at openjdk.org  Fri Aug 29 11:00:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 11:00:56 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
Message-ID: <sZQsOD4pxuBux-cG-BnTJmbQdWqtv6_iQ1UKaqvmB8c=.e6809441-e84d-4101-8cd4-ba8a8f1c5bcc@github.com>

On Fri, 29 Aug 2025 10:10:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> if one has a complex select like for example: `new SuperInitFails(){}.x` it is still necessary to look inside and see if there are some forbidden accesses
>
> Ok, the issue might then be that, while looking inside `SuperInitFails` you find a plain early access to a field (e.g. an ident) and we end up skipping it because `analyzingSelect` is set. At the very least we should unset inside classes (maybe lambdas too).

Example:


class Test {

    int x = 4;

    static String m(Runnable r) { return null; }

    Test() {
        m(() -> System.out.println(x)).toString();
        super();
    }

    public static void main(String[] args) {
        new Test();
    }
}


This seems to compile, but then fails with verifier error.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309859203

From mcimadamore at openjdk.org  Fri Aug 29 11:00:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 11:00:56 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <sZQsOD4pxuBux-cG-BnTJmbQdWqtv6_iQ1UKaqvmB8c=.e6809441-e84d-4101-8cd4-ba8a8f1c5bcc@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
 <sZQsOD4pxuBux-cG-BnTJmbQdWqtv6_iQ1UKaqvmB8c=.e6809441-e84d-4101-8cd4-ba8a8f1c5bcc@github.com>
Message-ID: <TajhlmyqZpQQrrePovtfhZFetaFeHh6kORlp3dODk_4=.5a5372f2-441d-42f3-80f1-5707c4647c67@github.com>

On Fri, 29 Aug 2025 10:55:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Ok, the issue might then be that, while looking inside `SuperInitFails` you find a plain early access to a field (e.g. an ident) and we end up skipping it because `analyzingSelect` is set. At the very least we should unset inside classes (maybe lambdas too).
>
> Example:
> 
> 
> class Test {
> 
>     int x = 4;
> 
>     static String m(Runnable r) { return null; }
> 
>     Test() {
>         m(() -> System.out.println(x)).toString();
>         super();
>     }
> 
>     public static void main(String[] args) {
>         new Test();
>     }
> }
> 
> 
> This seems to compile, but then fails with verifier error.

(e.g. we really need to make sure that `analyzeSelect` is not applied too broadly)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309860632

From vromero at openjdk.org  Fri Aug 29 11:00:58 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 11:00:58 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
Message-ID: <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>

On Fri, 29 Aug 2025 10:47:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removing unnecessary imports
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1449:
> 
>> 1447:                              * not allowed in the prologue
>> 1448:                              */
>> 1449:                             if (insideLambdaOrClassDef ||
> 
> I'm not entirely convinced about these checks. They seem to lead to very strange asymmetries:
> 
> 
> import java.util.function.*;
> 
> class Test3 {
> 
>     int x = 4;
>     int y;
> 
>     Test3() {
>         System.out.println(x); //error
>         Supplier<Integer> s1 = () -> x; // error
>         y = 2;
>         System.out.println(y); // ok
>         Supplier<Integer> s2 = () -> y; // error
>         super();
>     }
> }
> 
> 
> I understand that references to `x` are invalid here -- `x` is not a strict field, so it will be initialized _after_ the prologue. So the first couple of references are errors, fine.
> 
> But in the last couple, we have that `print(x)` is good, but the reference from the lambda is flagged as an error. I'm not sure what's the rationale here? After all the lambda is defined _after_ `y` has been assigned, so what are we trying to protect against?

I think that the idea of restricting the access from lambdas and local classes is that they will capture `this` in order to access the field(s)

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1010:
> 
>> 1008:                 return node.type.tsym;
>> 1009:             return null;
>> 1010:         case TYPECAST:
> 
> Is this still needed?

yes no for this patch, but I was wondering if it could be useful for future use. But I will remove it

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309862398
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309865193

From vromero at openjdk.org  Fri Aug 29 11:11:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 11:11:02 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <TajhlmyqZpQQrrePovtfhZFetaFeHh6kORlp3dODk_4=.5a5372f2-441d-42f3-80f1-5707c4647c67@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
 <sZQsOD4pxuBux-cG-BnTJmbQdWqtv6_iQ1UKaqvmB8c=.e6809441-e84d-4101-8cd4-ba8a8f1c5bcc@github.com>
 <TajhlmyqZpQQrrePovtfhZFetaFeHh6kORlp3dODk_4=.5a5372f2-441d-42f3-80f1-5707c4647c67@github.com>
Message-ID: <1mblGCg-ec_o_Q_FX__BWdikOqXHqOfiI0Gtfdd0yJo=.3b662362-4398-47dd-b297-6d5255e7cc1a@github.com>

On Fri, 29 Aug 2025 10:56:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Example:
>> 
>> 
>> class Test {
>> 
>>     int x = 4;
>> 
>>     static String m(Runnable r) { return null; }
>> 
>>     Test() {
>>         m(() -> System.out.println(x)).toString();
>>         super();
>>     }
>> 
>>     public static void main(String[] args) {
>>         new Test();
>>     }
>> }
>> 
>> 
>> This seems to compile, but then fails with verifier error.
>
> (e.g. we really need to make sure that `analyzeSelect` is not applied too broadly)

true, now that we removed the visitor at TreeInfo that is a problem

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309883083

From vromero at openjdk.org  Fri Aug 29 12:05:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 12:05:52 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
Message-ID: <34538axagjf2FjcY19gxrvx-jr4-dquXyDRaLPMQwvA=.74eb51af-8ec1-4bee-8956-97484afa42f8@github.com>

On Fri, 29 Aug 2025 10:12:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> all the code we analyze in this visitor is in the prologue, this is why we pre-select what code we will see
>
> I understand -- but in the prologue of Foo we can have a Bar.this where Bar is some enclosing class?
> 
> 
> class Foo {
>         class Bar {
>             Bar() { Object o = Foo.this; super();}
>         }
> }

yep I see, there seems to be a bug here, thanks

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2309986600

From vromero at openjdk.org  Fri Aug 29 13:13:12 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 13:13:12 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v16]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <gt_lSFj7yfX1oYnIodv0rl4YI0VobZhtWPkCr5I4Fik=.f3127a64-fc1d-4fc2-ac9e-43428cb7e2b5@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/48a47133..c987a085

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=15
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=14-15

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

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

From duke at openjdk.org  Fri Aug 29 13:27:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 29 Aug 2025 13:27:41 GMT
Subject: [lworld] RFR: 8366200: Modify jimage package flags to support preview
 mode
Message-ID: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>

Reuses the previously unused package flags in the /packages/xxx entries of jimage files to support preview mode.

With these flags it becomes simple to determine things like:
1. Which modules are children of /packages/xxx
  - This can differ between preview and non-preview mode.

2. Which modules/packages have any preview content
  - Useful in preview mode for faster rejection testing to avoid double-lookup on all resources.

If there are no preview resources built into the jimage file, then the difference between output is that the "isEmpty" flag (old version) has become a "hasContent" flag (but since these flags are not read by anyone right now, this should not be an issue).

Note that bumping the minor version number was done to ensure that, during testing, no undiscovered code is reading the new file with old logic (this would work since there's no structural change, but the semantics are different).

This does mean that on systems where a 'jimage' binary is installed for the JDK (e.g. /usr/bin/jimage), that tool will stop working on files generate by this code, but the version of that binary in the built JDK will work. The alternative is to just not bump the version number (if nobody is reading the flags now, it shouldn't matter what's in them).

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

Commit messages:
 - Modify jimage package flags to support preview mode

Changes: https://git.openjdk.org/valhalla/pull/1537/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1537&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366200
  Stats: 472 lines in 6 files changed: 402 ins; 22 del; 48 mod
  Patch: https://git.openjdk.org/valhalla/pull/1537.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1537/head:pull/1537

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

From duke at openjdk.org  Fri Aug 29 13:33:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 29 Aug 2025 13:33:11 GMT
Subject: [lworld] RFR: 8366200: Modify jimage package flags to support
 preview mode [v2]
In-Reply-To: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
References: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
Message-ID: <17h3t1EKEsuIwuR1GYBFYfux3KN9qPJZzZxEwB37mXI=.7bd082e5-b18e-4011-86ee-72dbbfdba2ed@github.com>

> Reuses the previously unused package flags in the /packages/xxx entries of jimage files to support preview mode.
> 
> With these flags it becomes simple to determine things like:
> 1. Which modules are children of /packages/xxx
>   - This can differ between preview and non-preview mode.
> 
> 2. Which modules/packages have any preview content
>   - Useful in preview mode for faster rejection testing to avoid double-lookup on all resources.
> 
> If there are no preview resources built into the jimage file, then the difference between output is that the "isEmpty" flag (old version) has become a "hasContent" flag (but since these flags are not read by anyone right now, this should not be an issue).
> 
> Note that bumping the minor version number was done to ensure that, during testing, no undiscovered code is reading the new file with old logic (this would work since there's no structural change, but the semantics are different).
> 
> This does mean that on systems where a 'jimage' binary is installed for the JDK (e.g. /usr/bin/jimage), that tool will stop working on files generate by this code, but the version of that binary in the built JDK will work. The alternative is to just not bump the version number (if nobody is reading the flags now, it shouldn't matter what's in them).

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

  Minor tidy

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1537/files
  - new: https://git.openjdk.org/valhalla/pull/1537/files/3d51e1a4..8fa42347

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

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

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

From mcimadamore at openjdk.org  Fri Aug 29 13:38:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 13:38:47 GMT
Subject: [lworld] RFR: Fix issues in javac combo tests
Message-ID: <IY1xoeNYUdA9IHUNO2dcXLGyzJlFhhaOkeKNS_XCIuE=.c4fea90c-3496-44df-bd78-76a12240566a@github.com>

A [change](https://bugs.openjdk.org/browse/JDK-8334294) made last year added `@enablePreview` to some tests using the combinatorial javac testing framework.
I believe the issue was that back then we had no way to load different version of a class (e.g. `Optional`) based on whether we were running on preview vs. non-preview so. Since the framework uses `Optional` it was treated as having an hard dependency on a preview feature, and compilation failed.
To fix this, we added `@enablePreview` in the tests that depend on that framework -- this meant the framework was now compiled with `--enable-preview` which solved the issue.

But this workaround is no longer needed today. And, worse, as we keep getting new tests from mainline, such tests will fail if they depend on the combinatorial framework, as they will depend on a "preview" classfile (as of today we have 4 such errors). So this means that to keep test working we will have to add `@enablePreview` to an increasing number of tests. This doesn't scale and since we no longer need it, it seems better to just just drop the `@enablePreview` directives that were added, effectively reverting the code to what is there in mainline/master.

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

Commit messages:
 - Fix issues in combo tests

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

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

From duke at openjdk.org  Fri Aug 29 13:41:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 29 Aug 2025 13:41:54 GMT
Subject: [lworld] RFR: 8366200: Modify jimage package flags to support
 preview mode [v2]
In-Reply-To: <17h3t1EKEsuIwuR1GYBFYfux3KN9qPJZzZxEwB37mXI=.7bd082e5-b18e-4011-86ee-72dbbfdba2ed@github.com>
References: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
 <17h3t1EKEsuIwuR1GYBFYfux3KN9qPJZzZxEwB37mXI=.7bd082e5-b18e-4011-86ee-72dbbfdba2ed@github.com>
Message-ID: <kKAFUtTIOZoczz_4Snsuj09anrJO4auvEhi7I6XMtJM=.3f899d47-ff9f-41cd-828e-99b85e3eea47@github.com>

On Fri, 29 Aug 2025 13:33:11 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Reuses the previously unused package flags in the /packages/xxx entries of jimage files to support preview mode.
>> 
>> With these flags it becomes simple to determine things like:
>> 1. Which modules are children of /packages/xxx
>>   - This can differ between preview and non-preview mode.
>> 
>> 2. Which modules/packages have any preview content
>>   - Useful in preview mode for faster rejection testing to avoid double-lookup on all resources.
>> 
>> If there are no preview resources built into the jimage file, then the difference between output is that the "isEmpty" flag (old version) has become a "hasContent" flag (but since these flags are not read by anyone right now, this should not be an issue).
>> 
>> Note that bumping the minor version number was done to ensure that, during testing, no undiscovered code is reading the new file with old logic (this would work since there's no structural change, but the semantics are different).
>> 
>> This does mean that on systems where a 'jimage' binary is installed for the JDK (e.g. /usr/bin/jimage), that tool will stop working on files generate by this code, but the version of that binary in the built JDK will work. The alternative is to just not bump the version number (if nobody is reading the flags now, it shouldn't matter what's in them).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor tidy

Some pre-loaded comments for reviewers.

src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 33:

> 31: 
> 32: /**
> 33:  * Defines the header and version information for jimage files.

Technically optional even though this is a semantic change (it's a change in data nobody should be reading at the moment).

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 48:

> 46: public final class ImageResourcesTree {
> 47:     public static boolean isTreeInfoResource(String path) {
> 48:         return path.startsWith("/packages/") || path.startsWith("/modules/");

Fixed in passing. Previously this would silently hide/ignore packages with names starting "packages..." or "modules..." in the jimage tool.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 178:

> 176:             private final int flags;
> 177: 
> 178:             PackageReference(String name, int flags) {

I really don't like the name "PackageReference", since this does not reference a package, it references a module in which the package exists. I'd be happy to just refactor the name to something else but didn't want to do too many "preferential" changes.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 183:

> 181:             }
> 182: 
> 183:             String name() {return name;}

Methods here make the comparator easier to construct.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 197:

> 195:             @Override
> 196:             public String toString() {
> 197:                 return String.format("%s [has_normal_content=%s, has_preview_content=%s, is_preview_only=%s]",

I assume nobody was expected to be relying on the `toString()` output.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 206:

> 204: 
> 205:         // Outside this class, callers should access via modules() / moduleCount().
> 206:         private final Map<String, PackageReference> unsortedReferences = new HashMap<>();

Changing the name to make it clear this is not the preferred way to read references now. If these classes were in separate sources it would be easier to encapsulate.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 243:

> 241:         private void validate() {
> 242:             // If there's a module for which this package has content, it should be first and unique.
> 243:             if (modules().skip(1).anyMatch(ref -> !ref.isEmpty())) {

With module references sorted, the validation becomes easier.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 498:

> 496:                 buff.order(writer.getByteOrder());
> 497:                 pkgNode.modules().forEach(mod -> {
> 498:                     buff.putInt(mod.flags);

This is the whole point of this change, to write the new flags into the package entry.

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

PR Review: https://git.openjdk.org/valhalla/pull/1537#pullrequestreview-3168722127
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2310152805
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2310168105
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2310172648
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2310177352
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2310178660
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2310181114
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2310183290
PR Review Comment: https://git.openjdk.org/valhalla/pull/1537#discussion_r2310189310

From duke at openjdk.org  Fri Aug 29 13:48:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 29 Aug 2025 13:48:41 GMT
Subject: [lworld] RFR: 8366200: Modify jimage package flags to support
 preview mode [v3]
In-Reply-To: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
References: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
Message-ID: <b3b5Zieo6oqNVjH_Uay7rt_UWUT8khMQ5GW_KB-ZmFU=.653c88ec-109d-4e7d-bbd2-9f5848095a40@github.com>

> Reuses the previously unused package flags in the /packages/xxx entries of jimage files to support preview mode.
> 
> With these flags it becomes simple to determine things like:
> 1. Which modules are children of /packages/xxx
>   - This can differ between preview and non-preview mode.
> 
> 2. Which modules/packages have any preview content
>   - Useful in preview mode for faster rejection testing to avoid double-lookup on all resources.
> 
> If there are no preview resources built into the jimage file, then the difference between output is that the "isEmpty" flag (old version) has become a "hasContent" flag (but since these flags are not read by anyone right now, this should not be an issue).
> 
> Note that bumping the minor version number was done to ensure that, during testing, no undiscovered code is reading the new file with old logic (this would work since there's no structural change, but the semantics are different).
> 
> This does mean that on systems where a 'jimage' binary is installed for the JDK (e.g. /usr/bin/jimage), that tool will stop working on files generate by this code, but the version of that binary in the built JDK will work. The alternative is to just not bump the version number (if nobody is reading the flags now, it shouldn't matter what's in them).

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

  Remove code from testing the tests.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1537/files
  - new: https://git.openjdk.org/valhalla/pull/1537/files/8fa42347..cc58aca1

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

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

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

From mcimadamore at openjdk.org  Fri Aug 29 13:56:00 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 13:56:00 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
Message-ID: <coQc-lXEwiJdly6vH8hVp1P3Fu0UFWoPPtOQDcbz0pc=.4fb49aa2-b1a1-407a-be58-4830bf22a150@github.com>

On Fri, 29 Aug 2025 10:13:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> this is for cases when we have an argument that is for example of the same type as the current class so like:
>> 
>> class Test {
>>     String s;
>>     
>>     Test(Test t) {
>>         // the owner of s is Test not MTH so we need to check what is the qualifier for s which at the end is the argument
>>         // `t` so we ignore it
>>         String s1 = t.s;
>>         super();
>>     }
>> }
>
> yes, so isn't just checking owner.kind != TYP enough? (e.g. "not a field")

I tried to replace this with:

`if (!sym.isStatic() && sym.kind == VAR && sym.owner.kind == TYP) { ... }`

And no tests seem to fail.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2310224467

From mcimadamore at openjdk.org  Fri Aug 29 13:56:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 13:56:02 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
Message-ID: <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>

On Fri, 29 Aug 2025 10:57:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1449:
>> 
>>> 1447:                              * not allowed in the prologue
>>> 1448:                              */
>>> 1449:                             if (insideLambdaOrClassDef ||
>> 
>> I'm not entirely convinced about these checks. They seem to lead to very strange asymmetries:
>> 
>> 
>> import java.util.function.*;
>> 
>> class Test3 {
>> 
>>     int x = 4;
>>     int y;
>> 
>>     Test3() {
>>         System.out.println(x); //error
>>         Supplier<Integer> s1 = () -> x; // error
>>         y = 2;
>>         System.out.println(y); // ok
>>         Supplier<Integer> s2 = () -> y; // error
>>         super();
>>     }
>> }
>> 
>> 
>> I understand that references to `x` are invalid here -- `x` is not a strict field, so it will be initialized _after_ the prologue. So the first couple of references are errors, fine.
>> 
>> But in the last couple, we have that `print(x)` is good, but the reference from the lambda is flagged as an error. I'm not sure what's the rationale here? After all the lambda is defined _after_ `y` has been assigned, so what are we trying to protect against?
>
> I think that the idea of restricting the access from lambdas and local classes is that they will capture `this` in order to access the field(s)

Ah! Forgot about that one -- but... with proxy locals that's no longer the case, no?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2310221250

From mcimadamore at openjdk.org  Fri Aug 29 14:06:59 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 14:06:59 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <1mblGCg-ec_o_Q_FX__BWdikOqXHqOfiI0Gtfdd0yJo=.3b662362-4398-47dd-b297-6d5255e7cc1a@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
 <sZQsOD4pxuBux-cG-BnTJmbQdWqtv6_iQ1UKaqvmB8c=.e6809441-e84d-4101-8cd4-ba8a8f1c5bcc@github.com>
 <TajhlmyqZpQQrrePovtfhZFetaFeHh6kORlp3dODk_4=.5a5372f2-441d-42f3-80f1-5707c4647c67@github.com>
 <1mblGCg-ec_o_Q_FX__BWdikOqXHqOfiI0Gtfdd0yJo=.3b662362-4398-47dd-b297-6d5255e7cc1a@github.com>
Message-ID: <Cnl5MH4253roI6T2PwMsAoZGYNzLqcj2ncTMcbOW8HQ=.68f61f37-6729-4795-9a83-45d75c786da6@github.com>

On Fri, 29 Aug 2025 11:08:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> (e.g. we really need to make sure that `analyzeSelect` is not applied too broadly)
>
> true, now that we removed the visitor at TreeInfo that is a problem

Actually -- this is enough:

class Test {

    int x = 4;

    static String m(Object r) { return null; }

    Test() {
        m(x).toString();
        super();
    }

    public static void main(String[] args) {
        new Test();
    }
}

No lambda. So probably was an issue even before, with `TreeInfo`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2310258047

From mcimadamore at openjdk.org  Fri Aug 29 14:17:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 14:17:56 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
 <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
Message-ID: <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>

On Fri, 29 Aug 2025 13:51:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I think that the idea of restricting the access from lambdas and local classes is that they will capture `this` in order to access the field(s)
>
> Ah! Forgot about that one -- but... with proxy locals that's no longer the case, no?

(or, do we only do local proxies for strict fields? If so, should we be more uniform here?)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2310293186

From vromero at openjdk.org  Fri Aug 29 14:19:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 14:19:50 GMT
Subject: [lworld] RFR: Fix issues in javac combo tests
In-Reply-To: <IY1xoeNYUdA9IHUNO2dcXLGyzJlFhhaOkeKNS_XCIuE=.c4fea90c-3496-44df-bd78-76a12240566a@github.com>
References: <IY1xoeNYUdA9IHUNO2dcXLGyzJlFhhaOkeKNS_XCIuE=.c4fea90c-3496-44df-bd78-76a12240566a@github.com>
Message-ID: <H4pt-JVfruNg5BC_PL6q8Vk59KwTq-qeFC4Q2MAEoJo=.da5cd9b7-9a3d-48a8-a16e-0c9aaddd1a01@github.com>

On Fri, 29 Aug 2025 13:33:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> A [change](https://bugs.openjdk.org/browse/JDK-8334294) made last year added `@enablePreview` to some tests using the combinatorial javac testing framework.
> I believe the issue was that back then we had no way to load different version of a class (e.g. `Optional`) based on whether we were running on preview vs. non-preview so. Since the framework uses `Optional` it was treated as having an hard dependency on a preview feature, and compilation failed.
> To fix this, we added `@enablePreview` in the tests that depend on that framework -- this meant the framework was now compiled with `--enable-preview` which solved the issue.
> 
> But this workaround is no longer needed today. And, worse, as we keep getting new tests from mainline, such tests will fail if they depend on the combinatorial framework, as they will depend on a "preview" classfile (as of today we have 4 such errors). So this means that to keep test working we will have to add `@enablePreview` to an increasing number of tests. This doesn't scale and since we no longer need it, it seems better to just just drop the `@enablePreview` directives that were added, effectively reverting the code to what is there in mainline/master.

looks good, thanks for fixing this

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1538#pullrequestreview-3168921354

From vromero at openjdk.org  Fri Aug 29 14:32:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 14:32:02 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v13]
In-Reply-To: <Cnl5MH4253roI6T2PwMsAoZGYNzLqcj2ncTMcbOW8HQ=.68f61f37-6729-4795-9a83-45d75c786da6@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <mTSWubxQKgNXyujWSrDN8Ovezi-KUaLA2XqgU8alCRs=.ea32944b-c9c4-4fd7-bf1c-ad5a2ab17587@github.com>
 <1AKmN9UUmC78FgJeEsBWgt-ifR7ZExskxENFWy_vpZo=.73135fcf-39f5-4150-a2ef-3879c8deae60@github.com>
 <BiUa4A7vfSj2oDYIShQGavMGQgrzZK19tCe7A7rVTxM=.bfb48dbb-4e46-4e80-8a67-82ab4a1e36fd@github.com>
 <cusc6qxCO4ckJWWsrxaiAJ6sOOYUvmxYSTwjVrJC2tA=.f050c382-2b05-436c-a89b-602ee4b40124@github.com>
 <sZQsOD4pxuBux-cG-BnTJmbQdWqtv6_iQ1UKaqvmB8c=.e6809441-e84d-4101-8cd4-ba8a8f1c5bcc@github.com>
 <TajhlmyqZpQQrrePovtfhZFetaFeHh6kORlp3dODk_4=.5a5372f2-441d-42f3-80f1-5707c4647c67@github.com>
 <1mblGCg-ec_o_Q_FX__BWdikOqXHqOfiI0Gtfdd0yJo=.3b662362-4398-47dd-b297-6d5255e7cc1a@github.com>
 <Cnl5MH4253roI6T2PwMsAoZGYNzLqcj2ncTMcbOW8HQ=.68f61f37-6729-4795-9a83-45d75c786da6@github.com>
Message-ID: <gOAUifiE8HpavCzVW_KqSfLnRwMBObx6DHvDy4RAH7c=.e260255e-2ec5-4a84-bad1-faf463aac5e0@github.com>

On Fri, 29 Aug 2025 14:04:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> true, now that we removed the visitor at TreeInfo that is a problem
>
> Actually -- this is enough:
> 
> class Test {
> 
>     int x = 4;
> 
>     static String m(Object r) { return null; }
> 
>     Test() {
>         m(x).toString();
>         super();
>     }
> 
>     public static void main(String[] args) {
>         new Test();
>     }
> }
> 
> No lambda. So probably was an issue even before, with `TreeInfo`.

yep :(

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2310323171

From vromero at openjdk.org  Fri Aug 29 14:32:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 14:32:02 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v15]
In-Reply-To: <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <yYMSe5ONTGhuf20zxXwHudmMrRPx2CCN2bqeB2gBr00=.f15fdad0-1ddc-47ca-a9eb-c29f1ede817f@github.com>
 <1LVa6gpDkvhjwbObQ0PmxjZzFRBIH_1qxXviLRypkBk=.da27ddd9-a2de-4a0c-b1f9-3732b4c565b9@github.com>
 <CKn_mWYfg-4Sn7yCcBIsvJJEiLATBdD8oCRHKDt5lUw=.21cdc091-5e62-4daf-9f02-2894ee7d2bdb@github.com>
 <0TlPQHFNxMNl22ulZGcxf4UURpcu4WT12xiTJsgYxqY=.c48a3949-b372-4adc-9ec7-d21b1ff88b79@github.com>
 <EgtRgQkXxB3nhTbdcgsZ9uKy7b787ajX2yCelHLGeZ4=.345d7e46-1cde-456e-bbf6-75001a08d9b4@github.com>
Message-ID: <ofmC8m_hlxPgPSpKRePkS7M94nm-JYJmhdd_iesCjRQ=.0b05d84f-d188-4f27-9b1a-f90f5539c1b8@github.com>

On Fri, 29 Aug 2025 14:15:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Ah! Forgot about that one -- but... with proxy locals that's no longer the case, no?
>
> (or, do we only do local proxies for strict fields? If so, should we be more uniform here?)

no we do local proxies for every field read in the prologue, a getField with a larval `this` will be an error in the VM

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2310329283

From duke at openjdk.org  Fri Aug 29 15:27:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 29 Aug 2025 15:27:21 GMT
Subject: [lworld] RFR: 8366200: Modify jimage package flags to support
 preview mode [v4]
In-Reply-To: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
References: <T9agi8MWtFWN7-c5BwNDea33o6TQkdLft0v83eOv_qM=.9c75b546-ac8b-4a09-9cd4-68ee68e87a72@github.com>
Message-ID: <HRikrRZRJ16Ayek8UCWjcx-F1USu0auwEMUcPs7iL7o=.38effd02-fc08-4b4a-b6f5-2161679583c5@github.com>

> Reuses the previously unused package flags in the /packages/xxx entries of jimage files to support preview mode.
> 
> With these flags it becomes simple to determine things like:
> 1. Which modules are children of /packages/xxx
>   - This can differ between preview and non-preview mode.
> 
> 2. Which modules/packages have any preview content
>   - Useful in preview mode for faster rejection testing to avoid double-lookup on all resources.
> 
> If there are no preview resources built into the jimage file, then the difference between output is that the "isEmpty" flag (old version) has become a "hasContent" flag (but since these flags are not read by anyone right now, this should not be an issue).
> 
> Note that bumping the minor version number was done to ensure that, during testing, no undiscovered code is reading the new file with old logic (this would work since there's no structural change, but the semantics are different).
> 
> This does mean that on systems where a 'jimage' binary is installed for the JDK (e.g. /usr/bin/jimage), that tool will stop working on files generate by this code, but the version of that binary in the built JDK will work. The alternative is to just not bump the version number (if nobody is reading the flags now, it shouldn't matter what's in them).

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

  More tests and test tweaking for clarity

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1537/files
  - new: https://git.openjdk.org/valhalla/pull/1537/files/cc58aca1..44bedece

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

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

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

From mcimadamore at openjdk.org  Fri Aug 29 17:11:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Aug 2025 17:11:57 GMT
Subject: [lworld] Integrated: Fix issues in javac combo tests
In-Reply-To: <IY1xoeNYUdA9IHUNO2dcXLGyzJlFhhaOkeKNS_XCIuE=.c4fea90c-3496-44df-bd78-76a12240566a@github.com>
References: <IY1xoeNYUdA9IHUNO2dcXLGyzJlFhhaOkeKNS_XCIuE=.c4fea90c-3496-44df-bd78-76a12240566a@github.com>
Message-ID: <T36Xg94yAoENhuaYE0hXQi4HI5RiHdrjKAbzZc13YKw=.c83401a5-6c42-4931-a0c0-fd6f5e04cf23@github.com>

On Fri, 29 Aug 2025 13:33:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> A [change](https://bugs.openjdk.org/browse/JDK-8334294) made last year added `@enablePreview` to some tests using the combinatorial javac testing framework.
> I believe the issue was that back then we had no way to load different version of a class (e.g. `Optional`) based on whether we were running on preview vs. non-preview so. Since the framework uses `Optional` it was treated as having an hard dependency on a preview feature, and compilation failed.
> To fix this, we added `@enablePreview` in the tests that depend on that framework -- this meant the framework was now compiled with `--enable-preview` which solved the issue.
> 
> But this workaround is no longer needed today. And, worse, as we keep getting new tests from mainline, such tests will fail if they depend on the combinatorial framework, as they will depend on a "preview" classfile (as of today we have 4 such errors). So this means that to keep test working we will have to add `@enablePreview` to an increasing number of tests. This doesn't scale and since we no longer need it, it seems better to just just drop the `@enablePreview` directives that were added, effectively reverting the code to what is there in mainline/master.

This pull request has now been integrated.

Changeset: 4a8a6150
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4a8a6150e8959d46c75f7ef73414fe1b82328d1e
Stats:     30 lines in 30 files changed: 0 ins; 30 del; 0 mod

Fix issues in javac combo tests

Reviewed-by: vromero

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

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

From vromero at openjdk.org  Fri Aug 29 18:19:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 18:19:38 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v17]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <9TGJQ1ln2YWQpdluFSGNjiqC6u6IKQnKR2zq1rVdSm0=.7f5e385b-8629-444d-919b-4647ff6b1140@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  additional changes, more tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/c987a085..32ccabf3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=16
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=15-16

  Stats: 75 lines in 5 files changed: 31 ins; 25 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From vromero at openjdk.org  Fri Aug 29 19:48:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 19:48:52 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v18]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <r2sLjTuqTRVVH-Y1jK5CaHyaqUe6u1VwDMKGELyJIgg=.e37b86bb-ff52-44a5-a79b-1031a58d1f4b@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  moving isEarlyReference to Attr

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/32ccabf3..b101d1ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=17
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=16-17

  Stats: 68 lines in 2 files changed: 29 ins; 36 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1523.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1523/head:pull/1523

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

From vromero at openjdk.org  Fri Aug 29 19:48:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 19:48:53 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v18]
In-Reply-To: <r2sLjTuqTRVVH-Y1jK5CaHyaqUe6u1VwDMKGELyJIgg=.e37b86bb-ff52-44a5-a79b-1031a58d1f4b@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <r2sLjTuqTRVVH-Y1jK5CaHyaqUe6u1VwDMKGELyJIgg=.e37b86bb-ff52-44a5-a79b-1031a58d1f4b@github.com>
Message-ID: <0UYfUQ_IEHn-m37QjJnAZdXnbHrr55i4YvWRci-tO-g=.014aa386-3b4d-4a8e-bc89-330b3d521e43@github.com>

On Fri, 29 Aug 2025 19:45:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moving isEarlyReference to Attr

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 323:

> 321: 
> 322:         // Check instance field assignments that appear in constructor prologues
> 323:         if (isEarlyReference(env, base, v)) {

this method, isEarlyReference, is only used in Attr, I moved it here

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2311016772

From vromero at openjdk.org  Fri Aug 29 19:51:58 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 19:51:58 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v18]
In-Reply-To: <r2sLjTuqTRVVH-Y1jK5CaHyaqUe6u1VwDMKGELyJIgg=.e37b86bb-ff52-44a5-a79b-1031a58d1f4b@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
 <r2sLjTuqTRVVH-Y1jK5CaHyaqUe6u1VwDMKGELyJIgg=.e37b86bb-ff52-44a5-a79b-1031a58d1f4b@github.com>
Message-ID: <xsRnSg-qo53n5nn4bPFhDx0y7IyHsaRD4WhEjmYaqyM=.de7b24bc-2ba7-4aa0-a927-5227c71e6dd8@github.com>

On Fri, 29 Aug 2025 19:48:52 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
>> 
>> TIA
>> 
>> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moving isEarlyReference to Attr

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3945:

> 3943:         return result.toList();
> 3944:     }
> 3945:     private boolean isReceiverParameter(Env<AttrContext> env, JCFieldAccess tree) {

this method, `isReceiverParameter`, is not used any more, I removed it

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3968:

> 3966:      * To catch those cases, we rely on similar logic in Attr.checkAssignable().
> 3967:      */
> 3968:     private boolean isAllowedEarlyReference(DiagnosticPosition pos, Env<AttrContext> env, VarSymbol v) {

moved this one to Attr

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2311022818
PR Review Comment: https://git.openjdk.org/valhalla/pull/1523#discussion_r2311023458

From vromero at openjdk.org  Fri Aug 29 20:10:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Aug 2025 20:10:39 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v19]
In-Reply-To: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
References: <kHHWjT9LgrQ3K_oiLEnbNGQJJSLjMaq3P0UUd38J-po=.4df96cb4-f87d-4bbb-b11a-d76ee8b3a1bf@github.com>
Message-ID: <xUG_UhPW3CKq8-bedVYGDOzDKHotf_J5kf9zyRBQefI=.c13f4c8a-5608-4264-8b01-28c9438bde18@github.com>

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase. This implies changes in flow analysis as before we were only tracking final and strict fields. There is also some "cooperation" needed in the code to detect cases when reading a field is not allowed in the prologue phase. For example some methods in Resolve don't have all the needed information at the moment they are dealing with some ASTs and part of the processing needs to be done in Attr
> 
> TIA
> 
> This PR is a remake of https://github.com/openjdk/valhalla/pull/1490

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

  some documentation

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1523/files
  - new: https://git.openjdk.org/valhalla/pull/1523/files/b101d1ea..e87108da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=18
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1523&range=17-18

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

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

From liach at openjdk.org  Fri Aug 29 21:03:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 29 Aug 2025 21:03:25 GMT
Subject: [lworld] Integrated: 8310649: [lworld] PrimitiveClassConstantTest
 fails with ClassFormatError
Message-ID: <ZKqqnOMwsW5sgeEQvQh177OnSHek65hfpb87KufNy7E=.c49123a2-54d2-4710-81bb-7e5dd4059e50@github.com>

Trivially remove a few outdated classfile problemlist entries. These tests all pass now, except  `PrimitiveClassConstantTest` has since been removed and its successor has already been passing in tier1 part3.

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

Commit messages:
 - 8310649: [lworld] PrimitiveClassConstantTest fails with ClassFormatError

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

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

From liach at openjdk.org  Fri Aug 29 21:03:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 29 Aug 2025 21:03:25 GMT
Subject: [lworld] Integrated: 8310649: [lworld] PrimitiveClassConstantTest
 fails with ClassFormatError
In-Reply-To: <ZKqqnOMwsW5sgeEQvQh177OnSHek65hfpb87KufNy7E=.c49123a2-54d2-4710-81bb-7e5dd4059e50@github.com>
References: <ZKqqnOMwsW5sgeEQvQh177OnSHek65hfpb87KufNy7E=.c49123a2-54d2-4710-81bb-7e5dd4059e50@github.com>
Message-ID: <ayAPloCchHEblacuAdhKrtEa3gN1gbqzyeqE_PD1F4k=.55a83624-8d78-477d-91f4-36093319e925@github.com>

On Fri, 29 Aug 2025 20:58:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Trivially remove a few outdated classfile problemlist entries. These tests all pass now, except  `PrimitiveClassConstantTest` has since been removed and its successor has already been passing in tier1 part3.

Integrating this as this is quite trivial.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1539#issuecomment-3238261384

From liach at openjdk.org  Fri Aug 29 21:03:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 29 Aug 2025 21:03:26 GMT
Subject: [lworld] Integrated: 8310649: [lworld] PrimitiveClassConstantTest
 fails with ClassFormatError
In-Reply-To: <ZKqqnOMwsW5sgeEQvQh177OnSHek65hfpb87KufNy7E=.c49123a2-54d2-4710-81bb-7e5dd4059e50@github.com>
References: <ZKqqnOMwsW5sgeEQvQh177OnSHek65hfpb87KufNy7E=.c49123a2-54d2-4710-81bb-7e5dd4059e50@github.com>
Message-ID: <om2BQ22Sjd8Ht7gHWuyiMsFlfL8u9GF1Cf_XNAEBQJw=.bd3e7dc8-aa03-4250-bd40-1dfd240ddc62@github.com>

On Fri, 29 Aug 2025 20:58:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Trivially remove a few outdated classfile problemlist entries. These tests all pass now, except  `PrimitiveClassConstantTest` has since been removed and its successor has already been passing in tier1 part3.

This pull request has now been integrated.

Changeset: 63314117
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/63314117aa0c30f1a5928b56d21d944de063b8c6
Stats:     6 lines in 1 file changed: 0 ins; 6 del; 0 mod

8310649: [lworld] PrimitiveClassConstantTest fails with ClassFormatError

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

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