From thartmann at openjdk.org  Wed Oct  1 07:23:25 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 1 Oct 2025 07:23:25 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v2]
In-Reply-To: <ldjuHEQsxNxKu9SyWGPJgmzXeNwDVnduZOSRpf3EoVk=.aa4bdfa6-d3ab-4bd6-9374-050310643e92@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <ldjuHEQsxNxKu9SyWGPJgmzXeNwDVnduZOSRpf3EoVk=.aa4bdfa6-d3ab-4bd6-9374-050310643e92@github.com>
Message-ID: <-Oa2kcVEzgCQPt3unbHXAC_LoOeq_qKbnjYfCW1ZRfc=.e06691b6-4c95-4805-9cec-b5450045e2fb@github.com>

On Tue, 30 Sep 2025 23:37:01 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> ## Act I: dead loops
>> 
>> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
>> 
>> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
>> 
>> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
>> 
>> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
>> 
>> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set phis input to top initially, not merge with top.

Thanks for making these changes! I added a few more comments.

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

> 43: // Clones the inline type to handle control flow merges involving multiple inline types.
> 44: // The inputs are replaced by PhiNodes to represent the merged values for the given region.
> 45: // top_for_other_inputs: input of phis above the returned InlineTypeNode are initialized to top.

You call it `top_for_other_inputs` here but below it's called `phi_input_are_top`. I would suggest to use something like `init_with_top`.

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

> 55:   PhiNode* oop;
> 56:   if (phi_input_are_top) {
> 57:     oop = PhiNode::make(region, top, t);

For readability, I would prefer:

`oop = PhiNode::make(region, phi_input_are_top ? top : vt->get_oop(), t)`

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1640#pullrequestreview-3287632300
PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2393569908
PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2393515332

From thartmann at openjdk.org  Wed Oct  1 07:23:27 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 1 Oct 2025 07:23:27 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v2]
In-Reply-To: <MfAwJeJsbkOnDV4U9w3ObtTxuVWy-wZgMITWMU0GUf4=.d3d3c1e6-a796-490c-9bcc-7272f39532fd@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
 <MfAwJeJsbkOnDV4U9w3ObtTxuVWy-wZgMITWMU0GUf4=.d3d3c1e6-a796-490c-9bcc-7272f39532fd@github.com>
Message-ID: <NRL_wzyX7yaDrSMb6VLIKTV7LAvJeSBOfCp4dlKEyd8=.c70c62e0-65c5-41b9-9559-cfd22de28062@github.com>

On Tue, 30 Sep 2025 08:51:25 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/opto/cfgnode.cpp line 1482:
>> 
>>> 1480:   }
>>> 1481:   {
>>> 1482:     Node* uin = unique_constant_input_recursive(phase);
>> 
>> I think the original format was fine but I have no strong opinion.
>
> I wouldn't fight too hard for it, but when trying things, it was necessary (since I wanted different types for `uin`), but I also think it helps to see that it is not useful too long, and I can mess with it without having to look at what comes after. In this case, indeed, it feels a bit coming out of nowhere at the end...
> 
> In C++17, I'd do:
> ```c++
>  if (Node* uin = unique_constant_input_recursive(phase); uin != nullptr) {
>   return uin;
> }
> 
> one could also do
> ```c++
>  if (Node* uin = unique_constant_input_recursive(phase)) {
>   return uin;
> }
> 
> if we are not afraid of implicit conditions (but we are, and I'm fine with it!).

Right but now that both `uin` have the same type, the scoping seems unnecessary.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2393507487

From thartmann at openjdk.org  Wed Oct  1 07:23:29 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 1 Oct 2025 07:23:29 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v2]
In-Reply-To: <rPxVM8ARo8-xrHrnpLcj1GZ1TAMRB7YHd7bqybqLd8g=.274bf5a5-4c7b-4d15-9141-42a671aa1921@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
 <Q5YGR7GOP505Wn9nYkOn37yyaV8wdZD8n_IBQ_ejqQo=.611d9e4a-6fc9-491e-804e-0133bc64ae84@github.com>
 <502Y1FL7CYU7czxswnBm_Z9dz6gsEdg5R3YUJLQiOEI=.30213c5a-d857-470e-9a4c-5441f59a0239@github.com>
 <rPxVM8ARo8-xrHrnpLcj1GZ1TAMRB7YHd7bqybqLd8g=.274bf5a5-4c7b-4d15-9141-42a671aa1921@github.com>
Message-ID: <qX1yUPVgb78EMqXeiHAPRpKxmZAA_HSfqdzSBDPqJew=.764b7e88-abc6-4282-a95b-d59c8cc6e658@github.com>

On Tue, 30 Sep 2025 23:37:51 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Right, skipping the call would be even better. I think the `ensure_phi` callsite should be fine as well as all the branches that the phi inputs correspond to should either be initialized afterwards or are dead (in which case `top` seems appropriate). But only testing will tell :D
>
> I didn't dig too much, but it seems that if one put top everywhere in `clone_with_phis`, between a quarter and a third of all the tests are broken. Anyway, it doesn't seem good. But making this callsite init the inputs of the phi with top seems to simplify our life and seems to work.

Okay, interesting. Maybe one of the Phis is folded too early or something. Could be worth investigating separately but out of scope for this issue.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2393675419

From mchevalier at openjdk.org  Wed Oct  1 09:35:39 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 1 Oct 2025 09:35:39 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v2]
In-Reply-To: <-Oa2kcVEzgCQPt3unbHXAC_LoOeq_qKbnjYfCW1ZRfc=.e06691b6-4c95-4805-9cec-b5450045e2fb@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <ldjuHEQsxNxKu9SyWGPJgmzXeNwDVnduZOSRpf3EoVk=.aa4bdfa6-d3ab-4bd6-9374-050310643e92@github.com>
 <-Oa2kcVEzgCQPt3unbHXAC_LoOeq_qKbnjYfCW1ZRfc=.e06691b6-4c95-4805-9cec-b5450045e2fb@github.com>
Message-ID: <dH_zHimUYToqJoXzz0qTUDoSzgS8DxEXCr_a1AuWzM0=.164eae81-5c81-4ed3-a56e-4f48b3ce58bb@github.com>

On Wed, 1 Oct 2025 05:46:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set phis input to top initially, not merge with top.
>
> src/hotspot/share/opto/inlinetypenode.cpp line 57:
> 
>> 55:   PhiNode* oop;
>> 56:   if (phi_input_are_top) {
>> 57:     oop = PhiNode::make(region, top, t);
> 
> For readability, I would prefer:
> 
> `oop = PhiNode::make(region, phi_input_are_top ? top : vt->get_oop(), t)`

I guess that's a matter of taste... Done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2393984851

From mchevalier at openjdk.org  Wed Oct  1 09:35:35 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 1 Oct 2025 09:35:35 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v3]
In-Reply-To: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
Message-ID: <ET6af25Hok4PxdjzJIdlkTzXfXHEhAW38c2FjaW05-c=.71707960-232e-4399-9634-e4f2c2935d31@github.com>

> ## Act I: dead loops
> 
> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
> 
> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
> 
> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
> 
> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
> 
> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java` fail in another way:...

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

  More comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1640/files
  - new: https://git.openjdk.org/valhalla/pull/1640/files/7af6110a..161cae4d

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

  Stats: 35 lines in 3 files changed: 0 ins; 22 del; 13 mod
  Patch: https://git.openjdk.org/valhalla/pull/1640.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1640/head:pull/1640

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

From mchevalier at openjdk.org  Wed Oct  1 09:35:36 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 1 Oct 2025 09:35:36 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v3]
In-Reply-To: <NRL_wzyX7yaDrSMb6VLIKTV7LAvJeSBOfCp4dlKEyd8=.c70c62e0-65c5-41b9-9559-cfd22de28062@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <6fj_6i-m-YsivIerjV65yKGCm8AJ0kg7PL6Dgz3-wkA=.5080da40-e309-4410-832f-ea1d094c9efa@github.com>
 <MfAwJeJsbkOnDV4U9w3ObtTxuVWy-wZgMITWMU0GUf4=.d3d3c1e6-a796-490c-9bcc-7272f39532fd@github.com>
 <NRL_wzyX7yaDrSMb6VLIKTV7LAvJeSBOfCp4dlKEyd8=.c70c62e0-65c5-41b9-9559-cfd22de28062@github.com>
Message-ID: <qyPfU1UTdkF7HCmGrE4HZwq1nhO1gP6x8-6L_p3kISE=.6e2f3e4d-83ba-4176-afd4-b6148b9685e1@github.com>

On Wed, 1 Oct 2025 05:40:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> I wouldn't fight too hard for it, but when trying things, it was necessary (since I wanted different types for `uin`), but I also think it helps to see that it is not useful too long, and I can mess with it without having to look at what comes after. In this case, indeed, it feels a bit coming out of nowhere at the end...
>> 
>> In C++17, I'd do:
>> ```c++
>>  if (Node* uin = unique_constant_input_recursive(phase); uin != nullptr) {
>>   return uin;
>> }
>> 
>> one could also do
>> ```c++
>>  if (Node* uin = unique_constant_input_recursive(phase)) {
>>   return uin;
>> }
>> 
>> if we are not afraid of implicit conditions (but we are, and I'm fine with it!).
>
> Right but now that both `uin` have the same type, the scoping seems unnecessary.

Unnecessary to make it compile. But I still think it's helpful: each block can be rearranged since it doesn't change the semantics of an outer-living variable. It makes explicit that `uin` isn't used after... But I said I won't fight too hard, so I reverted!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1640#discussion_r2393981991

From dsimms at openjdk.org  Wed Oct  1 10:33:18 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 1 Oct 2025 10:33:18 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <_oG3htyVcqtkXGQT3g3gA6cmWZXTnuF7jbTBDiUGTUA=.8c6baebf-9862-4d0a-885b-f4752132b5f6@github.com>

Merge tag 'jdk-26+12' into lworld_merge_jdk_26_12

Added tag jdk-26+12 for changeset 02fe095d

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

Commit messages:
 - Merge jdk
 - 8364934: G1: Rename members of G1CollectionSet
 - 8365115: G1: Refactor rem set statistics gather code for group
 - 8364962: G1: Inline G1CollectionSet::finalize_incremental_building
 - 8365026: G1: Initialization should start a "full" new collection set
 - 8364414: G1: Use simpler data structure for holding collection set candidates during calculation
 - 8364532: G1: In liveness tracing, print more significant digits for the liveness value
 - 8364925: G1: Improve program flow around incremental collection set building
 - 8364650: G1: Use InvalidCSetIndex instead of UINT_MAX for "invalid" sentinel value of young_index_in_cset
 - 8365910: [BACKOUT] Add a compilation timeout flag to catch long running compilations
 - ... and 86 more: https://git.openjdk.org/valhalla/compare/29df705a...a45ea3e2

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

Changes: https://git.openjdk.org/valhalla/pull/1649/files
  Stats: 11936 lines in 476 files changed: 6994 ins; 3176 del; 1766 mod
  Patch: https://git.openjdk.org/valhalla/pull/1649.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1649/head:pull/1649

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

From thartmann at openjdk.org  Wed Oct  1 10:33:44 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 1 Oct 2025 10:33:44 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v3]
In-Reply-To: <ET6af25Hok4PxdjzJIdlkTzXfXHEhAW38c2FjaW05-c=.71707960-232e-4399-9634-e4f2c2935d31@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <ET6af25Hok4PxdjzJIdlkTzXfXHEhAW38c2FjaW05-c=.71707960-232e-4399-9634-e4f2c2935d31@github.com>
Message-ID: <phh9MNQ7by4AK9LmdX7i_XwaIy7mTiVWaBYwCD-52JQ=.496fc46a-1481-4475-b0ae-3ff13643cf3c@github.com>

On Wed, 1 Oct 2025 09:35:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> ## Act I: dead loops
>> 
>> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
>> 
>> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
>> 
>> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
>> 
>> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
>> 
>> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More comments

Looks great, thanks for your patience! :)

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1640#pullrequestreview-3288478800

From coleenp at openjdk.org  Wed Oct  1 13:13:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 1 Oct 2025 13:13:17 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word
In-Reply-To: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
Message-ID: <wxIaecFVlOygE9WfrZXePXQyeRK9ymFSXOrMg2uMsNk=.c1d9fa1b-2170-4c99-b65c-b6fdf63e19ee@github.com>

On Fri, 12 Sep 2025 09:43:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
> 
> Specifically, there are three portions to this change:
> - Moving the age bits lower to their intended position.
> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
> 
> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

Looks good!

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1578#pullrequestreview-3288947725

From phubner at openjdk.org  Wed Oct  1 13:13:17 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 1 Oct 2025 13:13:17 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of mark
 word
Message-ID: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>

Hi all, 

This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 

Specifically, there are three portions to this change:
- Moving the age bits lower to their intended position.
- Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
- Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.

Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

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

Commit messages:
 - Revise documentation.
 - Fix hashCode intrinsic miscompilation.
 - Fix outdated markWord test semantics.
 - Chuck out weird markWord code.
 - Emulate old Valhalla decode_pointer behavior.
 - Fix typo.
 - Follow JEP450 MarkWord specification.

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

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

From phubner at openjdk.org  Wed Oct  1 13:24:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 1 Oct 2025 13:24:50 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word
In-Reply-To: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
Message-ID: <cSWvZ56ZSfm7MDEe9dH5utsIy2YJG_fbloXjOJJdKEs=.4f500b2a-3f1c-4890-8a4c-d4e17bd39b93@github.com>

On Fri, 12 Sep 2025 09:43:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
> 
> Specifically, there are three portions to this change:
> - Moving the age bits lower to their intended position.
> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
> 
> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

I'm going to go merge in the latest changes and re-run testing. I'll update the PR description with the testing result summary when done.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1578#issuecomment-3356286913

From fparain at openjdk.org  Wed Oct  1 13:24:50 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 Oct 2025 13:24:50 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word
In-Reply-To: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
Message-ID: <yXmvLPopwpL1zDKc4lIKOq0zR2-_9JweNm1Uv0WiePI=.6a0932d2-5082-447b-a17a-bea82574ebea@github.com>

On Fri, 12 Sep 2025 09:43:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
> 
> Specifically, there are three portions to this change:
> - Moving the age bits lower to their intended position.
> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
> 
> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

src/hotspot/share/oops/markWord.hpp line 428:

> 426: 
> 427:  private:
> 428:   inline uintptr_t write_bits(uintptr_t input, uintptr_t val, uint start, uint end) const {

Where is this method used?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1578#discussion_r2394561107

From phubner at openjdk.org  Wed Oct  1 13:24:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 1 Oct 2025 13:24:50 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word
In-Reply-To: <yXmvLPopwpL1zDKc4lIKOq0zR2-_9JweNm1Uv0WiePI=.6a0932d2-5082-447b-a17a-bea82574ebea@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
 <yXmvLPopwpL1zDKc4lIKOq0zR2-_9JweNm1Uv0WiePI=.6a0932d2-5082-447b-a17a-bea82574ebea@github.com>
Message-ID: <1qh_sRikZ8_k8GkxfLW8PqKb0mFkeG3SrwgdJb7pzIk=.4a247ab4-0f70-4f12-a8bb-4642e3a3a2fa@github.com>

On Wed, 1 Oct 2025 13:21:18 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
>> 
>> Specifically, there are three portions to this change:
>> - Moving the age bits lower to their intended position.
>> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
>> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
>> 
>> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.
>
> src/hotspot/share/oops/markWord.hpp line 428:
> 
>> 426: 
>> 427:  private:
>> 428:   inline uintptr_t write_bits(uintptr_t input, uintptr_t val, uint start, uint end) const {
> 
> Where is this method used?

Good catch, it's left over from a prototype. Sorry about that, will remove.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1578#discussion_r2394564136

From fparain at openjdk.org  Wed Oct  1 14:22:18 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 Oct 2025 14:22:18 GMT
Subject: [lworld] Integrated: 8367767: [lworld] Interpreter adherence to new
 memory model rules for strict instance fields
Message-ID: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>

Create new method entry for the interpreter to add a memory barrier when entering the j.l.Object constructor.

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

Commit messages:
 - Add arm platform and comments
 - Fix method kind selection
 - Add memory barrier when entering the j.l.Object constructor

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

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

From heidinga at openjdk.org  Wed Oct  1 14:22:20 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 1 Oct 2025 14:22:20 GMT
Subject: [lworld] Integrated: 8367767: [lworld] Interpreter adherence to
 new memory model rules for strict instance fields
In-Reply-To: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
References: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
Message-ID: <wufMtWoOfqAHtJGWA4DywQJWZmnlzoOZn3fq9G-_ads=.895227b7-e83b-4d8d-b732-e1ef9f3ac9e1@github.com>

On Tue, 30 Sep 2025 19:29:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Create new method entry for the interpreter to add a memory barrier when entering the j.l.Object constructor.

Apart from the request for comments on the unchanged ports so we know the barrier isn't needed and is deliberately skipped, this looks great!

Thanks Fred

src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 1:

> 1: /*

Can you add a comment mentioning StoreStore at the equivalent place in this method?  It'll make it easier to find where the barrier is expected / compare across platforms.  I always trip on the fact that the x86 `_return` implementation doesn't mention anything

src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 1142:

> 1140: // Generic interpreted method entry to (asm) interpreter
> 1141: //
> 1142: address TemplateInterpreterGenerator::generate_normal_entry(bool synchronized, bool object_init) {

Same request about a comment here

src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1242:

> 1240: // Generic interpreted method entry to (asm) interpreter
> 1241: //
> 1242: address TemplateInterpreterGenerator::generate_normal_entry(bool synchronized, bool object_init) {

Same request for a comment so there's breadcrumbs to find

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1647#pullrequestreview-3286462141
PR Review: https://git.openjdk.org/valhalla/pull/1647#pullrequestreview-3289427747
PR Review Comment: https://git.openjdk.org/valhalla/pull/1647#discussion_r2392648397
PR Review Comment: https://git.openjdk.org/valhalla/pull/1647#discussion_r2392648933
PR Review Comment: https://git.openjdk.org/valhalla/pull/1647#discussion_r2392650179

From fparain at openjdk.org  Wed Oct  1 14:22:21 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 Oct 2025 14:22:21 GMT
Subject: [lworld] Integrated: 8367767: [lworld] Interpreter adherence to
 new memory model rules for strict instance fields
In-Reply-To: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
References: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
Message-ID: <1qsJ5_hJx9QcV3FhkKZAsYyX5-gfOmHIUtfEf4Mt1zo=.b733487e-bd93-4c1c-ba73-e26246084672@github.com>

On Tue, 30 Sep 2025 19:29:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Create new method entry for the interpreter to add a memory barrier when entering the j.l.Object constructor.

Thanks for the idea and review Dan.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1647#issuecomment-3356560048

From fparain at openjdk.org  Wed Oct  1 14:22:23 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 Oct 2025 14:22:23 GMT
Subject: [lworld] Integrated: 8367767: [lworld] Interpreter adherence to new
 memory model rules for strict instance fields
In-Reply-To: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
References: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
Message-ID: <9j45ZplSVO7hARRHiiqQoVEUyeqeNOPhRn1IZ8yv1HQ=.1fde503a-6b23-4632-98ec-c1d63051fcef@github.com>

On Tue, 30 Sep 2025 19:29:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Create new method entry for the interpreter to add a memory barrier when entering the j.l.Object constructor.

This pull request has now been integrated.

Changeset: 2bc50b32
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2bc50b323a5c57f5d55094196729f54b7dd98302
Stats:     58 lines in 10 files changed: 50 ins; 0 del; 8 mod

8367767: [lworld] Interpreter adherence to new memory model rules for strict instance fields

Co-authored-by: Dan Heidinga <heidinga at openjdk.org>
Reviewed-by: heidinga

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

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

From fparain at openjdk.org  Wed Oct  1 14:22:21 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 Oct 2025 14:22:21 GMT
Subject: [lworld] Integrated: 8367767: [lworld] Interpreter adherence to
 new memory model rules for strict instance fields
In-Reply-To: <wufMtWoOfqAHtJGWA4DywQJWZmnlzoOZn3fq9G-_ads=.895227b7-e83b-4d8d-b732-e1ef9f3ac9e1@github.com>
References: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
 <wufMtWoOfqAHtJGWA4DywQJWZmnlzoOZn3fq9G-_ads=.895227b7-e83b-4d8d-b732-e1ef9f3ac9e1@github.com>
Message-ID: <lkMdNjZRvGfteQiWAZo-1DhkIWWxkU_VRoRfIsBnqkA=.8ef0a7b9-33b9-4c14-b810-5328a7fcdcdd@github.com>

On Tue, 30 Sep 2025 19:40:07 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Create new method entry for the interpreter to add a memory barrier when entering the j.l.Object constructor.
>
> src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 1:
> 
>> 1: /*
> 
> Can you add a comment mentioning StoreStore at the equivalent place in this method?  It'll make it easier to find where the barrier is expected / compare across platforms.  I always trip on the fact that the x86 `_return` implementation doesn't mention anything

Done

> src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp line 1142:
> 
>> 1140: // Generic interpreted method entry to (asm) interpreter
>> 1141: //
>> 1142: address TemplateInterpreterGenerator::generate_normal_entry(bool synchronized, bool object_init) {
> 
> Same request about a comment here

Add the barrier here, because I think the platform needs it.

> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1242:
> 
>> 1240: // Generic interpreted method entry to (asm) interpreter
>> 1241: //
>> 1242: address TemplateInterpreterGenerator::generate_normal_entry(bool synchronized, bool object_init) {
> 
> Same request for a comment so there's breadcrumbs to find

Done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1647#discussion_r2394753688
PR Review Comment: https://git.openjdk.org/valhalla/pull/1647#discussion_r2394756075
PR Review Comment: https://git.openjdk.org/valhalla/pull/1647#discussion_r2394757131

From vromero at openjdk.org  Wed Oct  1 15:32:07 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Oct 2025 15:32:07 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue
Message-ID: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>

redoing JDK-8367698 as the original fix had to be delta applied due to some test failures

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

Commit messages:
 - fixing another test failure
 - Merge branch 'lworld' into JDK-8368497
 - Merge branch 'lworld' into JDK-8368497
 - Merge branch 'lworld' into JDK-8368497
 - Merge branch 'lworld' into JDK-8368497
 - 8368497: [lworld] redo: New lint category  for code that would not be allowed in the prologue

Changes: https://git.openjdk.org/valhalla/pull/1650/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1650&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368497
  Stats: 669 lines in 78 files changed: 574 ins; 9 del; 86 mod
  Patch: https://git.openjdk.org/valhalla/pull/1650.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1650/head:pull/1650

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

From roger.riggs at oracle.com  Wed Oct  1 15:59:14 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 1 Oct 2025 11:59:14 -0400
Subject: Value class for ZoneOffset?
In-Reply-To: <48550302-9fae-42d8-a78e-cb8e9eb2ddd7@oracle.com>
References: <CACzrW9AUztzOMy=BbFh6pCmwUpHBqSy8WCaarnbae-r4uqZEag@mail.gmail.com>
 <48550302-9fae-42d8-a78e-cb8e9eb2ddd7@oracle.com>
Message-ID: <a7b36e49-4115-44c1-a787-749e5050feee@oracle.com>

Hi Stephen,

Yes, we didn't take the time to refactor ZoneOffset to be a value class 
and yes, the cache was the bump in the road on that.

We'll take another look at it.

Regards, Roger

On 9/30/25 5:10 PM, Brian Goetz wrote:
> Dan can fill in the details on this specific case, but by way of 
> background, for JEP 401 we're not trying to migrate _every_ candidate 
> value class in the JDK -- just a good set of the most common ones.? So 
> any list we came up with is surely going to be just an approximation, 
> not the last word.
>
> On 9/30/2025 5:04 PM, Stephen Colebourne wrote:
>> I notice from the updated JEPhttps://openjdk.org/jeps/401 that
>> ZoneOffset is not intended to become a value class. I assume this is
>> because of the id and rules cache variables?
>>
>> It seems to me that ZoneOffset is very much applicable to be a value,
>> as it's state is fundamentally an int. Performance tests would be
>> needed, but it might be possible to create the id and rules on the fly
>> rather than caching them.
>>
>> thanks
>> Stephen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251001/99d79451/attachment.htm>

From fparain at openjdk.org  Wed Oct  1 16:32:53 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 1 Oct 2025 16:32:53 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word
In-Reply-To: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
Message-ID: <vej3oRqJ5pqpVelG6NgeNxcqI1ypdk7JnLSRyuVcm18=.902f5c17-22b7-4114-8661-a7d229ee6079@github.com>

On Fri, 12 Sep 2025 09:43:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
> 
> Specifically, there are three portions to this change:
> - Moving the age bits lower to their intended position.
> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
> 
> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

With the removal of the unused method, this looks good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1578#pullrequestreview-3290052416

From vromero at openjdk.org  Wed Oct  1 20:20:46 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Oct 2025 20:20:46 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v2]
In-Reply-To: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
Message-ID: <2r2AFUOi4BViF1hQxvNrJkiOoIMAbYhGFU23RSqakZo=.cdbdd269-e7fe-4708-8275-eae61acce5c3@github.com>

> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures

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

  do not generate proxy variables for warned code

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1650/files
  - new: https://git.openjdk.org/valhalla/pull/1650/files/4865c380..4af18367

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

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

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

From liach at openjdk.org  Wed Oct  1 20:53:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 1 Oct 2025 20:53:57 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v2]
In-Reply-To: <2r2AFUOi4BViF1hQxvNrJkiOoIMAbYhGFU23RSqakZo=.cdbdd269-e7fe-4708-8275-eae61acce5c3@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
 <2r2AFUOi4BViF1hQxvNrJkiOoIMAbYhGFU23RSqakZo=.cdbdd269-e7fe-4708-8275-eae61acce5c3@github.com>
Message-ID: <4LBrK772eNVk7RKIBaO9d-P763bUyDy0KAhMLrlGFe8=.d2dab5e0-11bf-4cce-ba7b-7601f57fa9a9@github.com>

On Wed, 1 Oct 2025 20:20:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not generate proxy variables for warned code

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 190:

> 188:      */
> 189:     public static boolean isExplicitThisReference(Types types, Type.ClassType currentClass, JCTree tree) {
> 190:         Symbol.ClassSymbol currentClassSym = (Symbol.ClassSymbol)(types.erasure(currentClass)).tsym;

Suggestion:

        Symbol.ClassSymbol currentClassSym = (Symbol.ClassSymbol) types.erasure(currentClass).tsym;

src/jdk.compiler/share/classes/module-info.java line 170:

> 168:  * <tr><th scope="row">{@code incubating}           <td>use of incubating modules
> 169:  * <tr><th scope="row">{@code initialization}       <td>code in identity classes that wouldn't be allowed in early
> 170:  *                                                      construction due to a this dependency.

Suggestion:

 *                                                      construction due to a {@code this} dependency.

test/langtools/tools/javac/SuperInit/EarlyAssignments.java line 14:

> 12:  *          jdk.compiler/com.sun.tools.javac.main
> 13:  *          jdk.compiler/com.sun.tools.javac.tree
> 14:  *          jdk.compiler/com.sun.tools.javac.util

Can we put all these `@modules` into TEST.properties like this: https://github.com/openjdk/jdk/blob/db6320df980ebe7cf2a1c727970cc937ab549b97/test/jdk/jdk/classfile/TEST.properties#L2-L5

test/langtools/tools/javac/SuperInit/InitializationWarningTester.java line 143:

> 141:                 javaFile = p;
> 142:             } else if (p.toString().endsWith("out")) {
> 143:                 goldenFile = p;

Can we just do `baseDir.resolve(className + ".java")`, and do a `Files.exists` check for the golden file, instead of having complicated stuf like this?

test/lib/jdk/test/lib/NetworkConfiguration.java line 1:

> 1: /*

We should probably ignore initialization warnings for test libs at: https://github.com/openjdk/valhalla/blob/2bc50b323a5c57f5d55094196729f54b7dd98302/make/test/BuildTestLib.gmk#L65

test/micro/org/openjdk/bench/java/lang/StringEquals.java line 1:

> 1: /*

Instead of patching individual microbenchmarks, we should just include `initialization` here: https://github.com/openjdk/valhalla/blob/2bc50b323a5c57f5d55094196729f54b7dd98302/make/test/BuildMicrobenchmark.gmk#L86-L87

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1650#discussion_r2395836363
PR Review Comment: https://git.openjdk.org/valhalla/pull/1650#discussion_r2395837388
PR Review Comment: https://git.openjdk.org/valhalla/pull/1650#discussion_r2395858768
PR Review Comment: https://git.openjdk.org/valhalla/pull/1650#discussion_r2395863655
PR Review Comment: https://git.openjdk.org/valhalla/pull/1650#discussion_r2395871784
PR Review Comment: https://git.openjdk.org/valhalla/pull/1650#discussion_r2395869754

From vromero at openjdk.org  Thu Oct  2 02:27:02 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 02:27:02 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v3]
In-Reply-To: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
Message-ID: <D370gyxGALKiBaIEUblmDhwBpk9bAg-sIeBNR5wPRys=.5fa58574-a639-44a4-bdc5-78e8550fb336@github.com>

> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures

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

  improving comment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1650/files
  - new: https://git.openjdk.org/valhalla/pull/1650/files/4af18367..bc40ec8b

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

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

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

From vromero at openjdk.org  Thu Oct  2 04:02:11 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 04:02:11 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v4]
In-Reply-To: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
Message-ID: <CfW8cC-EIbffTMbWSCnduGgISnBCB6NK1kZJ_0t0B6M=.3ee7a218-047d-4856-9c2d-39158c14e421@github.com>

> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures

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

  Update src/jdk.compiler/share/classes/module-info.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1650/files
  - new: https://git.openjdk.org/valhalla/pull/1650/files/bc40ec8b..2b7e6817

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

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

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

From thartmann at openjdk.org  Thu Oct  2 06:56:17 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 2 Oct 2025 06:56:17 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word
In-Reply-To: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
Message-ID: <4TOgWrXby-hfktLOJF_08n3tUfBMTLwsymOKGl_0dbI=.0becd66a-bc64-4f60-bc82-ef84c2b612ba@github.com>

On Fri, 12 Sep 2025 09:43:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
> 
> Specifically, there are three portions to this change:
> - Moving the age bits lower to their intended position.
> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
> 
> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

Looks good to me. Good job investigating and fixing this!

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

> 5367:     // We cannot use the inline type mask as this may check bits that are overriden
> 5368:     // by an object monitor's pointer when inflating locking.
> 5369:     Node *lock_mask      = _gvn.MakeConX(markWord::lock_mask_in_place);

FTR, this merge commit broke it: https://github.com/openjdk/valhalla/commit/0e3418df579fa7d2c6f56b4064656a8223f362db

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1578#pullrequestreview-3292786797
PR Review Comment: https://git.openjdk.org/valhalla/pull/1578#discussion_r2397302008

From mchevalier at openjdk.org  Thu Oct  2 07:01:17 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 2 Oct 2025 07:01:17 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v3]
In-Reply-To: <ET6af25Hok4PxdjzJIdlkTzXfXHEhAW38c2FjaW05-c=.71707960-232e-4399-9634-e4f2c2935d31@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <ET6af25Hok4PxdjzJIdlkTzXfXHEhAW38c2FjaW05-c=.71707960-232e-4399-9634-e4f2c2935d31@github.com>
Message-ID: <eW1O6DIQVhsnzb23P688XoFnMJHYvUdjWkv1HjKGWw8=.317c638f-e04f-4e78-b121-1381d9f55dcf@github.com>

On Wed, 1 Oct 2025 09:35:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> ## Act I: dead loops
>> 
>> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
>> 
>> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
>> 
>> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
>> 
>> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
>> 
>> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More comments

Thanks @TobiHartmann!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1640#issuecomment-3359450825

From duke at openjdk.org  Thu Oct  2 07:01:17 2025
From: duke at openjdk.org (duke)
Date: Thu, 2 Oct 2025 07:01:17 GMT
Subject: [lworld] RFR: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected" [v3]
In-Reply-To: <ET6af25Hok4PxdjzJIdlkTzXfXHEhAW38c2FjaW05-c=.71707960-232e-4399-9634-e4f2c2935d31@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
 <ET6af25Hok4PxdjzJIdlkTzXfXHEhAW38c2FjaW05-c=.71707960-232e-4399-9634-e4f2c2935d31@github.com>
Message-ID: <0Sk4wLcBFw-DlUdpVitDE3eaNHPg-FZhZZW8I87ZLf4=.195287b6-e681-4b1b-afa1-74164471e706@github.com>

On Wed, 1 Oct 2025 09:35:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> ## Act I: dead loops
>> 
>> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
>> 
>> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
>> 
>> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
>> 
>> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
>> 
>> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More comments

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1640#issuecomment-3359457258

From phubner at openjdk.org  Thu Oct  2 08:26:56 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 2 Oct 2025 08:26:56 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word [v2]
In-Reply-To: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
Message-ID: <c3Pnqcwv61vcfdEx1Sh6pebGYPdR9lpYsJnc61E55LE=.f4c2ec4f-949a-49b4-a2e1-042338719f00@github.com>

> Hi all, 
> 
> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
> 
> Specifically, there are three portions to this change:
> - Moving the age bits lower to their intended position.
> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
> 
> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

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

 - Remove unused prototype method.
 - Merge branch 'lworld' into JDK-8367073
 - Revise documentation.
 - Fix hashCode intrinsic miscompilation.
 - Fix outdated markWord test semantics.
 - Chuck out weird markWord code.
 - Emulate old Valhalla decode_pointer behavior.
 - Fix typo.
 - Follow JEP450 MarkWord specification.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1578/files
  - new: https://git.openjdk.org/valhalla/pull/1578/files/8fe33b79..5b0b70ee

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

  Stats: 10750 lines in 383 files changed: 5195 ins; 4264 del; 1291 mod
  Patch: https://git.openjdk.org/valhalla/pull/1578.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1578/head:pull/1578

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

From mchevalier at openjdk.org  Thu Oct  2 09:27:20 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 2 Oct 2025 09:27:20 GMT
Subject: [lworld] Integrated: 8367242: [lworld] C2 compilation asserts with
 "dead loop detected"
In-Reply-To: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
References: <7zmVtgsYpXk_XKI4hpUoyZaRorpGJhgP2kRPz-SqthQ=.1ab46f37-3672-4ed3-acfe-2402fc3bfee1@github.com>
Message-ID: <yr3DSoNPrYdFuFAzYZojCKO5Z7Am_o7hutngvuisD7s=.31eb5742-cf65-463f-94cb-9f85aacfd23e@github.com>

On Fri, 26 Sep 2025 14:02:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> ## Act I: dead loops
> 
> [JDK-8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert](https://bugs.openjdk.org/browse/JDK-8336003), allows to replace a Phi node by a single input recursively through phis. This change was only added to Valhalla. In mainline, a Phi can be simplified to its single direct input, not through other phis. The valhalla version will work on loops, while the mainline version will reduce all the phis into a single input only if the blob of Phis is acyclic.
> 
> When a loop is dead, it is possible that the said single input is also an output of the phi. After applying the identity, the phi's unique input becomes its own output (or input). For most nodes, that is not allowed. This is probably relatively harmless as the whole code around is dead and will be removed, but it makes some verification fail. It is also possible that some other idealization are not protected against data loops without phis on the way, and would not terminate. It is interesting to notice that applying [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to mainline is enough to reproduce the bug there too.
> 
> We could detect when it's about to happen, and handle the situation differently if we are about to create a very small loop that would be caught by the dead loop detection. It would be possible to make big dead data loop. How annoying that is? Immediately, there is the non-termination problem mentioned above. But also, maybe some nodes can be optimized away by IGVN and end up with a small loop and then the assert would strike again. Is the dead loop check too weak then? It depends what we think is the purpose of this check. During IGVN, we cannot clean up eagerly every dead loop since it would be too expensive to traverse everything. Avoiding dead data loop would also need a lot of traversal. My understanding is that it's rather a sanity check, to make sure that one doesn't mess up the graph surgery and create dead loops accidentally, when something else was meant, and detecting as soon as possible is helpful. So I'm not sure it's worth strengthening the check.
> 
> A way to avoid the creation of dead data loop is to simply limit the simplification allowed by [JDK-8336003](https://bugs.openjdk.org/browse/JDK-8336003) to constant nodes: since they don't have input, they can't make a cycle! And it seems enough for the bug initially reported.
> 
> Yet, that makes `test151` in `compiler/valhalla/inlinetypes/TestLWorld.java` fail in another way:...

This pull request has now been integrated.

Changeset: 2abd3a90
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2abd3a90185e5ec06f3cb12b92d9d0452681673e
Stats:     27 lines in 4 files changed: 15 ins; 0 del; 12 mod

8367242: [lworld] C2 compilation asserts with "dead loop detected"

Reviewed-by: thartmann

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

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

From vromero at openjdk.org  Thu Oct  2 11:41:58 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 11:41:58 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v5]
In-Reply-To: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
Message-ID: <vjeOYZXogqYKbjUV5boTkVaUUmySnYdLDX2qZkTpRyM=.a8da8937-9a2d-487e-9198-d649072dd1f6@github.com>

> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures

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

  Update src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1650/files
  - new: https://git.openjdk.org/valhalla/pull/1650/files/2b7e6817..3c7b8d9b

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

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

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

From thartmann at openjdk.org  Thu Oct  2 12:24:20 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 2 Oct 2025 12:24:20 GMT
Subject: [lworld] Integrated: 8367767: [lworld] Interpreter adherence to
 new memory model rules for strict instance fields
In-Reply-To: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
References: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
Message-ID: <6vju-TErrU488G5u4HcO5BGT-_Sy805yWDVup_6Vhz4=.92e1e74b-9172-4791-ac34-0173aa37bd76@github.com>

On Tue, 30 Sep 2025 19:29:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Create new method entry for the interpreter to add a memory barrier when entering the j.l.Object constructor.

src/hotspot/share/interpreter/abstractInterpreter.cpp line 157:

> 155:           // We need to execute the special return bytecode to check for
> 156:           // finalizer registration so create a normal frame.
> 157:           // No need to use the method kind with a memory barrier on entry

I don't think this is correct because the return bytecode will be rewritten: 
https://github.com/openjdk/valhalla/blob/2abd3a90185e5ec06f3cb12b92d9d0452681673e/src/hotspot/share/interpreter/rewriter.cpp#L537-L541
->
https://github.com/openjdk/valhalla/blob/2abd3a90185e5ec06f3cb12b92d9d0452681673e/src/hotspot/share/interpreter/rewriter.cpp#L161

And thus, this code will never be executed:
https://github.com/openjdk/valhalla/blob/2abd3a90185e5ec06f3cb12b92d9d0452681673e/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp#L2310-L2314

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1647#discussion_r2398611543

From thartmann at openjdk.org  Thu Oct  2 13:04:28 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 2 Oct 2025 13:04:28 GMT
Subject: [lworld] Integrated: 8367767: [lworld] Interpreter adherence to
 new memory model rules for strict instance fields
In-Reply-To: <6vju-TErrU488G5u4HcO5BGT-_Sy805yWDVup_6Vhz4=.92e1e74b-9172-4791-ac34-0173aa37bd76@github.com>
References: <fKBcWym9Lm7lJr2DHD2PQ4l9cHsiHCGksF_1c7ML7Ss=.44eece1d-47eb-4877-a470-0a88dd0c4d6f@github.com>
 <6vju-TErrU488G5u4HcO5BGT-_Sy805yWDVup_6Vhz4=.92e1e74b-9172-4791-ac34-0173aa37bd76@github.com>
Message-ID: <rAeTKTiN5jXUmLrDz_d9PXKl_bswBGuoYxSxQMHZ9j4=.db6d96d8-7685-41fa-a9cc-ea54f8b15f59@github.com>

On Thu, 2 Oct 2025 12:21:07 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Create new method entry for the interpreter to add a memory barrier when entering the j.l.Object constructor.
>
> src/hotspot/share/interpreter/abstractInterpreter.cpp line 157:
> 
>> 155:           // We need to execute the special return bytecode to check for
>> 156:           // finalizer registration so create a normal frame.
>> 157:           // No need to use the method kind with a memory barrier on entry
> 
> I don't think this is correct because the return bytecode will be rewritten: 
> https://github.com/openjdk/valhalla/blob/2abd3a90185e5ec06f3cb12b92d9d0452681673e/src/hotspot/share/interpreter/rewriter.cpp#L537-L541
> ->
> https://github.com/openjdk/valhalla/blob/2abd3a90185e5ec06f3cb12b92d9d0452681673e/src/hotspot/share/interpreter/rewriter.cpp#L161
> 
> And thus, this code will never be executed:
> https://github.com/openjdk/valhalla/blob/2abd3a90185e5ec06f3cb12b92d9d0452681673e/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp#L2310-L2314

I filed [JDK-8369044](https://bugs.openjdk.org/browse/JDK-8369044).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1647#discussion_r2398768237

From fparain at openjdk.org  Thu Oct  2 13:29:39 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 2 Oct 2025 13:29:39 GMT
Subject: [lworld] RFR: 8369044: [lworld] Interpreter does not emit barrier at
 the end of java.lang.Object::<init>
Message-ID: <vpGj7x-q6LyAujqap0v3pZqILuJgQmrUB-qa4fi1DsI=.2772af1c-29cc-4ffa-8e4a-783fd795cdeb@github.com>

The rewriting of the _return bytecode in j.l.Object.<init> method was preventing the generation of the barrier, this fix solves the issue.

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

Commit messages:
 - Fix init barrier for j.l.Object

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

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

From thartmann at openjdk.org  Thu Oct  2 13:34:30 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 2 Oct 2025 13:34:30 GMT
Subject: [lworld] RFR: 8369044: [lworld] Interpreter does not emit barrier
 at the end of java.lang.Object::<init>
In-Reply-To: <vpGj7x-q6LyAujqap0v3pZqILuJgQmrUB-qa4fi1DsI=.2772af1c-29cc-4ffa-8e4a-783fd795cdeb@github.com>
References: <vpGj7x-q6LyAujqap0v3pZqILuJgQmrUB-qa4fi1DsI=.2772af1c-29cc-4ffa-8e4a-783fd795cdeb@github.com>
Message-ID: <QhE3IT-GwYY13kfLu1XpflHzCGib7fonh1-tUHatM_4=.0e1d94cd-0d0c-4620-8415-2e81dd20c36d@github.com>

On Thu, 2 Oct 2025 13:23:50 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> The rewriting of the _return bytecode in j.l.Object.<init> method was preventing the generation of the barrier, this fix solves the issue.

Looks good to me but I'm not an interpreter expert :)

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1652#pullrequestreview-3294657994

From dfenacci at openjdk.org  Thu Oct  2 14:06:36 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 2 Oct 2025 14:06:36 GMT
Subject: [lworld] RFR: 8368939: [lworld] TestInliningProtectionDomain fails
 since jdk-26+11
Message-ID: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>

## Issue
`compiler/ciReplay/TestInliningProtectionDomain.java` for class `ProtectionDomainTestNoOtherCompilationPrivate` fails because it expects `bar()` not to be inlined but it gets inlined instead.

## Cause
`TestInliningProtectionDomain` checks that ciReplay inlining does not fail with unresolved signature classes. For class `ProtectionDomainTestNoOtherCompilationPrivate` it expects `Integer` in its signature to be unresolved but it is resolved instead. The reason for this is that in valhalla boxing classes are automatically added when registering a loader ([JDK-8364034](https://bugs.openjdk.org/browse/JDK-8364034) (and later [JDK-8364483](https://bugs.openjdk.org/browse/JDK-8364483)):
https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/classfile/systemDictionary.cpp#L215-L217

## Fix
`TestInliningProtectionDomain` should actually use a different class than `Integer` (a class that is not in the migrated value classes set, like `java.lang.Thread`. Changed in all classes for "consistency").

## Testing
Tier 1-3

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

Commit messages:
 - JDK-8368939: update copyright year
 - JDK-8368939: [lworld] TestInliningProtectionDomain fails since jdk-26+11

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

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

From thartmann at openjdk.org  Thu Oct  2 14:14:10 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 2 Oct 2025 14:14:10 GMT
Subject: [lworld] RFR: 8368939: [lworld] TestInliningProtectionDomain fails
 since jdk-26+11
In-Reply-To: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
References: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
Message-ID: <Anl19QBFR-va8DDHQ-kC0Ry0dLB5gUoQ2O5Kyhqcsmc=.33a4f67e-c1dc-4b06-8cf9-1ee04ed4c005@github.com>

On Thu, 2 Oct 2025 10:23:22 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> `compiler/ciReplay/TestInliningProtectionDomain.java` for class `ProtectionDomainTestNoOtherCompilationPrivate` fails because it expects `bar()` not to be inlined but it gets inlined instead.
> 
> ## Cause
> `TestInliningProtectionDomain` checks that ciReplay inlining does not fail with unresolved signature classes. For class `ProtectionDomainTestNoOtherCompilationPrivate` it expects `Integer` in its signature to be unresolved but it is resolved instead. The reason for this is that in valhalla boxing classes are automatically added when registering a loader ([JDK-8364034](https://bugs.openjdk.org/browse/JDK-8364034) (and later [JDK-8364483](https://bugs.openjdk.org/browse/JDK-8364483)):
> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/classfile/systemDictionary.cpp#L215-L217
> 
> ## Fix
> `TestInliningProtectionDomain` should actually use a different class than `Integer` (a class that is not in the migrated value classes set, like `java.lang.Thread`. Changed in all classes for "consistency").
> 
> ## Testing
> Tier 1-3

test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java line 156:

> 154:     }
> 155: 
> 156:     // String should be unresovled for the protection domain of this class because getDeclaredMethods is called in normal run

Shouldn't this be `resolved` as the comment explains?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1651#discussion_r2398984531

From vromero at openjdk.org  Thu Oct  2 14:16:08 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 14:16:08 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v2]
In-Reply-To: <4LBrK772eNVk7RKIBaO9d-P763bUyDy0KAhMLrlGFe8=.d2dab5e0-11bf-4cce-ba7b-7601f57fa9a9@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
 <2r2AFUOi4BViF1hQxvNrJkiOoIMAbYhGFU23RSqakZo=.cdbdd269-e7fe-4708-8275-eae61acce5c3@github.com>
 <4LBrK772eNVk7RKIBaO9d-P763bUyDy0KAhMLrlGFe8=.d2dab5e0-11bf-4cce-ba7b-7601f57fa9a9@github.com>
Message-ID: <r0m6WKhOfzo7AWHSAXp9XBBtIYcktGbSvHIO5NJfEdU=.c288585c-093b-4f3c-b159-df18fe904cd2@github.com>

On Wed, 1 Oct 2025 20:51:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do not generate proxy variables for warned code
>
> test/lib/jdk/test/lib/NetworkConfiguration.java line 1:
> 
>> 1: /*
> 
> We should probably ignore initialization warnings for test libs at: https://github.com/openjdk/valhalla/blob/2bc50b323a5c57f5d55094196729f54b7dd98302/make/test/BuildTestLib.gmk#L65

yes we could, but I prefer not to. I found bugs in the original implementation by analyzing case by case the reason for the warnings. If we remove it for all tests then we could be blinded to lwrking bugs

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1650#discussion_r2398992215

From dfenacci at openjdk.org  Thu Oct  2 14:52:46 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 2 Oct 2025 14:52:46 GMT
Subject: [lworld] RFR: 8368939: [lworld] TestInliningProtectionDomain fails
 since jdk-26+11 [v2]
In-Reply-To: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
References: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
Message-ID: <CzDkyR_h-GZxEwnR8det75Z9X2Gh7eO-vYEXTRtQzmc=.d421ed39-b596-452c-b187-4c2c4bb6553e@github.com>

> ## Issue
> `compiler/ciReplay/TestInliningProtectionDomain.java` for class `ProtectionDomainTestNoOtherCompilationPrivate` fails because it expects `bar()` not to be inlined but it gets inlined instead.
> 
> ## Cause
> `TestInliningProtectionDomain` checks that ciReplay inlining does not fail with unresolved signature classes. For class `ProtectionDomainTestNoOtherCompilationPrivate` it expects `Integer` in its signature to be unresolved but it is resolved instead. The reason for this is that in valhalla boxing classes are automatically added when registering a loader ([JDK-8364034](https://bugs.openjdk.org/browse/JDK-8364034) (and later [JDK-8364483](https://bugs.openjdk.org/browse/JDK-8364483)):
> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/classfile/systemDictionary.cpp#L215-L217
> 
> ## Fix
> `TestInliningProtectionDomain` should actually use a different class than `Integer` (a class that is not in the migrated value classes set, like `java.lang.Thread`. Changed in all classes for "consistency").
> 
> ## Testing
> Tier 1-3

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8368939: fixed comment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1651/files
  - new: https://git.openjdk.org/valhalla/pull/1651/files/3fed0ea2..51858f4c

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

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

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

From dfenacci at openjdk.org  Thu Oct  2 14:52:48 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 2 Oct 2025 14:52:48 GMT
Subject: [lworld] RFR: 8368939: [lworld] TestInliningProtectionDomain fails
 since jdk-26+11 [v2]
In-Reply-To: <Anl19QBFR-va8DDHQ-kC0Ry0dLB5gUoQ2O5Kyhqcsmc=.33a4f67e-c1dc-4b06-8cf9-1ee04ed4c005@github.com>
References: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
 <Anl19QBFR-va8DDHQ-kC0Ry0dLB5gUoQ2O5Kyhqcsmc=.33a4f67e-c1dc-4b06-8cf9-1ee04ed4c005@github.com>
Message-ID: <TzBcggUaQ3ryQnm8mQBdagjrCVZqbt3Z_8ZzcAr31hc=.05682094-fe08-47aa-82f2-abfb0b4b27e6@github.com>

On Thu, 2 Oct 2025 14:11:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8368939: fixed comment
>
> test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java line 156:
> 
>> 154:     }
>> 155: 
>> 156:     // String should be unresovled for the protection domain of this class because getDeclaredMethods is called in normal run
> 
> Shouldn't this be `resolved` as the comment explains?

Indeed. I got confused by the "but" at the end. Fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1651#discussion_r2399098265

From fparain at openjdk.org  Thu Oct  2 15:10:42 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 2 Oct 2025 15:10:42 GMT
Subject: [lworld] Integrated: 8369044: [lworld] Interpreter does not emit
 barrier at the end of java.lang.Object::<init>
In-Reply-To: <vpGj7x-q6LyAujqap0v3pZqILuJgQmrUB-qa4fi1DsI=.2772af1c-29cc-4ffa-8e4a-783fd795cdeb@github.com>
References: <vpGj7x-q6LyAujqap0v3pZqILuJgQmrUB-qa4fi1DsI=.2772af1c-29cc-4ffa-8e4a-783fd795cdeb@github.com>
Message-ID: <myeescpjbaJQU1doH4vwgQkktXVLIFhBZnZWJUB7y1A=.37e12f3a-fd59-4749-97e5-610316c2c34b@github.com>

On Thu, 2 Oct 2025 13:23:50 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> The rewriting of the _return bytecode in j.l.Object.<init> method was preventing the generation of the barrier, this fix solves the issue.

This pull request has now been integrated.

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

8369044: [lworld] Interpreter does not emit barrier at the end of java.lang.Object::<init>

Reviewed-by: thartmann

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

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

From fparain at openjdk.org  Thu Oct  2 15:10:42 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 2 Oct 2025 15:10:42 GMT
Subject: [lworld] RFR: 8369044: [lworld] Interpreter does not emit barrier
 at the end of java.lang.Object::<init>
In-Reply-To: <vpGj7x-q6LyAujqap0v3pZqILuJgQmrUB-qa4fi1DsI=.2772af1c-29cc-4ffa-8e4a-783fd795cdeb@github.com>
References: <vpGj7x-q6LyAujqap0v3pZqILuJgQmrUB-qa4fi1DsI=.2772af1c-29cc-4ffa-8e4a-783fd795cdeb@github.com>
Message-ID: <vWI18nh4c2-QfCfPD-gaM5rF-KQN3rGVrL4UL7iYgzM=.7dc3ee06-8ce3-4613-821e-952fe02e314e@github.com>

On Thu, 2 Oct 2025 13:23:50 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> The rewriting of the _return bytecode in j.l.Object.<init> method was preventing the generation of the barrier, this fix solves the issue.

Thank your for the review Tobias

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

PR Comment: https://git.openjdk.org/valhalla/pull/1652#issuecomment-3361636066

From vromero at openjdk.org  Thu Oct  2 16:50:27 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 16:50:27 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v6]
In-Reply-To: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
Message-ID: <BLAUPitCygzDRQPhplPbPkyZutl_lFLq4Bdt7nWSnxo=.cedb076e-43e6-44b5-9769-8414f6bee6a4@github.com>

> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures

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/1650/files
  - new: https://git.openjdk.org/valhalla/pull/1650/files/3c7b8d9b..4878eea3

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

  Stats: 1632 lines in 59 files changed: 728 ins; 902 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1650.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1650/head:pull/1650

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

From vromero at openjdk.org  Thu Oct  2 16:50:30 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 16:50:30 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v2]
In-Reply-To: <4LBrK772eNVk7RKIBaO9d-P763bUyDy0KAhMLrlGFe8=.d2dab5e0-11bf-4cce-ba7b-7601f57fa9a9@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
 <2r2AFUOi4BViF1hQxvNrJkiOoIMAbYhGFU23RSqakZo=.cdbdd269-e7fe-4708-8275-eae61acce5c3@github.com>
 <4LBrK772eNVk7RKIBaO9d-P763bUyDy0KAhMLrlGFe8=.d2dab5e0-11bf-4cce-ba7b-7601f57fa9a9@github.com>
Message-ID: <D5kBX2QIGPFrLDsz2q7KCeEIclhn5bIszJJDBLWXjfM=.c8d246a6-7c43-4eec-aa17-caf9080f1389@github.com>

On Wed, 1 Oct 2025 20:47:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do not generate proxy variables for warned code
>
> test/langtools/tools/javac/SuperInit/InitializationWarningTester.java line 143:
> 
>> 141:                 javaFile = p;
>> 142:             } else if (p.toString().endsWith("out")) {
>> 143:                 goldenFile = p;
> 
> Can we just do `baseDir.resolve(className + ".java")`, and do a `Files.exists` check for the golden file, instead of having complicated stuf like this?

yep I wanted to clean that before pushing but then I forgot, thanks

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1650#discussion_r2399414143

From liach at openjdk.org  Thu Oct  2 16:52:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 2 Oct 2025 16:52:51 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v6]
In-Reply-To: <BLAUPitCygzDRQPhplPbPkyZutl_lFLq4Bdt7nWSnxo=.cedb076e-43e6-44b5-9769-8414f6bee6a4@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
 <BLAUPitCygzDRQPhplPbPkyZutl_lFLq4Bdt7nWSnxo=.cedb076e-43e6-44b5-9769-8414f6bee6a4@github.com>
Message-ID: <ZHDLaFyyHnVqnKoZ2yjXDCnLjwF_E2gKXfI1eCEu98s=.35e1e475-a4da-47e8-bdc0-d9c18ecc6f65@github.com>

On Thu, 2 Oct 2025 16:50:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Looks good for pushing

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1650#pullrequestreview-3295489990

From vromero at openjdk.org  Thu Oct  2 17:05:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 17:05:32 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v7]
In-Reply-To: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
Message-ID: <qZA8aDu3iobkanDeoAtUe4vs72ml9_PRuR-Zv7mTiyw=.318e256a-76e8-4f85-82e4-c89b9e16cae3@github.com>

> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures

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

  addressing review comments2

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1650/files
  - new: https://git.openjdk.org/valhalla/pull/1650/files/4878eea3..f1af2abc

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

  Stats: 126 lines in 44 files changed: 66 ins; 60 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1650.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1650/head:pull/1650

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

From liach at openjdk.org  Thu Oct  2 17:05:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 2 Oct 2025 17:05:32 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v7]
In-Reply-To: <qZA8aDu3iobkanDeoAtUe4vs72ml9_PRuR-Zv7mTiyw=.318e256a-76e8-4f85-82e4-c89b9e16cae3@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
 <qZA8aDu3iobkanDeoAtUe4vs72ml9_PRuR-Zv7mTiyw=.318e256a-76e8-4f85-82e4-c89b9e16cae3@github.com>
Message-ID: <aikKziylfUYHv3CzKybF-AorT8P0QE4vK38eQX-UUl0=.7496c69d-b0f0-4629-b70d-37633e35ea5d@github.com>

On Thu, 2 Oct 2025 17:02:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments2

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1650#pullrequestreview-3295552124

From vromero at openjdk.org  Thu Oct  2 17:44:49 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 17:44:49 GMT
Subject: [lworld] RFR: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue [v7]
In-Reply-To: <aikKziylfUYHv3CzKybF-AorT8P0QE4vK38eQX-UUl0=.7496c69d-b0f0-4629-b70d-37633e35ea5d@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
 <qZA8aDu3iobkanDeoAtUe4vs72ml9_PRuR-Zv7mTiyw=.318e256a-76e8-4f85-82e4-c89b9e16cae3@github.com>
 <aikKziylfUYHv3CzKybF-AorT8P0QE4vK38eQX-UUl0=.7496c69d-b0f0-4629-b70d-37633e35ea5d@github.com>
Message-ID: <KYTOPvQQnVECr5IAWuje47hkID3xJGydtdKh0Zxm5mE=.0615a610-b460-40e3-9c4a-1ec8343736b1@github.com>

On Thu, 2 Oct 2025 17:00:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments2
>
> Marked as reviewed by liach (Committer).

@liach thanks for the comments

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

PR Comment: https://git.openjdk.org/valhalla/pull/1650#issuecomment-3362320199

From vromero at openjdk.org  Thu Oct  2 17:44:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 2 Oct 2025 17:44:51 GMT
Subject: [lworld] Integrated: 8368497: [lworld] redo: New lint category
 `initialization` for code that would not be allowed in the prologue
In-Reply-To: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
References: <r60gTyZ2M4rRbkmXUJ7tghQNvVKXzHEJ48v5UcTwzMc=.c8651d6a-8c85-4887-9ba0-ec0f625f61ac@github.com>
Message-ID: <lgklk3hjEK-OMCsYQfZMMPw5ol9pA3TJQ3jpggcAkak=.fb37df1f-e6aa-4c1f-9719-51bb935675cf@github.com>

On Wed, 1 Oct 2025 15:26:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> redoing JDK-8367698 as the original fix had to be delta applied due to some test failures

This pull request has now been integrated.

Changeset: 1a33b864
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1a33b8643f726d46a04941b3e7c1cf214e3a1de9
Stats:     536 lines in 85 files changed: 425 ins; 23 del; 88 mod

8368497: [lworld] redo: New lint category `initialization` for code that would not be allowed in the prologue

Reviewed-by: liach

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

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

From dsimms at openjdk.org  Fri Oct  3 05:53:32 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 3 Oct 2025 05:53:32 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <_oG3htyVcqtkXGQT3g3gA6cmWZXTnuF7jbTBDiUGTUA=.8c6baebf-9862-4d0a-885b-f4752132b5f6@github.com>
References: <_oG3htyVcqtkXGQT3g3gA6cmWZXTnuF7jbTBDiUGTUA=.8c6baebf-9862-4d0a-885b-f4752132b5f6@github.com>
Message-ID: <ZUEHFm3Yl8vHGzHRnKapUAxjy5dG4eneSTAuzhvbFA0=.592326e4-5496-44d5-9aaf-0c5b0327b020@github.com>

> Merge tag 'jdk-26+12' into lworld_merge_jdk_26_12
> 
> Added tag jdk-26+12 for changeset 02fe095d

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits:

 - Compile issue with pre/post 26+12
 - Merge branch 'lworld' into lworld_merge_jdk_26_12
 - Merge jdk
   
   Merge tag 'jdk-26+12' into lworld_merge_jdk_26_12
   
   Added tag jdk-26+12 for changeset 02fe095d
 - 8364934: G1: Rename members of G1CollectionSet
   
   Reviewed-by: ayang, kbarrett
 - 8365115: G1: Refactor rem set statistics gather code for group
   
   Reviewed-by: kbarrett, ayang
 - 8364962: G1: Inline G1CollectionSet::finalize_incremental_building
   
   Reviewed-by: ayang, kbarrett
 - 8365026: G1: Initialization should start a "full" new collection set
   
   Reviewed-by: ayang, kbarrett
 - 8364414: G1: Use simpler data structure for holding collection set candidates during calculation
   
   Reviewed-by: ayang, iwalulya
 - 8364532: G1: In liveness tracing, print more significant digits for the liveness value
   
   Reviewed-by: ayang, iwalulya
 - 8364925: G1: Improve program flow around incremental collection set building
   
   Reviewed-by: ayang, iwalulya
 - ... and 88 more: https://git.openjdk.org/valhalla/compare/1a33b864...c86a40b5

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

Changes: https://git.openjdk.org/valhalla/pull/1649/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1649&range=01
  Stats: 11937 lines in 476 files changed: 6994 ins; 3176 del; 1767 mod
  Patch: https://git.openjdk.org/valhalla/pull/1649.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1649/head:pull/1649

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

From thartmann at openjdk.org  Fri Oct  3 06:46:13 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 3 Oct 2025 06:46:13 GMT
Subject: [lworld] RFR: 8368939: [lworld] TestInliningProtectionDomain fails
 since jdk-26+11 [v2]
In-Reply-To: <CzDkyR_h-GZxEwnR8det75Z9X2Gh7eO-vYEXTRtQzmc=.d421ed39-b596-452c-b187-4c2c4bb6553e@github.com>
References: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
 <CzDkyR_h-GZxEwnR8det75Z9X2Gh7eO-vYEXTRtQzmc=.d421ed39-b596-452c-b187-4c2c4bb6553e@github.com>
Message-ID: <pimUXMYWRZEMX7pZ5i_IoZn_dtuo8hXi6uxCOKxDUWo=.9d4bd38a-edca-4b1f-b48c-9e923978a156@github.com>

On Thu, 2 Oct 2025 14:52:46 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> `compiler/ciReplay/TestInliningProtectionDomain.java` for class `ProtectionDomainTestNoOtherCompilationPrivate` fails because it expects `bar()` not to be inlined but it gets inlined instead.
>> 
>> ## Cause
>> `TestInliningProtectionDomain` checks that ciReplay inlining does not fail with unresolved signature classes. For class `ProtectionDomainTestNoOtherCompilationPrivate` it expects `Integer` in its signature to be unresolved but it is resolved instead. The reason for this is that in valhalla boxing classes are automatically added when registering a loader ([JDK-8364034](https://bugs.openjdk.org/browse/JDK-8364034) (and later [JDK-8364483](https://bugs.openjdk.org/browse/JDK-8364483)):
>> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/classfile/systemDictionary.cpp#L215-L217
>> 
>> ## Fix
>> `TestInliningProtectionDomain` should actually use a different class than `Integer` (a class that is not in the migrated value classes set, like `java.lang.Thread`. Changed in all classes for "consistency").
>> 
>> ## Testing
>> Tier 1-3
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368939: fixed comment

Thanks for fixing this Damon! Looks good to me otherwise.

test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java line 156:

> 154:     }
> 155: 
> 156:     // String should be resovled for the protection domain of this class because getDeclaredMethods is called in normal run

Suggestion:

    // String should be resolved for the protection domain of this class because getDeclaredMethods is called in normal run

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1651#pullrequestreview-3297636865
PR Review Comment: https://git.openjdk.org/valhalla/pull/1651#discussion_r2400957478

From dfenacci at openjdk.org  Fri Oct  3 06:57:51 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 3 Oct 2025 06:57:51 GMT
Subject: [lworld] RFR: 8368939: [lworld] TestInliningProtectionDomain fails
 since jdk-26+11 [v3]
In-Reply-To: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
References: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
Message-ID: <fjKoGsMHSHgrX2S7iAx5YJ_of5zh03xKCVQT2JGwMV8=.47ce0405-b4c8-496d-9141-f4a27f0b22f8@github.com>

> ## Issue
> `compiler/ciReplay/TestInliningProtectionDomain.java` for class `ProtectionDomainTestNoOtherCompilationPrivate` fails because it expects `bar()` not to be inlined but it gets inlined instead.
> 
> ## Cause
> `TestInliningProtectionDomain` checks that ciReplay inlining does not fail with unresolved signature classes. For class `ProtectionDomainTestNoOtherCompilationPrivate` it expects `Integer` in its signature to be unresolved but it is resolved instead. The reason for this is that in valhalla boxing classes are automatically added when registering a loader ([JDK-8364034](https://bugs.openjdk.org/browse/JDK-8364034) (and later [JDK-8364483](https://bugs.openjdk.org/browse/JDK-8364483)):
> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/classfile/systemDictionary.cpp#L215-L217
> 
> ## Fix
> `TestInliningProtectionDomain` should actually use a different class than `Integer` (a class that is not in the migrated value classes set, like `java.lang.Thread`. Changed in all classes for "consistency").
> 
> ## Testing
> Tier 1-3

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1651/files
  - new: https://git.openjdk.org/valhalla/pull/1651/files/51858f4c..74b8af65

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

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

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

From dfenacci at openjdk.org  Fri Oct  3 06:57:53 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 3 Oct 2025 06:57:53 GMT
Subject: [lworld] RFR: 8368939: [lworld] TestInliningProtectionDomain fails
 since jdk-26+11 [v2]
In-Reply-To: <pimUXMYWRZEMX7pZ5i_IoZn_dtuo8hXi6uxCOKxDUWo=.9d4bd38a-edca-4b1f-b48c-9e923978a156@github.com>
References: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
 <CzDkyR_h-GZxEwnR8det75Z9X2Gh7eO-vYEXTRtQzmc=.d421ed39-b596-452c-b187-4c2c4bb6553e@github.com>
 <pimUXMYWRZEMX7pZ5i_IoZn_dtuo8hXi6uxCOKxDUWo=.9d4bd38a-edca-4b1f-b48c-9e923978a156@github.com>
Message-ID: <mDiCf889AUMi1iIoBfqjkuOqkoAmieoAIJgTHTyYMsk=.044a8f6d-092e-491c-aca1-74e538538a5f@github.com>

On Fri, 3 Oct 2025 06:43:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8368939: fixed comment
>
> Thanks for fixing this Damon! Looks good to me otherwise.

Thanks for the review @TobiHartmann!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1651#issuecomment-3364484355

From duke at openjdk.org  Fri Oct  3 06:57:54 2025
From: duke at openjdk.org (duke)
Date: Fri, 3 Oct 2025 06:57:54 GMT
Subject: [lworld] RFR: 8368939: [lworld] TestInliningProtectionDomain fails
 since jdk-26+11 [v2]
In-Reply-To: <CzDkyR_h-GZxEwnR8det75Z9X2Gh7eO-vYEXTRtQzmc=.d421ed39-b596-452c-b187-4c2c4bb6553e@github.com>
References: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
 <CzDkyR_h-GZxEwnR8det75Z9X2Gh7eO-vYEXTRtQzmc=.d421ed39-b596-452c-b187-4c2c4bb6553e@github.com>
Message-ID: <KRLbMETttPumSB_OsUs6foYwn78R3mFN7a-iGdqMC9g=.1429a4ce-24c8-41fb-9f1e-7a8175fc144d@github.com>

On Thu, 2 Oct 2025 14:52:46 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> ## Issue
>> `compiler/ciReplay/TestInliningProtectionDomain.java` for class `ProtectionDomainTestNoOtherCompilationPrivate` fails because it expects `bar()` not to be inlined but it gets inlined instead.
>> 
>> ## Cause
>> `TestInliningProtectionDomain` checks that ciReplay inlining does not fail with unresolved signature classes. For class `ProtectionDomainTestNoOtherCompilationPrivate` it expects `Integer` in its signature to be unresolved but it is resolved instead. The reason for this is that in valhalla boxing classes are automatically added when registering a loader ([JDK-8364034](https://bugs.openjdk.org/browse/JDK-8364034) (and later [JDK-8364483](https://bugs.openjdk.org/browse/JDK-8364483)):
>> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/classfile/systemDictionary.cpp#L215-L217
>> 
>> ## Fix
>> `TestInliningProtectionDomain` should actually use a different class than `Integer` (a class that is not in the migrated value classes set, like `java.lang.Thread`. Changed in all classes for "consistency").
>> 
>> ## Testing
>> Tier 1-3
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8368939: fixed comment

@dafedafe 
Your change (at version 74b8af65387ba0fd96969dbe51eb12a90c26044f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1651#issuecomment-3364492732

From dfenacci at openjdk.org  Fri Oct  3 07:10:17 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 3 Oct 2025 07:10:17 GMT
Subject: [lworld] Integrated: 8368939: [lworld] TestInliningProtectionDomain
 fails since jdk-26+11
In-Reply-To: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
References: <JyIEEGWH7ceWf1hhQSr7VTfePOmCXUhq3iTHNGQ5hQk=.d8e5cd16-1439-4401-89a8-42f7e9be11ed@github.com>
Message-ID: <SpW3oDjtb8u21SGLTcEhGDGdl3UCg9azpzuQCjcJGcc=.59d1a451-7c05-43dc-bc46-6ca9b87e091d@github.com>

On Thu, 2 Oct 2025 10:23:22 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> `compiler/ciReplay/TestInliningProtectionDomain.java` for class `ProtectionDomainTestNoOtherCompilationPrivate` fails because it expects `bar()` not to be inlined but it gets inlined instead.
> 
> ## Cause
> `TestInliningProtectionDomain` checks that ciReplay inlining does not fail with unresolved signature classes. For class `ProtectionDomainTestNoOtherCompilationPrivate` it expects `Integer` in its signature to be unresolved but it is resolved instead. The reason for this is that in valhalla boxing classes are automatically added when registering a loader ([JDK-8364034](https://bugs.openjdk.org/browse/JDK-8364034) (and later [JDK-8364483](https://bugs.openjdk.org/browse/JDK-8364483)):
> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/classfile/systemDictionary.cpp#L215-L217
> 
> ## Fix
> `TestInliningProtectionDomain` should actually use a different class than `Integer` (a class that is not in the migrated value classes set, like `java.lang.Thread`. Changed in all classes for "consistency").
> 
> ## Testing
> Tier 1-3

This pull request has now been integrated.

Changeset: d300922e
Author:    Damon Fenacci <dfenacci at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d300922e749877f6c02d84da1f0eb7039ce8be2e
Stats:     9 lines in 2 files changed: 0 ins; 1 del; 8 mod

8368939: [lworld] TestInliningProtectionDomain fails since jdk-26+11

Reviewed-by: thartmann

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

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

From dsimms at openjdk.org  Fri Oct  3 07:20:54 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 3 Oct 2025 07:20:54 GMT
Subject: [lworld] RFR: Merge jdk [v3]
In-Reply-To: <_oG3htyVcqtkXGQT3g3gA6cmWZXTnuF7jbTBDiUGTUA=.8c6baebf-9862-4d0a-885b-f4752132b5f6@github.com>
References: <_oG3htyVcqtkXGQT3g3gA6cmWZXTnuF7jbTBDiUGTUA=.8c6baebf-9862-4d0a-885b-f4752132b5f6@github.com>
Message-ID: <heEA04svXxlJMm4efGhAsVeqNWRblYtNDCNT29JlGfI=.e4b003a0-6d0e-4561-b831-da11376fdfa7@github.com>

> Merge tag 'jdk-26+12' into lworld_merge_jdk_26_12
> 
> Added tag jdk-26+12 for changeset 02fe095d

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/1649/files
  - new: https://git.openjdk.org/valhalla/pull/1649/files/c86a40b5..593078c2

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

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

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

From dsimms at openjdk.org  Fri Oct  3 07:20:55 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 3 Oct 2025 07:20:55 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <_oG3htyVcqtkXGQT3g3gA6cmWZXTnuF7jbTBDiUGTUA=.8c6baebf-9862-4d0a-885b-f4752132b5f6@github.com>
References: <_oG3htyVcqtkXGQT3g3gA6cmWZXTnuF7jbTBDiUGTUA=.8c6baebf-9862-4d0a-885b-f4752132b5f6@github.com>
Message-ID: <NW09vO8NxORDjoDhkStweHC4E287AGM6WShLtWi4acc=.062ef648-97a9-4bb1-9d04-2e0dbf61fa97@github.com>

On Wed, 1 Oct 2025 10:25:52 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+12' into lworld_merge_jdk_26_12
> 
> Added tag jdk-26+12 for changeset 02fe095d

This pull request has now been integrated.

Changeset: f615c37a
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f615c37a7040ef612d31de4435e82c923f1c4e53
Stats:     11942 lines in 477 files changed: 6999 ins; 3176 del; 1767 mod

Merge jdk

Merge jdk-26+12

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

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

From dsimms at openjdk.org  Fri Oct  3 07:45:42 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 3 Oct 2025 07:45:42 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <vAKKXXGb1Qzlem41nDi3S83rpB0pljx_E17zZoBQfuc=.2063db82-115f-4b3b-9184-90a512262cef@github.com>

Merge tag 'jdk-26+13' into lworld_merge_jdk_26_13
Added tag jdk-26+13 for changeset 1d53ac30

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

Commit messages:
 - Merge tag 'jdk-26+13' into lworld_merge_jdk_26_13
 - 8366028: MethodType::fromMethodDescriptorString should not throw UnsupportedOperationException for invalid descriptors
 - 8359348: G1: Improve cpu usage measurements for heap sizing
 - 8365772: RISC-V: correctly prereserve NaN payload when converting from float to float16 in vector way
 - 8365203: defineClass with direct buffer can cause use-after-free
 - 8365919: Replace currentTimeMillis with nanoTime in Stresser.java
 - 8359683: ZGC: NUMA-Aware Relocation
 - 8365256: RelocIterator should use indexes instead of pointers
 - 8362566: Use -Xlog:aot+map to print contents of existing AOT cache
 - 8366127: RISC-V: compiler/intrinsics/TestVerifyIntrinsicChecks.java fails when running without RVV
 - ... and 65 more: https://git.openjdk.org/valhalla/compare/f615c37a...e2a8ec9b

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

Changes: https://git.openjdk.org/valhalla/pull/1653/files
  Stats: 8018 lines in 248 files changed: 5218 ins; 1812 del; 988 mod
  Patch: https://git.openjdk.org/valhalla/pull/1653.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1653/head:pull/1653

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

From dsimms at openjdk.org  Fri Oct  3 09:16:25 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 3 Oct 2025 09:16:25 GMT
Subject: [lworld] Integrated: Adjust testing 251003
Message-ID: <wtXA0VMCQaOJqN6P9G1aDYXloE08NzsKl4GxpYvmb9E=.a35293c7-afd0-4184-9e20-ea3c308b3fdc@github.com>

Problem list needed correcting

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

Commit messages:
 - Adjust testing 251003

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

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

From dsimms at openjdk.org  Fri Oct  3 09:16:25 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 3 Oct 2025 09:16:25 GMT
Subject: [lworld] Integrated: Adjust testing 251003
In-Reply-To: <wtXA0VMCQaOJqN6P9G1aDYXloE08NzsKl4GxpYvmb9E=.a35293c7-afd0-4184-9e20-ea3c308b3fdc@github.com>
References: <wtXA0VMCQaOJqN6P9G1aDYXloE08NzsKl4GxpYvmb9E=.a35293c7-afd0-4184-9e20-ea3c308b3fdc@github.com>
Message-ID: <AJM6q8dNoQ_7eyTTsBIW3-pqxupcNJkBdDhQvS1SdD4=.268fec49-6282-408c-8f50-973f0206c6cd@github.com>

On Fri, 3 Oct 2025 09:09:28 GMT, David Simms <dsimms at openjdk.org> wrote:

> Problem list needed correcting

This pull request has now been integrated.

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

Adjust testing 251003

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

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

From dsimms at openjdk.org  Fri Oct  3 09:23:52 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 3 Oct 2025 09:23:52 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <vAKKXXGb1Qzlem41nDi3S83rpB0pljx_E17zZoBQfuc=.2063db82-115f-4b3b-9184-90a512262cef@github.com>
References: <vAKKXXGb1Qzlem41nDi3S83rpB0pljx_E17zZoBQfuc=.2063db82-115f-4b3b-9184-90a512262cef@github.com>
Message-ID: <ihAY6nGsCk4UPjGwkRVjFUYc3tCxk-NsNbd9YWaHRiw=.0a226714-df76-43b6-ab43-3233142866a6@github.com>

> Merge tag 'jdk-26+13' into lworld_merge_jdk_26_13
> Added tag jdk-26+13 for changeset 1d53ac30

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:

 - Merge branch 'lworld' into lworld_merge_jdk_26_13
 - Merge tag 'jdk-26+13' into lworld_merge_jdk_26_13
   
   Added tag jdk-26+13 for changeset 1d53ac30
 - 8366028: MethodType::fromMethodDescriptorString should not throw UnsupportedOperationException for invalid descriptors
   
   Reviewed-by: jvernee
 - 8359348: G1: Improve cpu usage measurements for heap sizing
   
   Reviewed-by: tschatzl, ayang, manc
 - 8365772: RISC-V: correctly prereserve NaN payload when converting from float to float16 in vector way
   
   Reviewed-by: fyang, rehn
 - 8365203: defineClass with direct buffer can cause use-after-free
   
   Reviewed-by: jpai
 - 8365919: Replace currentTimeMillis with nanoTime in Stresser.java
   
   Reviewed-by: tschatzl, phh
 - 8359683: ZGC: NUMA-Aware Relocation
   
   Reviewed-by: aboldtch, sjohanss
 - 8365256: RelocIterator should use indexes instead of pointers
   
   Reviewed-by: kvn, dlong
 - 8362566: Use -Xlog:aot+map to print contents of existing AOT cache
   
   Reviewed-by: vlivanov, kvn
 - ... and 66 more: https://git.openjdk.org/valhalla/compare/e0f10c2f...1abafb26

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

Changes: https://git.openjdk.org/valhalla/pull/1653/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1653&range=01
  Stats: 8018 lines in 248 files changed: 5218 ins; 1812 del; 988 mod
  Patch: https://git.openjdk.org/valhalla/pull/1653.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1653/head:pull/1653

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

From coleenp at openjdk.org  Fri Oct  3 15:00:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 15:00:36 GMT
Subject: [lworld] RFR: 8314996: [lworld]
 java/lang/Thread/virtual/stress/PingPong.java fails since jdk-22+8
Message-ID: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>

When running with JTREG_REPEAT_COUNT=1000 I get the same error as skynet in [JDK-8342977](https://bugs.openjdk.org/browse/JDK-8342977), so I'm using that number for the ProblemList-Virtual.txt. This fails intermittently without JTREG_TEST_THREAD_FACTORY=Virtual, so maybe this belongs in ProblemList.txt instead, as well as Skynet.

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

Commit messages:
 - 8314996: [lworld] java/lang/Thread/virtual/stress/PingPong.java fails since jdk-22+8

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

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

From phubner at openjdk.org  Fri Oct  3 17:40:08 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 3 Oct 2025 17:40:08 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
Message-ID: <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>

On Fri, 3 Oct 2025 14:07:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This seems to pass multiple stressHierarchy test invocations with -XX:+UseParallelGC, and runtime/valhalla/inlinetypes tests. I think there's probably further investigation that needs to be done but hopefully this helps with the parallel GC test failures.
> Testing with tier1-4.

src/hotspot/share/oops/markWord.hpp line 310:

> 308:   bool must_be_preserved() const {
> 309:     return (!is_unlocked() || !has_no_hash() ||
> 310:       (EnableValhalla && (is_larval_state() || is_inline_type() || is_flat_array() || is_null_free_array())));

Doesn't `is_inline_type` imply `is_larval_state`?  (edit: other way around)

src/hotspot/share/oops/oop.inline.hpp line 100:

> 98: // This is for parallel gc, which doesn't always have the klass.
> 99: // markWord::must_be_preserved preserves the original prototype header bits for EnableValhalla,
> 100: // I don't know why serial gc doesn't work the same.

We should probably find out why. I can ask around.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2402105631
PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2402113000

From coleenp at openjdk.org  Fri Oct  3 17:40:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 17:40:06 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow klass
 assertion failure
Message-ID: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>

This seems to pass multiple stressHierarchy test invocations with -XX:+UseParallelGC, and runtime/valhalla/inlinetypes tests. I think there's probably further investigation that needs to be done but hopefully this helps with the parallel GC test failures.
Testing with tier1-4.

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

Commit messages:
 - default_prototype_header isn't needed. MemAllocator::finish better have a Klass.
 - 8368875: [lworld] UseParallelGC fails null narrow klass assertion failure

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

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

From coleenp at openjdk.org  Fri Oct  3 17:40:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 17:40:10 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
 <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
Message-ID: <bY6Vga3ibBTlP5s2DqPbYxbrAydkvT1Yldy1sTEUrLU=.70081ab5-34ff-46ab-913b-aa5856f4c58a@github.com>

On Fri, 3 Oct 2025 14:22:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/oops/markWord.hpp line 310:
>> 
>>> 308:   bool must_be_preserved() const {
>>> 309:     return (!is_unlocked() || !has_no_hash() ||
>>> 310:       (EnableValhalla && (is_larval_state() || is_inline_type() || is_flat_array() || is_null_free_array())));
>> 
>> Doesn't `is_inline_type` imply `is_larval_state`?  (edit: other way around)
>
> The other way around, `is_larval_state` implies `is_inline_type` because only value classes instances can be in a larval state.

I don't know.  I was decoding bits in my notebook yesterday.  Would rather have them spelled out explicitly in case larval_state goes away or the bits change.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2402134809

From fparain at openjdk.org  Fri Oct  3 17:40:09 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 3 Oct 2025 17:40:09 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
Message-ID: <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>

On Fri, 3 Oct 2025 14:16:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> This seems to pass multiple stressHierarchy test invocations with -XX:+UseParallelGC, and runtime/valhalla/inlinetypes tests. I think there's probably further investigation that needs to be done but hopefully this helps with the parallel GC test failures.
>> Testing with tier1-4.
>
> src/hotspot/share/oops/markWord.hpp line 310:
> 
>> 308:   bool must_be_preserved() const {
>> 309:     return (!is_unlocked() || !has_no_hash() ||
>> 310:       (EnableValhalla && (is_larval_state() || is_inline_type() || is_flat_array() || is_null_free_array())));
> 
> Doesn't `is_inline_type` imply `is_larval_state`?  (edit: other way around)

The other way around, `is_larval_state` implies `is_inline_type` because only value classes instances can be in a larval state.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2402133078

From phubner at openjdk.org  Fri Oct  3 17:40:10 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 3 Oct 2025 17:40:10 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
 <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
Message-ID: <0KTkPqFVjvqUU5q_MSK3tGrYJnjgH-5HTQkxVVwXjnE=.f562a047-9b91-4c01-bd15-44ef31929550@github.com>

On Fri, 3 Oct 2025 14:22:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/oops/markWord.hpp line 310:
>> 
>>> 308:   bool must_be_preserved() const {
>>> 309:     return (!is_unlocked() || !has_no_hash() ||
>>> 310:       (EnableValhalla && (is_larval_state() || is_inline_type() || is_flat_array() || is_null_free_array())));
>> 
>> Doesn't `is_inline_type` imply `is_larval_state`?  (edit: other way around)
>
> The other way around, `is_larval_state` implies `is_inline_type` because only value classes instances can be in a larval state.

Thanks @fparain, I mixed it up when writing it down. I knew that, I promise ?.  

I think it would be good to introduce an `is_valhalla_concept` (naming may vary) which ORs the larval, inline type, flat array and null free array bit masks into a single mask. That way we can check it in just one call, which is imo easier to read. Thoughts?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2402155434

From coleenp at openjdk.org  Fri Oct  3 17:40:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 17:40:11 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
Message-ID: <j5FJAtQfpRFH5xeYGPrCKX_PN6FmGjXh01b3iFDgkqc=.603b5ad2-e43b-4282-abf8-0e87db93d9fe@github.com>

On Fri, 3 Oct 2025 14:18:09 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> This seems to pass multiple stressHierarchy test invocations with -XX:+UseParallelGC, and runtime/valhalla/inlinetypes tests. I think there's probably further investigation that needs to be done but hopefully this helps with the parallel GC test failures.
>> Testing with tier1-4.
>
> src/hotspot/share/oops/oop.inline.hpp line 100:
> 
>> 98: // This is for parallel gc, which doesn't always have the klass.
>> 99: // markWord::must_be_preserved preserves the original prototype header bits for EnableValhalla,
>> 100: // I don't know why serial gc doesn't work the same.
> 
> We should probably find out why. I can ask around.

Thank you! That would be good.  The prototype_mark() function above or even init_mark shouldn't have to be conditional on EnableValhalla if the markWord is always preserved.  But serial gc is very unhappy with that.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2402141866

From coleenp at openjdk.org  Fri Oct  3 18:01:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 18:01:33 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <0KTkPqFVjvqUU5q_MSK3tGrYJnjgH-5HTQkxVVwXjnE=.f562a047-9b91-4c01-bd15-44ef31929550@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
 <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
 <0KTkPqFVjvqUU5q_MSK3tGrYJnjgH-5HTQkxVVwXjnE=.f562a047-9b91-4c01-bd15-44ef31929550@github.com>
Message-ID: <sT1CTkKXyzVVSwQrslfPinJy1JtzTGg0vnNNznvpk7s=.ab22876b-9082-401a-a555-90e03c6d6328@github.com>

On Fri, 3 Oct 2025 14:27:13 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> The other way around, `is_larval_state` implies `is_inline_type` because only value classes instances can be in a larval state.
>
> Thanks @fparain, I mixed it up when writing it down. I knew that, I promise ?.  
> 
> I think it would be good to introduce an `is_valhalla_concept` (naming may vary) which ORs the larval, inline type, flat array and null free array bit masks into a single mask. That way we can check it in just one call, which is imo easier to read. Thoughts?

Maybe we can consider this as a further enhancement.  If we add valhalla bits (although I think we're out of bits), this would make sense to collect them all.  I think all of this is probably optimized to one load and compare since it's inline.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2402843119

From coleenp at openjdk.org  Fri Oct  3 18:14:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 18:14:20 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <j5FJAtQfpRFH5xeYGPrCKX_PN6FmGjXh01b3iFDgkqc=.603b5ad2-e43b-4282-abf8-0e87db93d9fe@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
 <j5FJAtQfpRFH5xeYGPrCKX_PN6FmGjXh01b3iFDgkqc=.603b5ad2-e43b-4282-abf8-0e87db93d9fe@github.com>
Message-ID: <trQVImX9pNg5rH_cb2AYNzAyLwX9gZO_YZ3k2gTbaYA=.4cd85820-840b-4fb4-ad01-ceb69cb27ce3@github.com>

On Fri, 3 Oct 2025 14:24:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/oop.inline.hpp line 100:
>> 
>>> 98: // This is for parallel gc, which doesn't always have the klass.
>>> 99: // markWord::must_be_preserved preserves the original prototype header bits for EnableValhalla,
>>> 100: // I don't know why serial gc doesn't work the same.
>> 
>> We should probably find out why. I can ask around.
>
> Thank you! That would be good.  The prototype_mark() function above or even init_mark shouldn't have to be conditional on EnableValhalla if the markWord is always preserved.  But serial gc is very unhappy with that.

To be clear I think this should be a further investigation because this should fix a lot of ParallelGC tests that are currently failing.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2402885968

From fparain at openjdk.org  Fri Oct  3 19:22:19 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 3 Oct 2025 19:22:19 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <sT1CTkKXyzVVSwQrslfPinJy1JtzTGg0vnNNznvpk7s=.ab22876b-9082-401a-a555-90e03c6d6328@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
 <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
 <0KTkPqFVjvqUU5q_MSK3tGrYJnjgH-5HTQkxVVwXjnE=.f562a047-9b91-4c01-bd15-44ef31929550@github.com>
 <sT1CTkKXyzVVSwQrslfPinJy1JtzTGg0vnNNznvpk7s=.ab22876b-9082-401a-a555-90e03c6d6328@github.com>
Message-ID: <plyzoTiJp0IGtl9Qc6N8TPNSrftnxQ_KeHjEYUPah7c=.438cddba-5572-49e2-9bd7-d22afe8d76af@github.com>

On Fri, 3 Oct 2025 17:58:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Thanks @fparain, I mixed it up when writing it down. I knew that, I promise ?.  
>> 
>> I think it would be good to introduce an `is_valhalla_concept` (naming may vary) which ORs the larval, inline type, flat array and null free array bit masks into a single mask. That way we can check it in just one call, which is imo easier to read. Thoughts?
>
> Maybe we can consider this as a further enhancement.  If we add valhalla bits (although I think we're out of bits), this would make sense to collect them all.  I think all of this is probably optimized to one load and compare since it's inline.

is_larval_state() is a status that is specific to a particular instance, and cannot be retrieved from another source, and this is why it must be preserved. is_inline_type(), is_flat_array() and is_null_free_array() are all properties than can be retrieved from the K-klass. So I'm not sure why they have been added here.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2403116424

From fparain at openjdk.org  Fri Oct  3 19:28:14 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 3 Oct 2025 19:28:14 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
Message-ID: <61JeEcN2Y2mIswl7JDlgYgIRvShasUKo8OWQ-1VLMWQ=.398abec7-394e-4315-8607-8ce14079235b@github.com>

On Fri, 3 Oct 2025 14:07:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This seems to pass multiple stressHierarchy test invocations with -XX:+UseParallelGC, and runtime/valhalla/inlinetypes tests. I think there's probably further investigation that needs to be done but hopefully this helps with the parallel GC test failures.
> Testing with tier1-4.

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1655#pullrequestreview-3300585283

From coleenp at openjdk.org  Fri Oct  3 19:28:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 19:28:15 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <plyzoTiJp0IGtl9Qc6N8TPNSrftnxQ_KeHjEYUPah7c=.438cddba-5572-49e2-9bd7-d22afe8d76af@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
 <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
 <0KTkPqFVjvqUU5q_MSK3tGrYJnjgH-5HTQkxVVwXjnE=.f562a047-9b91-4c01-bd15-44ef31929550@github.com>
 <sT1CTkKXyzVVSwQrslfPinJy1JtzTGg0vnNNznvpk7s=.ab22876b-9082-401a-a555-90e03c6d6328@github.com>
 <plyzoTiJp0IGtl9Qc6N8TPNSrftnxQ_KeHjEYUPah7c=.438cddba-5572-49e2-9bd7-d22afe8d76af@github.com>
Message-ID: <MLyUtR2iaw7VeObM3mwMigSGiDRyu1GTY2EeBrinhas=.7609657a-b514-4a2d-8c05-ed92576171a7@github.com>

On Fri, 3 Oct 2025 19:19:59 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Maybe we can consider this as a further enhancement.  If we add valhalla bits (although I think we're out of bits), this would make sense to collect them all.  I think all of this is probably optimized to one load and compare since it's inline.
>
> is_larval_state() is a status that is specific to a particular instance, and cannot be retrieved from another source, and this is why it must be preserved. is_inline_type(), is_flat_array() and is_null_free_array() are all properties than can be retrieved from the K-klass. So I'm not sure why they have been added here.

The bug was that in parallelGC it is unsafe to retrieve the K-Klass to find these properties to re-initialize the moved object.  The moved object has written over the markWord because it's not preserved.  Adding the code that we must preserve the mark word because these bits matter fixes the bug because then the moved object will have these bits.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2403122604

From fparain at openjdk.org  Fri Oct  3 19:28:16 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 3 Oct 2025 19:28:16 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <MLyUtR2iaw7VeObM3mwMigSGiDRyu1GTY2EeBrinhas=.7609657a-b514-4a2d-8c05-ed92576171a7@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
 <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
 <0KTkPqFVjvqUU5q_MSK3tGrYJnjgH-5HTQkxVVwXjnE=.f562a047-9b91-4c01-bd15-44ef31929550@github.com>
 <sT1CTkKXyzVVSwQrslfPinJy1JtzTGg0vnNNznvpk7s=.ab22876b-9082-401a-a555-90e03c6d6328@github.com>
 <plyzoTiJp0IGtl9Qc6N8TPNSrftnxQ_KeHjEYUPah7c=.438cddba-5572-49e2-9bd7-d22afe8d76af@github.com>
 <MLyUtR2iaw7VeObM3mwMigSGiDRyu1GTY2EeBrinhas=.7609657a-b514-4a2d-8c05-ed92576171a7@github.com>
Message-ID: <Xqn95vFBVvgffamR-VL9SaKxr3ZsZsd1ob9tgh00fco=.de57ad40-1286-4265-90a3-6681a78ad83a@github.com>

On Fri, 3 Oct 2025 19:23:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> is_larval_state() is a status that is specific to a particular instance, and cannot be retrieved from another source, and this is why it must be preserved. is_inline_type(), is_flat_array() and is_null_free_array() are all properties than can be retrieved from the K-klass. So I'm not sure why they have been added here.
>
> The bug was that in parallelGC it is unsafe to retrieve the K-Klass to find these properties to re-initialize the moved object.  The moved object has written over the markWord because it's not preserved.  Adding the code that we must preserve the mark word because these bits matter fixes the bug because then the moved object will have these bits.

Replying to myself: The answer seems to be in the comment in oop.inline.hpp:98, but it would be nice to know the exact reason.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2403126456

From coleenp at openjdk.org  Fri Oct  3 19:36:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 19:36:20 GMT
Subject: [lworld] Integrated: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
Message-ID: <vPSQ3qq4Id3J3pZcNjIQzy51ndyBZgj5yFf7bHeQI0U=.76be854f-2fff-4770-9ec0-8cf5afe4a664@github.com>

On Fri, 3 Oct 2025 14:07:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This seems to pass multiple stressHierarchy test invocations with -XX:+UseParallelGC, and runtime/valhalla/inlinetypes tests. I think there's probably further investigation that needs to be done but hopefully this helps with the parallel GC test failures.
> Testing with tier1-4.

This pull request has now been integrated.

Changeset: db38c83f
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/db38c83fe407c7bb5623db3b5988f28198b860bc
Stats:     41 lines in 7 files changed: 19 ins; 18 del; 4 mod

8368875: [lworld] UseParallelGC fails null narrow klass assertion failure

Reviewed-by: fparain

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

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

From coleenp at openjdk.org  Fri Oct  3 19:36:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 19:36:19 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
Message-ID: <V_BDsWyv43J-VjDZX75b057gBx4tlA9llDyaUNePzqQ=.a7b99106-2120-4cb5-87f7-da481fc6924a@github.com>

On Fri, 3 Oct 2025 14:07:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This seems to pass multiple stressHierarchy test invocations with -XX:+UseParallelGC, and runtime/valhalla/inlinetypes tests. I think there's probably further investigation that needs to be done but hopefully this helps with the parallel GC test failures.
> Testing with tier1-4.

Thanks for reviewing, Fred.  I think this will help with test results but still requires further research.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1655#issuecomment-3366962981

From coleenp at openjdk.org  Fri Oct  3 19:36:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Oct 2025 19:36:19 GMT
Subject: [lworld] RFR: 8368875: [lworld] UseParallelGC fails null narrow
 klass assertion failure
In-Reply-To: <Xqn95vFBVvgffamR-VL9SaKxr3ZsZsd1ob9tgh00fco=.de57ad40-1286-4265-90a3-6681a78ad83a@github.com>
References: <GXBlLjKnSNew7pfUjJDUTMqKNQgN32Xyvnuq9P3yQLA=.65ad1c91-6d02-4a94-85d8-58ee4e4f46f2@github.com>
 <wBhBRTbUJ5joE-lUGIbCoikHzVR0SFMRyh1vtau3O6c=.27534bcb-f9a0-4227-afbc-873d89b5c644@github.com>
 <2-UmmPAS1DXRIepCKy7maOwvr5y4z68OC2V7-WJ8cuE=.4e679d4a-13e6-4c34-9b4e-0e4bcf5f5c7b@github.com>
 <0KTkPqFVjvqUU5q_MSK3tGrYJnjgH-5HTQkxVVwXjnE=.f562a047-9b91-4c01-bd15-44ef31929550@github.com>
 <sT1CTkKXyzVVSwQrslfPinJy1JtzTGg0vnNNznvpk7s=.ab22876b-9082-401a-a555-90e03c6d6328@github.com>
 <plyzoTiJp0IGtl9Qc6N8TPNSrftnxQ_KeHjEYUPah7c=.438cddba-5572-49e2-9bd7-d22afe8d76af@github.com>
 <MLyUtR2iaw7VeObM3mwMigSGiDRyu1GTY2EeBrinhas=.7609657a-b514-4a2d-8c05-ed92576171a7@github.com>
 <Xqn95vFBVvgffamR-VL9SaKxr3ZsZsd1ob9tgh00fco=.de57ad40-1286-4265-90a3-6681a78ad83a@github.com>
Message-ID: <60YnQruPG1N4JctZja5kTOCxk7O-7cAaEUJG12BqiZw=.63803eac-89d6-4412-9f63-959744edcea3@github.com>

On Fri, 3 Oct 2025 19:24:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> The bug was that in parallelGC it is unsafe to retrieve the K-Klass to find these properties to re-initialize the moved object.  The moved object has written over the markWord because it's not preserved.  Adding the code that we must preserve the mark word because these bits matter fixes the bug because then the moved object will have these bits.
>
> Replying to myself: The answer seems to be in the comment in oop.inline.hpp:98, but it would be nice to know the exact reason.

I agree, it would be good to have a GC expert explain this @albertnetymk ?  Paul can follow up with him next week.  I think it's inherent in the parallelCompaction algorithm that the klass is lost (and then found again?) at this point.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1655#discussion_r2403141248

From vromero at openjdk.org  Sat Oct  4 01:43:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 4 Oct 2025 01:43:50 GMT
Subject: [lworld] RFR: 8369090: [lworld] Merge jdk-26+12 breaks some
 constructor and early assignment javac tests
Message-ID: <jhLLLV9TOpMMbGbezwwmYwRgHASfx1qMRbDmlln9EKA=.7af7068c-05f0-4d99-9df9-127246531274@github.com>

The issue has nothing to do with the merge, it is due to changes on the timing of lint warnings

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

Commit messages:
 - additional changes
 - 8369090: [lworld] Merge jdk-26+12 breaks some constructor and early assignment javac tests

Changes: https://git.openjdk.org/valhalla/pull/1658/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1658&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369090
  Stats: 217 lines in 15 files changed: 79 ins; 96 del; 42 mod
  Patch: https://git.openjdk.org/valhalla/pull/1658.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1658/head:pull/1658

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

From vromero at openjdk.org  Sat Oct  4 01:47:16 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 4 Oct 2025 01:47:16 GMT
Subject: [lworld] Integrated: 8369090: [lworld] Merge jdk-26+12 breaks some
 constructor and early assignment javac tests
In-Reply-To: <jhLLLV9TOpMMbGbezwwmYwRgHASfx1qMRbDmlln9EKA=.7af7068c-05f0-4d99-9df9-127246531274@github.com>
References: <jhLLLV9TOpMMbGbezwwmYwRgHASfx1qMRbDmlln9EKA=.7af7068c-05f0-4d99-9df9-127246531274@github.com>
Message-ID: <qudzpwcZoW1Sd6Of0bABEpHKC9q_BCPDG2uRIdaWOl0=.c1f796a9-e824-42e5-8c35-b43628512dd8@github.com>

On Sat, 4 Oct 2025 01:36:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The issue has nothing to do with the merge, it is due to changes on the timing of lint warnings

This pull request has now been integrated.

Changeset: dcb487ad
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/dcb487ade32f2dab67dfeb586595841cc5cee149
Stats:     217 lines in 15 files changed: 79 ins; 96 del; 42 mod

8369090: [lworld] Merge jdk-26+12 breaks some constructor and early assignment javac tests

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

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

From vromero at openjdk.org  Sat Oct  4 02:47:44 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 4 Oct 2025 02:47:44 GMT
Subject: [lworld] RFR: 8369062: [lworld] Do not allow references to instance
 fields before a this() invocation
Message-ID: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>

implementation of [1] in valhalla. This means that code like:

class Inner7 {
    private int x;

    public Inner7(byte y) {
        x = y;  // error can't refer to an instance field before a this() invocation
        this((int)y);
    }
    public Inner7(int x) {
        this.x = x;
        super();
    }
}


won't be accepted by javac
[1] https://bugs.openjdk.org/browse/JDK-8368719

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

Commit messages:
 - test chantges
 - Merge branch 'lworld' into JDK-8369062
 - 8369062: [lworld] Do not allow references to instance fields before a this() invocation

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

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

From liach at openjdk.org  Sat Oct  4 04:14:23 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 4 Oct 2025 04:14:23 GMT
Subject: [lworld] RFR: 8369062: [lworld] Do not allow references to
 instance fields before a this() invocation
In-Reply-To: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
References: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
Message-ID: <rweeWG63Ow8Gr_7SWJuuNywaNBP3y_xMVrdGVgpz3No=.fec0354b-4b90-4ed2-a769-ad5c96ad2e77@github.com>

On Sat, 4 Oct 2025 02:40:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> implementation of [1] in valhalla. This means that code like:
> 
> class Inner7 {
>     private int x;
> 
>     public Inner7(byte y) {
>         x = y;  // error can't refer to an instance field before a this() invocation
>         this((int)y);
>     }
>     public Inner7(int x) {
>         this.x = x;
>         super();
>     }
> }
> 
> 
> won't be accepted by javac
> [1] https://bugs.openjdk.org/browse/JDK-8368719

Looks good. Now we are consistently rejecting this field access before this constructor delegation.

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

> 1488:                                 if (mode != PrologueVisitorMode.WARNINGS_ONLY) {
> 1489:                                     if (mode == PrologueVisitorMode.THIS_CONSTRUCTOR) {
> 1490:                                         reportPrologueError(tree, sym);

Can merge this with the `else` in the `allowValueClasses` check above for simplicity.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1659#pullrequestreview-3301528522
PR Review Comment: https://git.openjdk.org/valhalla/pull/1659#discussion_r2403727779

From liach at openjdk.org  Sat Oct  4 05:39:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 4 Oct 2025 05:39:11 GMT
Subject: [lworld] RFR: 8369062: [lworld] Do not allow references to
 instance fields before a this() invocation
In-Reply-To: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
References: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
Message-ID: <r4YkfrOftSiUaU_1txiUw03dvcckDUJ1MqBGz4SLJD8=.92f58054-ff35-4f30-8879-09e759038f41@github.com>

On Sat, 4 Oct 2025 02:40:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> implementation of [1] in valhalla. This means that code like:
> 
> class Inner7 {
>     private int x;
> 
>     public Inner7(byte y) {
>         x = y;  // error can't refer to an instance field before a this() invocation
>         this((int)y);
>     }
>     public Inner7(int x) {
>         this.x = x;
>         super();
>     }
> }
> 
> 
> won't be accepted by javac
> [1] https://bugs.openjdk.org/browse/JDK-8368719

Comment in JDK-8368719 says we don't want error unless JEP 401 is previewed and compilation is done with preview enabled. I think what we have (failing for pre-this immediately without preview on) is probably better, but we just need to make sure Dan or whoever is aware of our decisions.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1659#issuecomment-3367924462

From vromero at openjdk.org  Sun Oct  5 12:06:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 5 Oct 2025 12:06:18 GMT
Subject: [lworld] RFR: 8369062: [lworld] Do not allow references to
 instance fields before a this() invocation
In-Reply-To: <r4YkfrOftSiUaU_1txiUw03dvcckDUJ1MqBGz4SLJD8=.92f58054-ff35-4f30-8879-09e759038f41@github.com>
References: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
 <r4YkfrOftSiUaU_1txiUw03dvcckDUJ1MqBGz4SLJD8=.92f58054-ff35-4f30-8879-09e759038f41@github.com>
Message-ID: <4Fv1hcfG-MLw6uFmGa-90Wb_ObaAGBlrIbOchp2No_w=.ed175381-29f3-40c3-b834-2e24fd62a6ad@github.com>

On Sat, 4 Oct 2025 05:36:26 GMT, Chen Liang <liach at openjdk.org> wrote:

> Comment in JDK-8368719 says we don't want error unless JEP 401 is previewed and compilation is done with preview enabled. I think what we have (failing for pre-this immediately without preview on) is probably better, but we just need to make sure Dan or whoever is aware of our decisions.

yep good catch, better to be on the safe side and enable the new feature for preview only, thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1659#issuecomment-3369010666

From vromero at openjdk.org  Sun Oct  5 13:50:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 5 Oct 2025 13:50:53 GMT
Subject: [lworld] RFR: 8369062: [lworld] Do not allow references to
 instance fields before a this() invocation [v2]
In-Reply-To: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
References: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
Message-ID: <OItmsOR4z_VQfcFGLJh7AIrbN4tsoOtLnNE-rH7afCs=.0ca7400e-d7b0-4306-b7da-eceeb71e350b@github.com>

> implementation of [1] in valhalla. This means that code like:
> 
> class Inner7 {
>     private int x;
> 
>     public Inner7(byte y) {
>         x = y;  // error can't refer to an instance field before a this() invocation
>         this((int)y);
>     }
>     public Inner7(int x) {
>         this.x = x;
>         super();
>     }
> }
> 
> 
> won't be accepted by javac
> [1] https://bugs.openjdk.org/browse/JDK-8368719

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/1659/files
  - new: https://git.openjdk.org/valhalla/pull/1659/files/bdd8be33..31671163

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

  Stats: 26 lines in 4 files changed: 10 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1659.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1659/head:pull/1659

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

From liach at openjdk.org  Sun Oct  5 20:32:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 5 Oct 2025 20:32:16 GMT
Subject: [lworld] RFR: 8369062: [lworld] Do not allow references to
 instance fields before a this() invocation [v2]
In-Reply-To: <OItmsOR4z_VQfcFGLJh7AIrbN4tsoOtLnNE-rH7afCs=.0ca7400e-d7b0-4306-b7da-eceeb71e350b@github.com>
References: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
 <OItmsOR4z_VQfcFGLJh7AIrbN4tsoOtLnNE-rH7afCs=.0ca7400e-d7b0-4306-b7da-eceeb71e350b@github.com>
Message-ID: <u6fEldARjWrOIRx5LAPUh4DhFlJpSRV5RjM-w-LjQb8=.955cf0b5-9934-4963-83c8-d9d9c534d686@github.com>

On Sun, 5 Oct 2025 13:50:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> implementation of [1] in valhalla. This means that code like:
>> 
>> class Inner7 {
>>     private int x;
>> 
>>     public Inner7(byte y) {
>>         x = y;  // error can't refer to an instance field before a this() invocation
>>         this((int)y);
>>     }
>>     public Inner7(int x) {
>>         this.x = x;
>>         super();
>>     }
>> }
>> 
>> 
>> won't be accepted by javac
>> [1] https://bugs.openjdk.org/browse/JDK-8368719
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Looks good. We can later determine what kind of warning we want to emit for existing usages.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1659#pullrequestreview-3302531031

From vromero at openjdk.org  Sun Oct  5 21:04:16 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 5 Oct 2025 21:04:16 GMT
Subject: [lworld] RFR: 8369062: [lworld] Do not allow references to
 instance fields before a this() invocation
In-Reply-To: <r4YkfrOftSiUaU_1txiUw03dvcckDUJ1MqBGz4SLJD8=.92f58054-ff35-4f30-8879-09e759038f41@github.com>
References: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
 <r4YkfrOftSiUaU_1txiUw03dvcckDUJ1MqBGz4SLJD8=.92f58054-ff35-4f30-8879-09e759038f41@github.com>
Message-ID: <WVTZgEG4U3sr90yQvzO3uYBIZp4tARJxE8UhPfIiM_g=.e11ddce2-169a-47a1-9cdb-497a80402259@github.com>

On Sat, 4 Oct 2025 05:36:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> implementation of [1] in valhalla. This means that code like:
>> 
>> class Inner7 {
>>     private int x;
>> 
>>     public Inner7(byte y) {
>>         x = y;  // error can't refer to an instance field before a this() invocation
>>         this((int)y);
>>     }
>>     public Inner7(int x) {
>>         this.x = x;
>>         super();
>>     }
>> }
>> 
>> 
>> won't be accepted by javac
>> [1] https://bugs.openjdk.org/browse/JDK-8368719
>
> Comment in JDK-8368719 says we don't want error unless JEP 401 is previewed and compilation is done with preview enabled. I think what we have (failing for pre-this immediately without preview on) is probably better, but we just need to make sure Dan or whoever is aware of our decisions.

@liach thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1659#issuecomment-3369325068

From vromero at openjdk.org  Sun Oct  5 21:04:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 5 Oct 2025 21:04:18 GMT
Subject: [lworld] RFR: 8369062: [lworld] Do not allow references to
 instance fields before a this() invocation [v2]
In-Reply-To: <rweeWG63Ow8Gr_7SWJuuNywaNBP3y_xMVrdGVgpz3No=.fec0354b-4b90-4ed2-a769-ad5c96ad2e77@github.com>
References: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
 <rweeWG63Ow8Gr_7SWJuuNywaNBP3y_xMVrdGVgpz3No=.fec0354b-4b90-4ed2-a769-ad5c96ad2e77@github.com>
Message-ID: <eYrlraCKyMX_D_uCmOqSHcMG9yCWtLi1ssYGIFH4PzY=.9b980229-0837-4e2f-ab91-c8343df11749@github.com>

On Sat, 4 Oct 2025 04:09:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1490:
> 
>> 1488:                                 if (mode != PrologueVisitorMode.WARNINGS_ONLY) {
>> 1489:                                     if (mode == PrologueVisitorMode.THIS_CONSTRUCTOR) {
>> 1490:                                         reportPrologueError(tree, sym);
> 
> Can merge this with the `else` in the `allowValueClasses` check above for simplicity.

I refactored the code

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1659#discussion_r2404664945

From vromero at openjdk.org  Sun Oct  5 21:04:19 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 5 Oct 2025 21:04:19 GMT
Subject: [lworld] Integrated: 8369062: [lworld] Do not allow references to
 instance fields before a this() invocation
In-Reply-To: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
References: <KFqdJRuEHl6kQPBR3CadjpkBhJMeF0r-xDxL8TQn8ZI=.6fc319e6-cfa0-416a-9985-fc57cc22df5b@github.com>
Message-ID: <-J8sN8u_N3ND8fMXYsr2tW5CmbZ8m872pJRBfMD9iLk=.280d5261-fd7a-44d8-b1cf-51951504af57@github.com>

On Sat, 4 Oct 2025 02:40:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> implementation of [1] in valhalla. This means that code like:
> 
> class Inner7 {
>     private int x;
> 
>     public Inner7(byte y) {
>         x = y;  // error can't refer to an instance field before a this() invocation
>         this((int)y);
>     }
>     public Inner7(int x) {
>         this.x = x;
>         super();
>     }
> }
> 
> 
> won't be accepted by javac
> [1] https://bugs.openjdk.org/browse/JDK-8368719

This pull request has now been integrated.

Changeset: 274d5607
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/274d56076260a490ed52df29373216617ddf73ef
Stats:     85 lines in 9 files changed: 50 ins; 16 del; 19 mod

8369062: [lworld] Do not allow references to instance fields before a this() invocation

Reviewed-by: liach

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

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

From thartmann at openjdk.org  Mon Oct  6 07:39:12 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 07:39:12 GMT
Subject: [lworld] RFR: 8367785: [lworld] Compiler adherence to new memory model
 rules for strict instance fields
Message-ID: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>

The new memory model rules for strict instance fields (see [JDK-8366372](https://bugs.openjdk.org/browse/JDK-8366372)) require a memory barrier at the beginning of `java.lang.Object::<init>`. The JITs will try to omit it if the receiver type is statically known (potentially via CHA + a dependency) and the class does not contain any strict fields.

Potentially, there's some more tricks that we can play. Most importantly, I think we can omit barriers for final fields at the end of the constructors if the field is also strict. I filed [JDK-8369166](https://bugs.openjdk.org/browse/JDK-8369166) for this.

I added a test that already caught [JDK-8369044](https://bugs.openjdk.org/browse/JDK-8369044) and will fail immediately without the JIT changes (on AArch64).

Thanks,
Tobias

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

Commit messages:
 - More tests
 - Merge branch 'lworld' into JDK-8367785
 - Another typo
 - Removed TODO
 - Typo
 - Fix allocation removal
 - First prototype

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

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

From liach at openjdk.org  Mon Oct  6 07:39:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 Oct 2025 07:39:14 GMT
Subject: [lworld] RFR: 8367785: [lworld] Compiler adherence to new memory
 model rules for strict instance fields
In-Reply-To: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
References: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
Message-ID: <EqWGBizq5a5YNoChcCx-hs-vo7WFR8aCJD00Ap1RPQw=.a1e9e6f9-5558-4676-95b8-cda5cbdc762e@github.com>

On Fri, 3 Oct 2025 14:12:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The new memory model rules for strict instance fields (see [JDK-8366372](https://bugs.openjdk.org/browse/JDK-8366372)) require a memory barrier at the beginning of `java.lang.Object::<init>`. The JITs will try to omit it if the receiver type is statically known (potentially via CHA + a dependency) and the class does not contain any strict fields.
> 
> Potentially, there's some more tricks that we can play. Most importantly, I think we can omit barriers for final fields at the end of the constructors if the field is also strict. I filed [JDK-8369166](https://bugs.openjdk.org/browse/JDK-8369166) for this.
> 
> I added a test that already caught [JDK-8369044](https://bugs.openjdk.org/browse/JDK-8369044) and will fail immediately without the JIT changes (on AArch64).
> 
> Thanks,
> Tobias

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

> 4302:   // Check if we need a membar at the beginning of the java.lang.Object
> 4303:   // constructor to satisfy the memory model for strict fields.
> 4304:   if (EnableValhalla && method()->intrinsic_id() == vmIntrinsics::_Object_init) {

Suggestion:

  if (EnableValhalla && callee->intrinsic_id() == vmIntrinsics::_Object_init) {

Fits better in the context of this function.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 3019:

> 3017:   // Check if we need a membar at the beginning of the java.lang.Object
> 3018:   // constructor to satisfy the memory model for strict fields.
> 3019:   if (EnableValhalla && method()->intrinsic_id() == vmIntrinsics::_Object_init) {

Should we perform checks to try skip this fence here?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1656#discussion_r2403746159
PR Review Comment: https://git.openjdk.org/valhalla/pull/1656#discussion_r2403748696

From thartmann at openjdk.org  Mon Oct  6 07:39:14 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 07:39:14 GMT
Subject: [lworld] RFR: 8367785: [lworld] Compiler adherence to new memory
 model rules for strict instance fields
In-Reply-To: <EqWGBizq5a5YNoChcCx-hs-vo7WFR8aCJD00Ap1RPQw=.a1e9e6f9-5558-4676-95b8-cda5cbdc762e@github.com>
References: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
 <EqWGBizq5a5YNoChcCx-hs-vo7WFR8aCJD00Ap1RPQw=.a1e9e6f9-5558-4676-95b8-cda5cbdc762e@github.com>
Message-ID: <7NhunXSurT--xu544HuoLeCumqZNbnfGSowqGORyHBY=.6418578e-307d-428d-b092-b3571d167cc2@github.com>

On Sat, 4 Oct 2025 04:38:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The new memory model rules for strict instance fields (see [JDK-8366372](https://bugs.openjdk.org/browse/JDK-8366372)) require a memory barrier at the beginning of `java.lang.Object::<init>`. The JITs will try to omit it if the receiver type is statically known (potentially via CHA + a dependency) and the class does not contain any strict fields.
>> 
>> Potentially, there's some more tricks that we can play. Most importantly, I think we can omit barriers for final fields at the end of the constructors if the field is also strict. I filed [JDK-8369166](https://bugs.openjdk.org/browse/JDK-8369166) for this.
>> 
>> I added a test that already caught [JDK-8369044](https://bugs.openjdk.org/browse/JDK-8369044) and will fail immediately without the JIT changes (on AArch64).
>> 
>> Thanks,
>> Tobias
>
> src/hotspot/share/c1/c1_GraphBuilder.cpp line 4304:
> 
>> 4302:   // Check if we need a membar at the beginning of the java.lang.Object
>> 4303:   // constructor to satisfy the memory model for strict fields.
>> 4304:   if (EnableValhalla && method()->intrinsic_id() == vmIntrinsics::_Object_init) {
> 
> Suggestion:
> 
>   if (EnableValhalla && callee->intrinsic_id() == vmIntrinsics::_Object_init) {
> 
> Fits better in the context of this function.

I would rather leave the code as is because we enter the callee scope just above. Also, code further below also uses `method()`.

> src/hotspot/share/c1/c1_LIRGenerator.cpp line 3019:
> 
>> 3017:   // Check if we need a membar at the beginning of the java.lang.Object
>> 3018:   // constructor to satisfy the memory model for strict fields.
>> 3019:   if (EnableValhalla && method()->intrinsic_id() == vmIntrinsics::_Object_init) {
> 
> Should we perform checks to try skip this fence here?

What checks are you suggesting? `java.lang.Object::<init>` is root of the compilation here, so we can't omit the barrier. C1 would not emit a barrier at the end of the constructor, like the interpreter does. C1 would only do that if these conditions are met:
https://github.com/openjdk/valhalla/blob/274d56076260a490ed52df29373216617ddf73ef/src/hotspot/share/c1/c1_GraphBuilder.cpp#L1645-L1652

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1656#discussion_r2405058821
PR Review Comment: https://git.openjdk.org/valhalla/pull/1656#discussion_r2405003535

From chagedorn at openjdk.org  Mon Oct  6 08:07:26 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 6 Oct 2025 08:07:26 GMT
Subject: [lworld] RFR: 8367785: [lworld] Compiler adherence to new memory
 model rules for strict instance fields
In-Reply-To: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
References: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
Message-ID: <wRf6LL6DNncvEXam53beVj73_yp2zWzDzZDUudUvoQQ=.eff33ccc-5c9a-459e-96bc-be61d801c2de@github.com>

On Fri, 3 Oct 2025 14:12:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The new memory model rules for strict instance fields (see [JDK-8366372](https://bugs.openjdk.org/browse/JDK-8366372)) require a memory barrier at the beginning of `java.lang.Object::<init>`. The JITs will try to omit it if the receiver type is statically known (potentially via CHA + a dependency) and the class does not contain any strict fields.
> 
> Potentially, there's some more tricks that we can play. Most importantly, I think we can omit barriers for final fields at the end of the constructors if the field is also strict. I filed [JDK-8369166](https://bugs.openjdk.org/browse/JDK-8369166) for this.
> 
> I added a test that already caught [JDK-8369044](https://bugs.openjdk.org/browse/JDK-8369044) and will fail immediately without the JIT changes (on AArch64).
> 
> Thanks,
> Tobias

Looks good to me and nice test!

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestStrictFieldBarriers.java line 204:

> 202:                 if (res != 1) {
> 203:                     System.err.println("Incorrect field value observed!");
> 204:                     System.exit(1);

Is there any particular reason why you don't throw a `RuntimeException` here instead?

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1656#pullrequestreview-3303271947
PR Review Comment: https://git.openjdk.org/valhalla/pull/1656#discussion_r2405254858

From thartmann at openjdk.org  Mon Oct  6 08:14:29 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 08:14:29 GMT
Subject: [lworld] RFR: 8367785: [lworld] Compiler adherence to new memory
 model rules for strict instance fields
In-Reply-To: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
References: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
Message-ID: <wbVXBsxJOxKGuPexQjDjGTe0OJzVewsFT4phfKdZ2iQ=.84c57d6c-8a17-47d2-8f96-b38d13721137@github.com>

On Fri, 3 Oct 2025 14:12:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The new memory model rules for strict instance fields (see [JDK-8366372](https://bugs.openjdk.org/browse/JDK-8366372)) require a memory barrier at the beginning of `java.lang.Object::<init>`. The JITs will try to omit it if the receiver type is statically known (potentially via CHA + a dependency) and the class does not contain any strict fields.
> 
> Potentially, there's some more tricks that we can play. Most importantly, I think we can omit barriers for final fields at the end of the constructors if the field is also strict. I filed [JDK-8369166](https://bugs.openjdk.org/browse/JDK-8369166) for this.
> 
> I added a test that already caught [JDK-8369044](https://bugs.openjdk.org/browse/JDK-8369044) and will fail immediately without the JIT changes (on AArch64).
> 
> Thanks,
> Tobias

Thanks for the review Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1656#issuecomment-3370416529

From thartmann at openjdk.org  Mon Oct  6 08:14:31 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 08:14:31 GMT
Subject: [lworld] RFR: 8367785: [lworld] Compiler adherence to new memory
 model rules for strict instance fields
In-Reply-To: <wRf6LL6DNncvEXam53beVj73_yp2zWzDzZDUudUvoQQ=.eff33ccc-5c9a-459e-96bc-be61d801c2de@github.com>
References: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
 <wRf6LL6DNncvEXam53beVj73_yp2zWzDzZDUudUvoQQ=.eff33ccc-5c9a-459e-96bc-be61d801c2de@github.com>
Message-ID: <9s0pSBouo7fyw_hzSwftZ_B9vaRShFgzE4dBDBbVYbo=.9fe86699-9714-4875-86d8-2c9883ed3649@github.com>

On Mon, 6 Oct 2025 08:01:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The new memory model rules for strict instance fields (see [JDK-8366372](https://bugs.openjdk.org/browse/JDK-8366372)) require a memory barrier at the beginning of `java.lang.Object::<init>`. The JITs will try to omit it if the receiver type is statically known (potentially via CHA + a dependency) and the class does not contain any strict fields.
>> 
>> Potentially, there's some more tricks that we can play. Most importantly, I think we can omit barriers for final fields at the end of the constructors if the field is also strict. I filed [JDK-8369166](https://bugs.openjdk.org/browse/JDK-8369166) for this.
>> 
>> I added a test that already caught [JDK-8369044](https://bugs.openjdk.org/browse/JDK-8369044) and will fail immediately without the JIT changes (on AArch64).
>> 
>> Thanks,
>> Tobias
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestStrictFieldBarriers.java line 204:
> 
>> 202:                 if (res != 1) {
>> 203:                     System.err.println("Incorrect field value observed!");
>> 204:                     System.exit(1);
> 
> Is there any particular reason why you don't throw a `RuntimeException` here instead?

Yes, it's the best way (I think) to make sure all threads immediately exit if one thread observes an error. Throwing an exception will not stop the other threads.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1656#discussion_r2405280126

From chagedorn at openjdk.org  Mon Oct  6 08:22:21 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 6 Oct 2025 08:22:21 GMT
Subject: [lworld] RFR: 8367785: [lworld] Compiler adherence to new memory
 model rules for strict instance fields
In-Reply-To: <9s0pSBouo7fyw_hzSwftZ_B9vaRShFgzE4dBDBbVYbo=.9fe86699-9714-4875-86d8-2c9883ed3649@github.com>
References: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
 <wRf6LL6DNncvEXam53beVj73_yp2zWzDzZDUudUvoQQ=.eff33ccc-5c9a-459e-96bc-be61d801c2de@github.com>
 <9s0pSBouo7fyw_hzSwftZ_B9vaRShFgzE4dBDBbVYbo=.9fe86699-9714-4875-86d8-2c9883ed3649@github.com>
Message-ID: <5K786PFcr9lDgcQtCerLhZ-9DZcJnLVD0yEBL0bVsww=.b7f880cc-e057-4162-9f61-353e2ccd9d2f@github.com>

On Mon, 6 Oct 2025 08:11:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestStrictFieldBarriers.java line 204:
>> 
>>> 202:                 if (res != 1) {
>>> 203:                     System.err.println("Incorrect field value observed!");
>>> 204:                     System.exit(1);
>> 
>> Is there any particular reason why you don't throw a `RuntimeException` here instead?
>
> Yes, it's the best way (I think) to make sure all threads immediately exit if one thread observes an error. Throwing an exception will not stop the other threads.

Got it, thanks for the explanation!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1656#discussion_r2405299704

From phubner at openjdk.org  Mon Oct  6 08:23:26 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 6 Oct 2025 08:23:26 GMT
Subject: [lworld] RFR: Problemlist JDK-8369043
Message-ID: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>

The test is failing intermittently on AArch64 and creating a lot of noise.

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

Commit messages:
 - Problemlist HelloAOTCache.

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

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

From chagedorn at openjdk.org  Mon Oct  6 08:23:16 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 6 Oct 2025 08:23:16 GMT
Subject: [lworld] RFR: 8348972: [lworld] C1/C2: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
In-Reply-To: <i0KvRV-JavSIiNIk4YiI5iL6EUnYJHRyWccKxom0JiM=.9fa9dabf-e135-4b9d-9874-b4a88aa63ef3@github.com>
References: <i0KvRV-JavSIiNIk4YiI5iL6EUnYJHRyWccKxom0JiM=.9fa9dabf-e135-4b9d-9874-b4a88aa63ef3@github.com>
Message-ID: <8AmcTqh79Yx6Fla4_Rc5lpQ6uEJ4RLOFh98KybAkyQg=.4325f557-3254-421b-b776-c292444e25e0@github.com>

On Thu, 25 Sep 2025 10:47:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes various issues in C1 and C2 (11 bugs in total) when running with `-XX:+UseCompactObjectHeaders`.
> 
> Most of the bugs could either be traced back to:
> - Unconditionally assuming old layout with klass pointer following immediately the mark word.
> - Small mistakes when merging JEP 450.
> - Using the wrong basic type `T_OBJECT` for flat arrays instead of `T_FLAT_ELEMENT`. In Valhalla, we require that the elements of an array are aligned:https://github.com/openjdk/valhalla/blob/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a/src/hotspot/share/oops/arrayOop.hpp#L94-L97
> https://github.com/openjdk/valhalla/blob/04efe5c66b70b9dca1a5c538c9a04e7ad93c107a/src/hotspot/share/oops/arrayOop.hpp#L57-L61
> When we now wrongly use `T_OBJECT`, it is not a problem with default flags (using compressed klass pointers and no COH): An array has a 12 byte header + 4 byte length which is 16 bytes in total - no alignment required. But with COH, we now have a header of 8 bytes + 4 byte length. We now require alignment but when we pass in `T_OBJECT`, we miss the alignment which leads to crashes down the line. I went through all the uses of `base_offset_in_bytes()` and fixed more such issues.
> 
> To review: I made separate commits for each fixed bug, each message summarizing the found issue. To better understand individual changes of the patch, it might help to look at the commits separately.
> 
> **Testing:**
> - Apart from one bug, I could trigger them with existing tests. So, I have not added new tests for these issues separately.
> - One bug only manifested with a new test (`test127a`) which I added with this patch.
> - tier1-5 + compiler stress:
>   - No additional flags, i.e. (mostly) without COH: Looks good and only known failures
>   - With explicitly setting COH:
>     - A lot of CDS related failures on which @matias9927 is working ([JDK-8367959](https://bugs.openjdk.org/browse/JDK-8367959))
>     - Test timeout with `TestIntrinsics`: Unrelated to COH but only triggering with COH ([JDK-8368274](https://bugs.openjdk.org/browse/JDK-8368274)).
>     - Otherwise, looks good with only known failures.
> 
> Thanks,
> Christian

Thanks Tobias!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1632#issuecomment-3370444207

From thartmann at openjdk.org  Mon Oct  6 08:28:17 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 08:28:17 GMT
Subject: [lworld] RFR: Problemlist JDK-8369043
In-Reply-To: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>
References: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>
Message-ID: <8nGt2xsX4wgwgPoLRT-C2zk_r4nZ3JV6sj3SbqFBiq0=.a4dfb3a7-dead-4cbe-ae4f-0b03e63f7cd8@github.com>

On Mon, 6 Oct 2025 08:16:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is failing intermittently on AArch64 and creating a lot of noise.

Good and trivial.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1660#pullrequestreview-3303349995

From christian.hagedorn at oracle.com  Mon Oct  6 08:28:14 2025
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Mon, 6 Oct 2025 10:28:14 +0200
Subject: CFV: New Valhalla Committer: Marc Chevalier
In-Reply-To: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
References: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
Message-ID: <91f59422-a83f-4e46-b896-f21db317487f@oracle.com>

Vote: yes

Best regards,
Christian

On 9/30/25 10:00, Tobias Hartmann wrote:
> I hereby nominate Marc Chevalier [1] to Valhalla Committer.
> 
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 37 
> changes to the JDK project [2] and 12 changes to the Valhalla project [3].
> 
> Votes are due by October 14, 2025, 08:00 UTC.
> 
> Only current Valhalla Committers [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> Best regards,
> Tobias
> 
> [1] https://openjdk.org/census#mchevalier
> [2] https://github.com/search?q=author%3Amarc- 
> chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1
> [3] https://bugs.openjdk.org/issues/? 
> jql=assignee%20%3D%20mchevalier%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote


From christian.hagedorn at oracle.com  Mon Oct  6 08:29:52 2025
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Mon, 6 Oct 2025 10:29:52 +0200
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
Message-ID: <40954680-cb83-481f-b438-65a423719314@oracle.com>

Vote: yes

Best regards,
Christian

On 9/30/25 10:04, Tobias Hartmann wrote:
> I hereby nominate Damon Fenacci [1] to Valhalla Committer.
> 
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 36 
> changes to the JDK project [2] and 7 changes to the Valhalla project [3].
> 
> Votes are due by October 14, 2025, 08:00 UTC.
> 
> Only current Valhalla Committers [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> Best regards,
> Tobias
> 
> [1] https://openjdk.org/census#dfenacci
> [2] https://github.com/search?q=author- 
> name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits
> [3] https://bugs.openjdk.org/issues/? 
> jql=assignee%20%3D%20dfenacci%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote


From phubner at openjdk.org  Mon Oct  6 08:35:16 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 6 Oct 2025 08:35:16 GMT
Subject: [lworld] RFR: Problemlist JDK-8369043
In-Reply-To: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>
References: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>
Message-ID: <rHUjA5dvkrnweOxF7to-YPRPslBSHQJA_ZlI77usHHs=.607cedeb-2b00-4271-9c0f-da48283ec6f6@github.com>

On Mon, 6 Oct 2025 08:16:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is failing intermittently on AArch64 and creating a lot of noise.

Thanks for the review Tobias!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1660#issuecomment-3370481808

From duke at openjdk.org  Mon Oct  6 08:35:17 2025
From: duke at openjdk.org (duke)
Date: Mon, 6 Oct 2025 08:35:17 GMT
Subject: [lworld] RFR: Problemlist JDK-8369043
In-Reply-To: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>
References: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>
Message-ID: <XA6S7_pqcIV1Kt27AYBZhgJ5hKJId4OegMpWyuUoiKg=.39bc4538-3c83-431d-83fd-519523429163@github.com>

On Mon, 6 Oct 2025 08:16:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is failing intermittently on AArch64 and creating a lot of noise.

@Arraying 
Your change (at version fdbab7fb584141f76059b561f3b2a138a6b4342b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1660#issuecomment-3370486657

From phubner at openjdk.org  Mon Oct  6 08:39:25 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 6 Oct 2025 08:39:25 GMT
Subject: [lworld] Integrated: Problemlist JDK-8369043
In-Reply-To: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>
References: <FrOh_hfAfZkYK8TY3rrggE1_QvDXKzF6WliVwJuEDKo=.2218b0d8-8521-4867-b39c-2361b28fdc07@github.com>
Message-ID: <UY7vgZxYzTwA-dqTXw0nUYTrcfvcrMImN22wBdD-3mY=.9b42cfe1-42f7-4307-aa83-0aac30a05a41@github.com>

On Mon, 6 Oct 2025 08:16:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is failing intermittently on AArch64 and creating a lot of noise.

This pull request has now been integrated.

Changeset: e875fecf
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e875fecf0d09c8a1114d4c1cae6bba5b0dc80c53
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

Problemlist JDK-8369043

Reviewed-by: thartmann

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

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

From thartmann at openjdk.org  Mon Oct  6 08:43:22 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 08:43:22 GMT
Subject: [lworld] Integrated: 8367785: [lworld] Compiler adherence to new
 memory model rules for strict instance fields
In-Reply-To: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
References: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
Message-ID: <q0xSiyy5Ouj95TzuQA_cTn06-p4dhLVZlHv3SLR37EU=.ac9c8c1d-b2d8-45db-a548-f08f11409c32@github.com>

On Fri, 3 Oct 2025 14:12:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The new memory model rules for strict instance fields (see [JDK-8366372](https://bugs.openjdk.org/browse/JDK-8366372)) require a memory barrier at the beginning of `java.lang.Object::<init>`. The JITs will try to omit it if the receiver type is statically known (potentially via CHA + a dependency) and the class does not contain any strict fields.
> 
> Potentially, there's some more tricks that we can play. Most importantly, I think we can omit barriers for final fields at the end of the constructors if the field is also strict. I filed [JDK-8369166](https://bugs.openjdk.org/browse/JDK-8369166) for this.
> 
> I added a test that already caught [JDK-8369044](https://bugs.openjdk.org/browse/JDK-8369044) and will fail immediately without the JIT changes (on AArch64).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8367785: [lworld] Compiler adherence to new memory model rules for strict instance fields

Reviewed-by: chagedorn

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

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

From thartmann at openjdk.org  Mon Oct  6 08:58:36 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 08:58:36 GMT
Subject: [lworld] RFR: 8368802: [lworld] C1 compilation fails with SIGSEGV in
 ciObjArrayKlass::make_impl
Message-ID: <eczHvcjscdEcMNLe6wxZfio9E1dgoydm5DFjoDr4rkU=.7df34d14-3f87-4625-b18c-d42f98665918@github.com>

If we are OOM, `element_klass->get_Klass()->array_klass(THREAD)` will return `nullptr`. We need to check `HAS_PENDING_EXCEPTION` before using the return value.

Thanks,
Tobias

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

Commit messages:
 - 8368802: [lworld] C1 compilation fails with SIGSEGV in ciObjArrayKlass::make_impl

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

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

From dsimms at openjdk.org  Mon Oct  6 09:06:24 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 6 Oct 2025 09:06:24 GMT
Subject: [lworld] RFR: Merge jdk [v3]
In-Reply-To: <vAKKXXGb1Qzlem41nDi3S83rpB0pljx_E17zZoBQfuc=.2063db82-115f-4b3b-9184-90a512262cef@github.com>
References: <vAKKXXGb1Qzlem41nDi3S83rpB0pljx_E17zZoBQfuc=.2063db82-115f-4b3b-9184-90a512262cef@github.com>
Message-ID: <udlWDf2qAPxuTjRvAFTe9ftVaH3Iiqypt8UcizYMDLA=.8ed76314-5a40-48d9-b5ef-9277b111090c@github.com>

> Merge tag 'jdk-26+13' into lworld_merge_jdk_26_13
> Added tag jdk-26+13 for changeset 1d53ac30

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:

 - Merge branch 'lworld' into lworld_merge_jdk_26_13
 - Merge branch 'lworld' into lworld_merge_jdk_26_13
 - Merge tag 'jdk-26+13' into lworld_merge_jdk_26_13
   
   Added tag jdk-26+13 for changeset 1d53ac30
 - 8366028: MethodType::fromMethodDescriptorString should not throw UnsupportedOperationException for invalid descriptors
   
   Reviewed-by: jvernee
 - 8359348: G1: Improve cpu usage measurements for heap sizing
   
   Reviewed-by: tschatzl, ayang, manc
 - 8365772: RISC-V: correctly prereserve NaN payload when converting from float to float16 in vector way
   
   Reviewed-by: fyang, rehn
 - 8365203: defineClass with direct buffer can cause use-after-free
   
   Reviewed-by: jpai
 - 8365919: Replace currentTimeMillis with nanoTime in Stresser.java
   
   Reviewed-by: tschatzl, phh
 - 8359683: ZGC: NUMA-Aware Relocation
   
   Reviewed-by: aboldtch, sjohanss
 - 8365256: RelocIterator should use indexes instead of pointers
   
   Reviewed-by: kvn, dlong
 - ... and 67 more: https://git.openjdk.org/valhalla/compare/f8ced6c2...8f92505c

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

Changes: https://git.openjdk.org/valhalla/pull/1653/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1653&range=02
  Stats: 8018 lines in 248 files changed: 5218 ins; 1812 del; 988 mod
  Patch: https://git.openjdk.org/valhalla/pull/1653.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1653/head:pull/1653

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

From dsimms at openjdk.org  Mon Oct  6 11:02:37 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 6 Oct 2025 11:02:37 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <vAKKXXGb1Qzlem41nDi3S83rpB0pljx_E17zZoBQfuc=.2063db82-115f-4b3b-9184-90a512262cef@github.com>
References: <vAKKXXGb1Qzlem41nDi3S83rpB0pljx_E17zZoBQfuc=.2063db82-115f-4b3b-9184-90a512262cef@github.com>
Message-ID: <YhiPiQQ13t5AFkiMC77Qbgq9seZmjZF2tlAAXPsZk9I=.e8b801df-5b28-4ecb-9cee-6f150b02656a@github.com>

On Fri, 3 Oct 2025 07:37:17 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+13' into lworld_merge_jdk_26_13
> Added tag jdk-26+13 for changeset 1d53ac30

This pull request has now been integrated.

Changeset: b5a6caff
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b5a6caffc5ee5556330ec667a150c708dd4ec2b7
Stats:     8018 lines in 248 files changed: 5218 ins; 1812 del; 988 mod

Merge jdk

Merge jdk-26+13

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

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

From thartmann at openjdk.org  Mon Oct  6 11:25:21 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 11:25:21 GMT
Subject: [lworld] Integrated: 8368802: [lworld] C1 compilation fails with
 SIGSEGV in ciObjArrayKlass::make_impl
In-Reply-To: <eczHvcjscdEcMNLe6wxZfio9E1dgoydm5DFjoDr4rkU=.7df34d14-3f87-4625-b18c-d42f98665918@github.com>
References: <eczHvcjscdEcMNLe6wxZfio9E1dgoydm5DFjoDr4rkU=.7df34d14-3f87-4625-b18c-d42f98665918@github.com>
Message-ID: <frCvWzWldL5aT6VDNMF0lVpZEOp3qXH08hO53aYcIZw=.f7702345-73a9-44cf-b44c-2be76e26d47a@github.com>

On Mon, 6 Oct 2025 08:51:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> If we are OOM, `element_klass->get_Klass()->array_klass(THREAD)` will return `nullptr`. We need to check `HAS_PENDING_EXCEPTION` before using the return value.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 0f7e09c5
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0f7e09c54097d983324d12e82631279436713f24
Stats:     8 lines in 1 file changed: 4 ins; 4 del; 0 mod

8368802: [lworld] C1 compilation fails with SIGSEGV in ciObjArrayKlass::make_impl

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

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

From chagedorn at openjdk.org  Mon Oct  6 12:18:47 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 6 Oct 2025 12:18:47 GMT
Subject: [lworld] RFR: 8368782: [lworld] C2: fatal error: no reachable node
 should have no use
Message-ID: <Qms-lqrXEMyBAsXv7q8BxuDufx1IzSPCT0kl_n60Nqw=.7f49d2b0-c436-4ee4-a2d4-c8245ade022c@github.com>

`test9()` in `TestLWorld.java` is crashing intermittently when running with `StressLoopPeeling`.

The problem can be traced back to a node that is not re-added to the IGVN worklist in `PhiNode::Ideal()`:
<img width="282" height="198" alt="graph" src="https://github.com/user-attachments/assets/e8597cf1-d49f-4c8d-b248-184b25f30fba" />

We are processing `3786 Phi` and update its input `3748 Phi` to another node. As a result, `3748 Phi` loses it's last output and is now dead. It should be re-added to the IGVN worklist to be cleaned up. But that does not happen because we use `set_req()` on `3786 Phi` instead of `set_req_X()` when replacing the input `3748 Phi`. As a result, the dead node stays in the graph and eventually triggers the "no dead use" assert.

The fix is straight forward to use `set_req_X()` which ensures that a now dead input node is pushed to the IGVN worklist again and cleaned up later.

The affected code is also wrong in mainline but has never triggered there. Therefore, I suggest to wait and not eagerly upstream it to mainline for now.

Thanks,
Christian

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

Commit messages:
 - 8368782: [lworld] C2: fatal error: no reachable node should have no use

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

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

From thartmann at openjdk.org  Mon Oct  6 12:36:36 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Oct 2025 12:36:36 GMT
Subject: [lworld] RFR: 8368782: [lworld] C2: fatal error: no reachable node
 should have no use
In-Reply-To: <Qms-lqrXEMyBAsXv7q8BxuDufx1IzSPCT0kl_n60Nqw=.7f49d2b0-c436-4ee4-a2d4-c8245ade022c@github.com>
References: <Qms-lqrXEMyBAsXv7q8BxuDufx1IzSPCT0kl_n60Nqw=.7f49d2b0-c436-4ee4-a2d4-c8245ade022c@github.com>
Message-ID: <FPMZ4cZTDomJ4ocDDPAIQlbqL_6ZnTOZ2fH7qDdrEbg=.a578865a-be28-4c21-9d88-b12020cc3c33@github.com>

On Mon, 6 Oct 2025 12:13:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `test9()` in `TestLWorld.java` is crashing intermittently when running with `StressLoopPeeling`.
> 
> The problem can be traced back to a node that is not re-added to the IGVN worklist in `PhiNode::Ideal()`:
> <img width="282" height="198" alt="graph" src="https://github.com/user-attachments/assets/e8597cf1-d49f-4c8d-b248-184b25f30fba" />
> 
> We are processing `3786 Phi` and update its input `3748 Phi` to another node. As a result, `3748 Phi` loses it's last output and is now dead. It should be re-added to the IGVN worklist to be cleaned up. But that does not happen because we use `set_req()` on `3786 Phi` instead of `set_req_X()` when replacing the input `3748 Phi`. As a result, the dead node stays in the graph and eventually triggers the "no dead use" assert.
> 
> The fix is straight forward to use `set_req_X()` which ensures that a now dead input node is pushed to the IGVN worklist again and cleaned up later.
> 
> The affected code is also wrong in mainline but has never triggered there. Therefore, I suggest to wait and not eagerly upstream it to mainline for now.
> 
> Thanks,
> Christian

Looks good and trivial!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1662#pullrequestreview-3304303935

From chagedorn at openjdk.org  Mon Oct  6 13:19:28 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 6 Oct 2025 13:19:28 GMT
Subject: [lworld] RFR: 8368782: [lworld] C2: fatal error: no reachable node
 should have no use
In-Reply-To: <Qms-lqrXEMyBAsXv7q8BxuDufx1IzSPCT0kl_n60Nqw=.7f49d2b0-c436-4ee4-a2d4-c8245ade022c@github.com>
References: <Qms-lqrXEMyBAsXv7q8BxuDufx1IzSPCT0kl_n60Nqw=.7f49d2b0-c436-4ee4-a2d4-c8245ade022c@github.com>
Message-ID: <FvLsCU_A4g1vj1lVVa9UEkn9RHkUnejdqme7SONflgE=.ebdf3fbb-6384-4d3d-ab1e-1a3ba1ee85ec@github.com>

On Mon, 6 Oct 2025 12:13:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `test9()` in `TestLWorld.java` is crashing intermittently when running with `StressLoopPeeling`.
> 
> The problem can be traced back to a node that is not re-added to the IGVN worklist in `PhiNode::Ideal()`:
> <img width="282" height="198" alt="graph" src="https://github.com/user-attachments/assets/e8597cf1-d49f-4c8d-b248-184b25f30fba" />
> 
> We are processing `3786 Phi` and update its input `3748 Phi` to another node. As a result, `3748 Phi` loses it's last output and is now dead. It should be re-added to the IGVN worklist to be cleaned up. But that does not happen because we use `set_req()` on `3786 Phi` instead of `set_req_X()` when replacing the input `3748 Phi`. As a result, the dead node stays in the graph and eventually triggers the "no dead use" assert.
> 
> The fix is straight forward to use `set_req_X()` which ensures that a now dead input node is pushed to the IGVN worklist again and cleaned up later.
> 
> The affected code is also wrong in mainline but has never triggered there. Therefore, I suggest to wait and not eagerly upstream it to mainline for now.
> 
> Thanks,
> Christian

Thanks Tobias for your quick review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1662#issuecomment-3371595947

From liach at openjdk.org  Mon Oct  6 15:08:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 Oct 2025 15:08:27 GMT
Subject: [lworld] RFR: 8367785: [lworld] Compiler adherence to new memory
 model rules for strict instance fields
In-Reply-To: <7NhunXSurT--xu544HuoLeCumqZNbnfGSowqGORyHBY=.6418578e-307d-428d-b092-b3571d167cc2@github.com>
References: <wtO8bNDtLAP5sdGv7OQDGv2jjFPzEqHzYFfRbKyQ8OE=.67916a55-b3a8-41bb-a1fd-9876098ae581@github.com>
 <EqWGBizq5a5YNoChcCx-hs-vo7WFR8aCJD00Ap1RPQw=.a1e9e6f9-5558-4676-95b8-cda5cbdc762e@github.com>
 <7NhunXSurT--xu544HuoLeCumqZNbnfGSowqGORyHBY=.6418578e-307d-428d-b092-b3571d167cc2@github.com>
Message-ID: <S49XE3hM-f_1lBFtKEwzdZOuxFanPO2mmQVPeGXTESg=.834f427d-8056-4036-8004-cfaf9276fbcf@github.com>

On Mon, 6 Oct 2025 06:01:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/c1/c1_LIRGenerator.cpp line 3019:
>> 
>>> 3017:   // Check if we need a membar at the beginning of the java.lang.Object
>>> 3018:   // constructor to satisfy the memory model for strict fields.
>>> 3019:   if (EnableValhalla && method()->intrinsic_id() == vmIntrinsics::_Object_init) {
>> 
>> Should we perform checks to try skip this fence here?
>
> What checks are you suggesting? `java.lang.Object::<init>` is root of the compilation here, so we can't omit the barrier. C1 would not emit a barrier at the end of the constructor, like the interpreter does. C1 would only do that if these conditions are met:
> https://github.com/openjdk/valhalla/blob/274d56076260a490ed52df29373216617ddf73ef/src/hotspot/share/c1/c1_GraphBuilder.cpp#L1645-L1652

Thanks, didn't realize this is for the compilation root.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1656#discussion_r2406878367

From matsaave at openjdk.org  Mon Oct  6 15:33:04 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 6 Oct 2025 15:33:04 GMT
Subject: [lworld] RFR: 8369066: [lworld] UncaughtNativeExceptionTest.java fails
 with UnsupportedClassVersionError
Message-ID: <P7Dd9Z3xs6b9t-D_BU_3akpoB0LEy2N5ly3zyL8HzpU=.24563162-519f-44da-9305-7ee8db15b5ab@github.com>

The `--enable-preview` was not propagated correctly to the sub-process used in this test so this option was added explicitly.

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

Commit messages:
 - 8369066: [lworld] UncaughtNativeExceptionTest.java fails with UnsupportedClassVersionError

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

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

From chagedorn at openjdk.org  Tue Oct  7 07:27:15 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 7 Oct 2025 07:27:15 GMT
Subject: [lworld] Integrated: 8368782: [lworld] C2: fatal error: no reachable
 node should have no use
In-Reply-To: <Qms-lqrXEMyBAsXv7q8BxuDufx1IzSPCT0kl_n60Nqw=.7f49d2b0-c436-4ee4-a2d4-c8245ade022c@github.com>
References: <Qms-lqrXEMyBAsXv7q8BxuDufx1IzSPCT0kl_n60Nqw=.7f49d2b0-c436-4ee4-a2d4-c8245ade022c@github.com>
Message-ID: <ATXqFYpb7gX0tDb_GLWAFx6ckyTdz1MjkMJzrH5GJ8s=.2b8d2c64-f56f-4b7f-b59d-0e7164c47625@github.com>

On Mon, 6 Oct 2025 12:13:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `test9()` in `TestLWorld.java` is crashing intermittently when running with `StressLoopPeeling`.
> 
> The problem can be traced back to a node that is not re-added to the IGVN worklist in `PhiNode::Ideal()`:
> <img width="282" height="198" alt="graph" src="https://github.com/user-attachments/assets/e8597cf1-d49f-4c8d-b248-184b25f30fba" />
> 
> We are processing `3786 Phi` and update its input `3748 Phi` to another node. As a result, `3748 Phi` loses it's last output and is now dead. It should be re-added to the IGVN worklist to be cleaned up. But that does not happen because we use `set_req()` on `3786 Phi` instead of `set_req_X()` when replacing the input `3748 Phi`. As a result, the dead node stays in the graph and eventually triggers the "no dead use" assert.
> 
> The fix is straight forward to use `set_req_X()` which ensures that a now dead input node is pushed to the IGVN worklist again and cleaned up later.
> 
> The affected code is also wrong in mainline but has never triggered there. Therefore, I suggest to wait and not eagerly upstream it to mainline for now.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 619825cd
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/619825cd7640af99253455dda68e8b9d9018d478
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8368782: [lworld] C2: fatal error: no reachable node should have no use

Reviewed-by: thartmann

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

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

From dsimms at openjdk.org  Tue Oct  7 08:36:00 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 7 Oct 2025 08:36:00 GMT
Subject: [lworld] RFR: 8369260: [lworld] InnerClassLambdaMetafactory.java
 should use PREVIEW_MINOR_VERSION
Message-ID: <0JydSewKO9NEDpCxjd1xtvCy4tXhsuMTv-LYrTw306I=.9ec6682f-a5e8-46a5-9fcf-9018b21d6dd0@github.com>

Use the correct constant

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

Commit messages:
 - 8369260: [lworld] InnerClassLambdaMetafactory.java should use PREVIEW_MINOR_VERSION

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

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

From dsimms at openjdk.org  Tue Oct  7 11:13:17 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 7 Oct 2025 11:13:17 GMT
Subject: [lworld] Integrated: 8369260: [lworld]
 InnerClassLambdaMetafactory.java should use PREVIEW_MINOR_VERSION
In-Reply-To: <0JydSewKO9NEDpCxjd1xtvCy4tXhsuMTv-LYrTw306I=.9ec6682f-a5e8-46a5-9fcf-9018b21d6dd0@github.com>
References: <0JydSewKO9NEDpCxjd1xtvCy4tXhsuMTv-LYrTw306I=.9ec6682f-a5e8-46a5-9fcf-9018b21d6dd0@github.com>
Message-ID: <u7bOLRgwfwrW69gPDPjl3etb1yrTyVFA2Cdu-l7lT0I=.0f066bef-cb8a-4b26-92b6-092341300703@github.com>

On Tue, 7 Oct 2025 08:28:01 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use the correct constant

This pull request has now been integrated.

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

8369260: [lworld] InnerClassLambdaMetafactory.java should use PREVIEW_MINOR_VERSION

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

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

From dsimms at openjdk.org  Tue Oct  7 13:59:23 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 7 Oct 2025 13:59:23 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <P2xUg_6VBFHXFjSSYoYHIbNw2xftkTdSzOnhmNXFRQQ=.94a55d22-c955-4774-bd2a-aa3b33f56e8e@github.com>

Merge jdk-26+14

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

Commit messages:
 - Timeouts after TIMEOUT_FACTOR adjust
 - Merge branch 'lworld' into lworld_merge_jdk_26_14
 - Sorted includes
 - Merge tag 'jdk-26+14' into lworld_merge_jdk_26_14
 - 8366420: AOTMapTest fails when default jsa is missing from JDK
 - 8366849: Problemlist jdk/jshell/ToolSimpleTest.java as generic-all
 - 8366778: Sort share/asm, share/gc, share/include includes
 - 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group()
 - 8366558: Gtests leave /tmp/cgroups-test* files
 - 8366490: C2 SuperWord: wrong result because CastP2X is missing ctrl and floats over SafePoint creating stale oops
 - ... and 107 more: https://git.openjdk.org/valhalla/compare/b789fa92...2c1c888b

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

Changes: https://git.openjdk.org/valhalla/pull/1667/files
  Stats: 16294 lines in 906 files changed: 11636 ins; 1843 del; 2815 mod
  Patch: https://git.openjdk.org/valhalla/pull/1667.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1667/head:pull/1667

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

From dsimms at openjdk.org  Tue Oct  7 17:27:33 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 7 Oct 2025 17:27:33 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <P2xUg_6VBFHXFjSSYoYHIbNw2xftkTdSzOnhmNXFRQQ=.94a55d22-c955-4774-bd2a-aa3b33f56e8e@github.com>
References: <P2xUg_6VBFHXFjSSYoYHIbNw2xftkTdSzOnhmNXFRQQ=.94a55d22-c955-4774-bd2a-aa3b33f56e8e@github.com>
Message-ID: <A8wQPoY5DoQ-lrZhkz_rmHw9f6FzuhKzkZl1OPNvcRQ=.21fe57b1-9425-48af-b15e-42dbeb36b5d7@github.com>

> Merge jdk-26+14

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

  More timing out

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1667/files
  - new: https://git.openjdk.org/valhalla/pull/1667/files/2c1c888b..d6b75454

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

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

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

From dsimms at openjdk.org  Tue Oct  7 17:27:34 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 7 Oct 2025 17:27:34 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <P2xUg_6VBFHXFjSSYoYHIbNw2xftkTdSzOnhmNXFRQQ=.94a55d22-c955-4774-bd2a-aa3b33f56e8e@github.com>
References: <P2xUg_6VBFHXFjSSYoYHIbNw2xftkTdSzOnhmNXFRQQ=.94a55d22-c955-4774-bd2a-aa3b33f56e8e@github.com>
Message-ID: <AhM_G3zyuQR7YJx731GL9JY8m3jQGNrZ2nQ2HRe0Aj8=.794b9783-e414-4115-b659-25dc3e4929ba@github.com>

On Tue, 7 Oct 2025 13:50:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+14

This pull request has now been integrated.

Changeset: 14a3c909
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/14a3c90986e8310b80d015f91f04be6e22eeb49d
Stats:     16296 lines in 907 files changed: 11636 ins; 1843 del; 2817 mod

Merge jdk

Merge jdk-26+14

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

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

From dsimms at openjdk.org  Tue Oct  7 17:44:47 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 7 Oct 2025 17:44:47 GMT
Subject: [lworld] RFR: 8369066: [lworld] UncaughtNativeExceptionTest.java
 fails with UnsupportedClassVersionError
In-Reply-To: <P7Dd9Z3xs6b9t-D_BU_3akpoB0LEy2N5ly3zyL8HzpU=.24563162-519f-44da-9305-7ee8db15b5ab@github.com>
References: <P7Dd9Z3xs6b9t-D_BU_3akpoB0LEy2N5ly3zyL8HzpU=.24563162-519f-44da-9305-7ee8db15b5ab@github.com>
Message-ID: <ckGeUr4ls3aZze1Ya1rWzw51KLShfmE5L-chlzbewQ0=.509d4ad0-526d-45e4-bcdc-2b5346b18e3b@github.com>

On Mon, 6 Oct 2025 15:26:17 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The `--enable-preview` was not propagated correctly to the sub-process used in this test so this option was added explicitly.

Marked as reviewed by dsimms (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1663#pullrequestreview-3311243992

From rriggs at openjdk.org  Tue Oct  7 18:56:10 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 7 Oct 2025 18:56:10 GMT
Subject: [lworld] RFR: 8369066: [lworld] UncaughtNativeExceptionTest.java
 fails with UnsupportedClassVersionError
In-Reply-To: <P7Dd9Z3xs6b9t-D_BU_3akpoB0LEy2N5ly3zyL8HzpU=.24563162-519f-44da-9305-7ee8db15b5ab@github.com>
References: <P7Dd9Z3xs6b9t-D_BU_3akpoB0LEy2N5ly3zyL8HzpU=.24563162-519f-44da-9305-7ee8db15b5ab@github.com>
Message-ID: <6AKmrxs65xmSC1pkz_IIZHYz2HuFLP5YsUTYSMy-46g=.1be426d8-ee48-4a86-97e9-fafe940499a9@github.com>

On Mon, 6 Oct 2025 15:26:17 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The `--enable-preview` was not propagated correctly to the sub-process used in this test so this option was added explicitly.

Marked as reviewed by rriggs (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1663#pullrequestreview-3311471627

From matsaave at openjdk.org  Tue Oct  7 19:27:02 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 7 Oct 2025 19:27:02 GMT
Subject: [lworld] RFR: 8369066: [lworld] UncaughtNativeExceptionTest.java
 fails with UnsupportedClassVersionError
In-Reply-To: <ckGeUr4ls3aZze1Ya1rWzw51KLShfmE5L-chlzbewQ0=.509d4ad0-526d-45e4-bcdc-2b5346b18e3b@github.com>
References: <P7Dd9Z3xs6b9t-D_BU_3akpoB0LEy2N5ly3zyL8HzpU=.24563162-519f-44da-9305-7ee8db15b5ab@github.com>
 <ckGeUr4ls3aZze1Ya1rWzw51KLShfmE5L-chlzbewQ0=.509d4ad0-526d-45e4-bcdc-2b5346b18e3b@github.com>
Message-ID: <NhwiAyF2Lm4BhAB-uQWgMgA-yL9rQqQ_rOdajAsCmEs=.16902158-9d56-493e-b671-477a90973d38@github.com>

On Tue, 7 Oct 2025 17:41:48 GMT, David Simms <dsimms at openjdk.org> wrote:

>> The `--enable-preview` was not propagated correctly to the sub-process used in this test so this option was added explicitly.
>
> Marked as reviewed by dsimms (Committer).

Thank you for the reviews @MrSimms and @RogerRiggs

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

PR Comment: https://git.openjdk.org/valhalla/pull/1663#issuecomment-3378393338

From matsaave at openjdk.org  Tue Oct  7 19:27:03 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 7 Oct 2025 19:27:03 GMT
Subject: [lworld] Integrated: 8369066: [lworld]
 UncaughtNativeExceptionTest.java fails with UnsupportedClassVersionError
In-Reply-To: <P7Dd9Z3xs6b9t-D_BU_3akpoB0LEy2N5ly3zyL8HzpU=.24563162-519f-44da-9305-7ee8db15b5ab@github.com>
References: <P7Dd9Z3xs6b9t-D_BU_3akpoB0LEy2N5ly3zyL8HzpU=.24563162-519f-44da-9305-7ee8db15b5ab@github.com>
Message-ID: <BOaHOd8x-bpJmtjKbhTJzMM9ERA5Kh8zJK1yzSPOV6k=.3e758f8a-e38e-4f57-8094-34de241dd92a@github.com>

On Mon, 6 Oct 2025 15:26:17 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The `--enable-preview` was not propagated correctly to the sub-process used in this test so this option was added explicitly.

This pull request has now been integrated.

Changeset: a5924471
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a5924471d7a3f4808966cc974c42cd41cd0717cf
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8369066: [lworld] UncaughtNativeExceptionTest.java fails with UnsupportedClassVersionError

Reviewed-by: dsimms, rriggs

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

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

From duke at openjdk.org  Wed Oct  8 11:37:48 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 11:37:48 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <STcHR1GN0xmHp6VdRSx8z6N8GSslssb2TXqU9jr73Z8=.665dfa6d-a006-45ca-a226-1dc54d95bbf2@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <STcHR1GN0xmHp6VdRSx8z6N8GSslssb2TXqU9jr73Z8=.665dfa6d-a006-45ca-a226-1dc54d95bbf2@github.com>
Message-ID: <ZwJOK9d6uUxsIiow5ML_-scXFaJHrlcoeCbfsaGCe0U=.7639d8b2-a3f8-4777-a104-0ea77edc8ecb@github.com>

On Mon, 29 Sep 2025 01:41:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> src/java.base/share/native/libjimage/imageFile.hpp line 253:
> 
>> 251:         // Set on a "normal" (non-preview) location if a preview version of
>> 252:         // it exists in the same module.
>> 253:         FLAGS_HAS_PREVIEW_VERSION = 0x1,
> 
> To avoid confusion, the value and spelling of the flag should agree across all modules.
> In ImageLocation and jimage/ModulesReference.

ModulesReference are different flags, with different semantics. That's why I made sure they were private and provided helper methods for reading/writing the package directory offsets (because I did trip over using the wrong constants at one point).

I agree it's weird/annoying to have this similar-but-different set of flags, but the ModuleReference flags are completely encapsulated in one place, so cannot be accidentally confused with, or misused in place of the ImageLocation flags.

These flags have a requirement of being zero for almost all entries to reduce image file size, while the ModulesReference flags need to additive for merging (and are not stored in the same part of the jimage file).

I could change flag ordering to make the values match, but since they must never be mistaken for each other, I'm not sure that's beneficial (if anything it might foster the idea that the flags can be used interchangeably in some way).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2413560102

From duke at openjdk.org  Wed Oct  8 11:46:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 11:46:44 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <GvXtJ7RzLojuwFahtA9YkiCvxXzM46Myxet2SdvGSTs=.009f7f21-eff7-4ecc-8ab7-0c26bf4d5cf3@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <STcHR1GN0xmHp6VdRSx8z6N8GSslssb2TXqU9jr73Z8=.665dfa6d-a006-45ca-a226-1dc54d95bbf2@github.com>
 <GvXtJ7RzLojuwFahtA9YkiCvxXzM46Myxet2SdvGSTs=.009f7f21-eff7-4ecc-8ab7-0c26bf4d5cf3@github.com>
Message-ID: <Brc-guIDoBGcOoom6_ipMmcUZ9-Tg3MqthAfx1Qbfn0=.b7fb98d6-e5b9-4e40-9cab-4f5c89e5a2ac@github.com>

On Mon, 29 Sep 2025 14:43:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/native/libjimage/imageFile.hpp line 259:
>> 
>>> 257:         // it exists in the same module.
>>> 258:         FLAGS_IS_PREVIEW_ONLY = 0x4
>>> 259:     };
>> 
>> A refactoring of the flags can avoid conflicting states.
>> FLAGS_IS_PREVIEW_VERSION = 2;   // set for preview version
>> FLAGS_NO_NORMAL_VERSION = 1;    // preserving the zero value for normal and no preview.
>> 
>> Create static methods in ImageLocation to perform the desired tests on flags.
>> The utility methods make the code easier to read.
>> Also define macros/function in the native code in ImageFile and jimage.
>> 
>> isPreviewVersion(flags) { return (flags & FLAGS_IS_PREVIEW_VERSION) != 0)}
>> isPreviewOnly(flags) { return (flags & FLAGS_IS_REVIEW_VERSION | FLAGS_NO_NORMAL_VERSION) == FLAGS_NO_NORMAL_VERSION}
>
> Reprise:
> 
> Your name FLAGS_IS_PREVIEW_ONLY probably better than FLAGS_NO_NORMAL_VERSION and has the same semantics.
> 
> FLAGS_HAS_PREVIEW_VERSION means that there is a preview version and it will be found in the <META-INF/Preview> hierarchy. if the flag is in the preview node then this is it. If found in the normal hierarchy, the preview class is found in the <META-INF/Preview> hierarchy.

The FLAGS_HAS_PREVIEW_VERSION flag is only set on non-preview locations. It's what indicates that you may need to look for a preview version in preview mode (rare but possible).

For C++ I think this occasional 2nd hash calculation and lookup shouldn't be an issue because it's for class loading, so each successful lookup triggers a lot of additional work (and as I understand it, failed lookups should not be common in this code -- as opposed to the JRT file system code).

There are several possible approaches to address this is it does turn out to be a performance issue though.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2413582640

From duke at openjdk.org  Wed Oct  8 12:25:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 12:25:38 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <VIZeTXoW0TzmQNDIyhCyVtRWMMFQ9p8LzkNNXz8zCfM=.3896deb9-c5ac-4aa4-807d-ebe6f44bf9e6@github.com>

On Wed, 24 Sep 2025 18:20:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 42:
> 
>> 40:  * <ul>
>> 41:  *     <li>src/java.base/share/native/libjimage/imageFile.hpp
>> 42:  * </ul>
> 
> Are there any java source files that have to be updated on a version change?

This is it I think. Everything else reading/writing the jimage file just uses this constant as far as I can tell. But it's possible I'm wrong. Certainly none of the code I'm changing in these PRs needed more than this altered for the version bump, but I can't rule out things like command line tools I've not found yet (but I have no evidence). The jimage tool uses these classes, so gets the change from here.

> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 72:
> 
>> 70:      * <p>This flag is mutually exclusive with {@link #FLAGS_HAS_PREVIEW_VERSION}.
>> 71:      */
>> 72:     public static final int FLAGS_IS_PREVIEW_VERSION = 0x2;
> 
> Seems to be redundant with HAS_PREVIEW_VERSION when seen in a preview location.

Ah, but HAS_PREVIEW_VERSION is never set on a preview location. It's only for non-preview locations to indicate that a (different) preview version exists.

HAS_PREVIEW_VERSION can also be set for /packages/xxx directory entries (where it means "some of the entries are modules in which preview versions of resources exist" rather than "there's a META-INF/preview version of this entry"). IS_PREVIEW_VERSION is kind of meaningless for the /packages/xxx directories though, and is never set on them.

I'm not sure I'm a fan of trying to merge the semantics of these into some sort of "HAS_OR_IS_PREVIEW_VERSION" flag though. We're not short on flag space (and are extremely unlikely to ever be).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2413662039
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2413668235

From duke at openjdk.org  Wed Oct  8 12:37:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 12:37:44 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <UvS7dq5MMiZT1lshSB6KxkycWHH2tUGfX4rTllgToHA=.67b68fef-2eee-4ff7-8fe5-61751b487c47@github.com>

On Wed, 24 Sep 2025 18:23:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 87:
> 
>> 85:      * for {@code /packages/xxx} directories).
>> 86:      */
>> 87:     public static final int FLAGS_IS_PREVIEW_ONLY = 0x4;
> 
> The preview-only case is expected to be the empty set. There seems to be a lot of code dedicated to it.

Well it's a small set, but vitally important. Preview only is the case where you can't lookup the normal resource first and check its flags to see if there's a preview version. Since you must correct find all preview-only resources, you are left with either:

* *always* speculatively looking up all resources in their preview location when not found otherwise.
* Doing something "cleverer" to reduce double lookups.

In the C++ class-loader (as I understand it) most lookups will be for things referenced in other class files, and thus expected to exist. This makes "if you can't find the normal version, look for the preview version" acceptable (I think) because this should be only in cases where you're looking for something that should exist at one of the two paths.

In the Java stuff, there's a lot of speculative lookup, especially for non-class resources. All modules are tested for any non-existent resource. So in this case the strategy needs to be cleverer or you'll basically (at least) double the cost of a lot of things.

So I settled on the easiest approach to be to just (efficiently) pre-scan for preview resources and put them in the node cache during init (this is only about the same work the old code did for link nodes etc.). Once they're cached, the lookup code no longer has to care about 2nd lookups or anything. Preview versions and preview-only versions are just treated the same, they're in the cache, so they're found and returned without looking at anything else.

This is partly why there's the "ensureCached" method which guarantees you never replace what's in the cache with anything else (so preview stuff put there during init of the reader is "safe" from accidental overwriting).

The new flag stuff and change of ordering of package entries is there mostly to support efficient pre-scanning of the small set of preview only resources.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2413711669

From duke at openjdk.org  Wed Oct  8 12:44:01 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 12:44:01 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <AgW8uAwUv6Lg8B5HnDDZi7EKu5CwCpPhtm8zTVFyr0o=.30b5614d-ec92-4fc9-9c84-fb3d5672e254@github.com>

On Wed, 24 Sep 2025 21:14:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java line 125:
> 
>> 123:         } else if (envValue instanceof String && Boolean.parseBoolean((String) envValue)) {
>> 124:             return PreviewMode.ENABLED;
>> 125:         }
> 
> This kind of ambiguous type for the environment variable should not be supported. 
> Pick a type and stick to it.  
> Whereever the jrt: file system is specified will need a description for enablePreview to be added to the spec.

Other file-system flags already do this, so I was just copying that approach. Happy to not do this though.
Which do you suggest, Boolean or String?

> src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 79:
> 
>> 77: 
>> 78:         // TODO: Maybe throw if enablePreview attempted for exploded image?
>> 79: 
> 
> Exploded image is useful for debugging, it could support preview mode using the same META-INF directory structure.

Indeed. I can support it later, I'm just wondering if, in this partially complete state, I should complain or not.
I've got most of the code for that done somewhere or other.

> test/jdk/jdk/internal/jimage/ModuleReferenceTest.java line 228:
> 
>> 226: 
>> 227:     // Encodes strings sequentially starting from index 100.
>> 228:     private static Function<String, Integer> testEncoder() {
> 
> The method name `testEncoder` gives the impression of being a test, but it is just a utility function used by a test.

Goood point. It took me years to stop naming all my unit test methods testXxxx() so I should have spotted this. Thanks.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2413721287
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2413724197
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2413726546

From duke at openjdk.org  Wed Oct  8 13:26:39 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 13:26:39 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v4]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <8NZCno5Cy-OweKDGMTxa5wocmI13pTKnIpXdaRj2b_s=.4d08094f-6127-4943-b8ea-9ac5b7febe9c@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

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

  Test fixes and feedback changes.
  
  * Renaming slightly confusing "testEncoder" method.
  * Fixing unit tests to use new constructor.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1619/files
  - new: https://git.openjdk.org/valhalla/pull/1619/files/936b22d1..c9989bdd

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

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

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

From rriggs at openjdk.org  Wed Oct  8 15:31:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 15:31:57 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <VIZeTXoW0TzmQNDIyhCyVtRWMMFQ9p8LzkNNXz8zCfM=.3896deb9-c5ac-4aa4-807d-ebe6f44bf9e6@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
 <VIZeTXoW0TzmQNDIyhCyVtRWMMFQ9p8LzkNNXz8zCfM=.3896deb9-c5ac-4aa4-807d-ebe6f44bf9e6@github.com>
Message-ID: <qA58V9nRZm1pjpGGYA9L5QXkt7VDpt6gKXLwDDAynsU=.be8762fc-863f-4764-8f70-d9ea97a0c0be@github.com>

On Wed, 8 Oct 2025 12:18:37 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 72:
>> 
>>> 70:      * <p>This flag is mutually exclusive with {@link #FLAGS_HAS_PREVIEW_VERSION}.
>>> 71:      */
>>> 72:     public static final int FLAGS_IS_PREVIEW_VERSION = 0x2;
>> 
>> Seems to be redundant with HAS_PREVIEW_VERSION when seen in a preview location.
>
> Ah, but HAS_PREVIEW_VERSION is never set on a preview location. It's only for non-preview locations to indicate that a (different) preview version exists.
> 
> HAS_PREVIEW_VERSION can also be set for /packages/xxx directory entries (where it means "some of the entries are modules in which preview versions of resources exist" rather than "there's a META-INF/preview version of this entry"). IS_PREVIEW_VERSION is kind of meaningless for the /packages/xxx directories though, and is never set on them.
> 
> I'm not sure I'm a fan of trying to merge the semantics of these into some sort of "HAS_OR_IS_PREVIEW_VERSION" flag though. We're not short on flag space (and are extremely unlikely to ever be).

I see the semantics of the flag as `there-is-a-preview-version` of the resource.
Where-ever it appears, it means that the resource/class is in the preview branch of the hierarchy.
If the flag appears in the normal hierarchy index, it still means the same, look in the preview hierarchy.
If it appears on a directory, it means there preview resources in/below.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414264185

From rriggs at openjdk.org  Wed Oct  8 15:44:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 8 Oct 2025 15:44:27 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <UvS7dq5MMiZT1lshSB6KxkycWHH2tUGfX4rTllgToHA=.67b68fef-2eee-4ff7-8fe5-61751b487c47@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
 <UvS7dq5MMiZT1lshSB6KxkycWHH2tUGfX4rTllgToHA=.67b68fef-2eee-4ff7-8fe5-61751b487c47@github.com>
Message-ID: <EvVTXEDVnIQiRlxFVnu-yJ0z6QntVb3yKsEldbyD1jE=.3795a891-82c2-4a70-aafb-e66fabe42936@github.com>

On Wed, 8 Oct 2025 12:35:21 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 87:
>> 
>>> 85:      * for {@code /packages/xxx} directories).
>>> 86:      */
>>> 87:     public static final int FLAGS_IS_PREVIEW_ONLY = 0x4;
>> 
>> The preview-only case is expected to be the empty set. There seems to be a lot of code dedicated to it.
>
> Well it's a small set, but vitally important. Preview only is the case where you can't lookup the normal resource first and check its flags to see if there's a preview version. Since you must correct find all preview-only resources, you are left with either:
> 
> * *always* speculatively looking up all resources in their preview location when not found otherwise.
> * Doing something "cleverer" to reduce double lookups.
> 
> In the C++ class-loader (as I understand it) most lookups will be for things referenced in other class files, and thus expected to exist. This makes "if you can't find the normal version, look for the preview version" acceptable (I think) because this should be only in cases where you're looking for something that should exist at one of the two paths.
> 
> In the Java stuff, there's a lot of speculative lookup, especially for non-class resources. All modules are tested for any non-existent resource. So in this case the strategy needs to be cleverer or you'll basically (at least) double the cost of a lot of things.
> 
> So I settled on the easiest approach to be to just (efficiently) pre-scan for preview resources and put them in the node cache during init (this is only about the same work the old code did for link nodes etc.). Once they're cached, the lookup code no longer has to care about 2nd lookups or anything. Preview versions and preview-only versions are just treated the same, they're in the cache, so they're found and returned without looking at anything else.
> 
> This is partly why there's the "ensureCached" method which guarantees you never replace what's in the cache with anything else (so preview stuff put there during init of the reader is "safe" from accidental overwriting).
> 
> The new flag stuff and change of ordering of package entries is there mostly to support efficient pre-scanning of the small set of preview only resources.

I'm still going to say, there are no plans to have any Preview-only resources.

And yes, a preview-only flag would be useful to (mostly) avoid a second lookup.
If I understand the design, there is still a location in the normal tree with the preview-only flag but there is no resource at that location, only the flags.  And a second lookup is needed to find the location in the preview heirarchy. The caching avoids repeated 2nd lookups.

>> src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java line 125:
>> 
>>> 123:         } else if (envValue instanceof String && Boolean.parseBoolean((String) envValue)) {
>>> 124:             return PreviewMode.ENABLED;
>>> 125:         }
>> 
>> This kind of ambiguous type for the environment variable should not be supported. 
>> Pick a type and stick to it.  
>> Whereever the jrt: file system is specified will need a description for enablePreview to be added to the spec.
>
> Other file-system flags already do this, so I was just copying that approach. Happy to not do this though.
> Which do you suggest, Boolean or String?

Strings are more frequent and conventional.

>> src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 79:
>> 
>>> 77: 
>>> 78:         // TODO: Maybe throw if enablePreview attempted for exploded image?
>>> 79: 
>> 
>> Exploded image is useful for debugging, it could support preview mode using the same META-INF directory structure.
>
> Indeed. I can support it later, I'm just wondering if, in this partially complete state, I should complain or not.
> I've got most of the code for that done somewhere or other.

Throwing with a message would avoid doubt about whether it is supported.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414290560
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414296625
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414298186

From duke at openjdk.org  Wed Oct  8 16:23:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 16:23:55 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <EvVTXEDVnIQiRlxFVnu-yJ0z6QntVb3yKsEldbyD1jE=.3795a891-82c2-4a70-aafb-e66fabe42936@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
 <UvS7dq5MMiZT1lshSB6KxkycWHH2tUGfX4rTllgToHA=.67b68fef-2eee-4ff7-8fe5-61751b487c47@github.com>
 <EvVTXEDVnIQiRlxFVnu-yJ0z6QntVb3yKsEldbyD1jE=.3795a891-82c2-4a70-aafb-e66fabe42936@github.com>
Message-ID: <GVoVYozESJ_cW2nBlY8FIUDgzSwPX_5ik70LFHPZ3MU=.74e58e80-d7c1-422d-abfd-24049196be13@github.com>

On Wed, 8 Oct 2025 15:38:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Well it's a small set, but vitally important. Preview only is the case where you can't lookup the normal resource first and check its flags to see if there's a preview version. Since you must correct find all preview-only resources, you are left with either:
>> 
>> * *always* speculatively looking up all resources in their preview location when not found otherwise.
>> * Doing something "cleverer" to reduce double lookups.
>> 
>> In the C++ class-loader (as I understand it) most lookups will be for things referenced in other class files, and thus expected to exist. This makes "if you can't find the normal version, look for the preview version" acceptable (I think) because this should be only in cases where you're looking for something that should exist at one of the two paths.
>> 
>> In the Java stuff, there's a lot of speculative lookup, especially for non-class resources. All modules are tested for any non-existent resource. So in this case the strategy needs to be cleverer or you'll basically (at least) double the cost of a lot of things.
>> 
>> So I settled on the easiest approach to be to just (efficiently) pre-scan for preview resources and put them in the node cache during init (this is only about the same work the old code did for link nodes etc.). Once they're cached, the lookup code no longer has to care about 2nd lookups or anything. Preview versions and preview-only versions are just treated the same, they're in the cache, so they're found and returned without looking at anything else.
>> 
>> This is partly why there's the "ensureCached" method which guarantees you never replace what's in the cache with anything else (so preview stuff put there during init of the reader is "safe" from accidental overwriting).
>> 
>> The new flag stuff and change of ordering of package entries is there mostly to support efficient pre-scanning of the small set of preview only resources.
>
> I'm still going to say, there are no plans to have any Preview-only resources.
> 
> And yes, a preview-only flag would be useful to (mostly) avoid a second lookup.
> If I understand the design, there is still a location in the normal tree with the preview-only flag but there is no resource at that location, only the flags.  And a second lookup is needed to find the location in the preview heirarchy. The caching avoids repeated 2nd lookups.

Any new lambda or inner-class in a preview class is a new preview-only resource. It's definitely going to happen.
Additionally, if an entry is preview only, there's simply nothing in the jimage at the non-preview location. No flags, no nothing.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414403794

From matsaave at openjdk.org  Wed Oct  8 17:12:25 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 8 Oct 2025 17:12:25 GMT
Subject: [lworld] RFR: 8369446: [lworld] Problem list LoggingDeadlock2
Message-ID: <9EoBRBBKe3jvbPhiQf62rym3yrCSkaskyJJ8n6bnxPg=.1b832f03-91d9-4b84-976a-191d96775fc5@github.com>

This test fails with -XX:AOTClassLinking but the failure should no longer occur after upstreaming [JDK-8364929](https://bugs.openjdk.org/browse/JDK-8364929). This test should be problem listed for now.

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

Commit messages:
 - 8369446: [lworld] Problem list LoggingDeadlock2

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

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

From duke at openjdk.org  Wed Oct  8 17:15:53 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 17:15:53 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <qA58V9nRZm1pjpGGYA9L5QXkt7VDpt6gKXLwDDAynsU=.be8762fc-863f-4764-8f70-d9ea97a0c0be@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
 <VIZeTXoW0TzmQNDIyhCyVtRWMMFQ9p8LzkNNXz8zCfM=.3896deb9-c5ac-4aa4-807d-ebe6f44bf9e6@github.com>
 <qA58V9nRZm1pjpGGYA9L5QXkt7VDpt6gKXLwDDAynsU=.be8762fc-863f-4764-8f70-d9ea97a0c0be@github.com>
Message-ID: <9OIY7bwLhubt_QZvU3EAwBQ09-gmcoGgweCCqqSLsEs=.9a77bc85-3f15-48e8-a2e5-f66ad2a2a00c@github.com>

On Wed, 8 Oct 2025 15:29:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ah, but HAS_PREVIEW_VERSION is never set on a preview location. It's only for non-preview locations to indicate that a (different) preview version exists.
>> 
>> HAS_PREVIEW_VERSION can also be set for /packages/xxx directory entries (where it means "some of the entries are modules in which preview versions of resources exist" rather than "there's a META-INF/preview version of this entry"). IS_PREVIEW_VERSION is kind of meaningless for the /packages/xxx directories though, and is never set on them.
>> 
>> I'm not sure I'm a fan of trying to merge the semantics of these into some sort of "HAS_OR_IS_PREVIEW_VERSION" flag though. We're not short on flag space (and are extremely unlikely to ever be).
>
> I see the semantics of the flag as `there-is-a-preview-version` of the resource.
> Where-ever it appears, it means that the resource/class is in the preview branch of the hierarchy.
> If the flag appears in the normal hierarchy index, it still means the same, look in the preview hierarchy.
> If it appears on a directory, it means there preview resources in/below.

There is no "*the* resource/class" in the jimage file, because both can be present. It depends on whether the path to the entry contains META-INF/preview or not. So where a normal resource has a preview version, the same flag would be set on both.

For example, I don't see how this works if the flags have the same value.


    // Regardless of preview mode, don't return resources requested directly
    // via their preview path.
    if ((flags & ImageLocation::FLAGS_IS_PREVIEW_VERSION) != 0) {
        return 0L;
    }
    // Even if there is a preview version, we might not want to return it.
    if (!is_preview_mode || (flags & ImageLocation::FLAGS_HAS_PREVIEW_VERSION) == 0) {
        return locOffset;
    }

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414524082

From duke at openjdk.org  Wed Oct  8 18:19:53 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 18:19:53 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <My6GChuQhxwXGurlF4v3KLt5ccgK1DhktE_BdWAcKlU=.1417cbef-17f3-4d78-abfc-dec3fc76e7f5@github.com>

On Wed, 24 Sep 2025 20:56:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 559:
> 
>> 557:             loc = findLocation(name.substring(MODULES_PREFIX.length()));
>> 558:             return ensureCachedIfNonNull(
>> 559:                     loc != null && loc.getType() == RESOURCE ? newResource(name, loc) : null);
> 
> It seems odd to test loc and type to produce a null and them pass it to a method that will do nothing.
> The non-productive test can be done and return immediately.

Yeah, you're absolutely right, not sure what I was thinking there.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414665706

From duke at openjdk.org  Wed Oct  8 19:10:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 19:10:31 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v3]
In-Reply-To: <w-7Ab6qD3FDRW7XY9D-on6p7GeG0ZDrTEGUYnYNZcWg=.fe294df5-d4e4-48f3-a725-26c8485e83b2@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
 <GXRcWlgy-5WY0DM560h8AHexiI9CLGFUNyG_ogpczRs=.03766e7d-d426-490e-9908-7c5daca4ac51@github.com>
 <w-7Ab6qD3FDRW7XY9D-on6p7GeG0ZDrTEGUYnYNZcWg=.fe294df5-d4e4-48f3-a725-26c8485e83b2@github.com>
Message-ID: <wLTtKD7eztn_UIPLaHGrLVIghB7oNwbkLe3HlAXw2Xg=.1cbfb5ec-2972-465d-95c6-fa5ddcb70ff8@github.com>

On Fri, 26 Sep 2025 19:30:11 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 four new commits since the last revision:
>> 
>>  - Restoring lost changes and updating some comments.
>>  - add system property guard to preview mode
>>  - jimage writer changes to support preview mode.
>>    
>>    * Remove TODOs now jimage version is bumped
>>    * jimage writer changes to support preview mode.
>>  - Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/PreviewMode.java line 68:
> 
>> 66:             if (!ENABLE_PREVIEW_MODE) {
>> 67:                 return false;
>> 68:             }
> 
> As commented in the 1618 PR, the extra subclasses caused by the overrides can be replaced by the resolve method switching on `ordinal()`.

Great idea, thanks.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2414778951

From duke at openjdk.org  Wed Oct  8 19:12:25 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 19:12:25 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <89fD_pwfGsZ2TaZ5nseFz0D3xWnYb1NZmZIP6_oGId8=.7f1a4179-2d0c-40dc-88ef-26d69ed52065@github.com>

On Wed, 24 Sep 2025 18:26:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 56:
> 
>> 54:     /**
>> 55:      * Indicates that a non-preview location is associated with preview
>> 56:      * resources.
> 
> This comment would read better saying that preview resources exist related to this location.
> More like FLAGS_HAS_PREVIEW_VERSION.

Ahh, but it's deliberately not worded like that because this flag can be set for "/packages/xxx" entries, for which "preview resources exist related to this location" is not a meaningful statement.

This is where you could add another flag (e.g. "FLAGS_PACKAGE_HAS_PREVIEW_ENTRIES"), but it felt better to use the same flag for this, since where it's calculated becomes a neat case of just propagating the flag (next PR):


            // Calculate the package's ImageLocation flags.
            boolean hasPreviewVersion =
                    moduleReferences.stream().anyMatch(ModuleReference::hasPreviewVersion);
            boolean isPreviewOnly =
                    moduleReferences.stream().allMatch(ModuleReference::isPreviewOnly);
            return (hasPreviewVersion ? ImageLocation.FLAGS_HAS_PREVIEW_VERSION : 0)
                    | (isPreviewOnly ? ImageLocation.FLAGS_IS_PREVIEW_ONLY : 0);


And the flag/method names in this code just match across this logic.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414783866

From duke at openjdk.org  Wed Oct  8 19:33:24 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 19:33:24 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <EvVTXEDVnIQiRlxFVnu-yJ0z6QntVb3yKsEldbyD1jE=.3795a891-82c2-4a70-aafb-e66fabe42936@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
 <UvS7dq5MMiZT1lshSB6KxkycWHH2tUGfX4rTllgToHA=.67b68fef-2eee-4ff7-8fe5-61751b487c47@github.com>
 <EvVTXEDVnIQiRlxFVnu-yJ0z6QntVb3yKsEldbyD1jE=.3795a891-82c2-4a70-aafb-e66fabe42936@github.com>
Message-ID: <1TZShS6etI6rIkxAOiwcOOL8d1t068S-DvEpScSGM_M=.16700e79-1963-40b8-b67b-0341c0c92eec@github.com>

On Wed, 8 Oct 2025 15:40:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Other file-system flags already do this, so I was just copying that approach. Happy to not do this though.
>> Which do you suggest, Boolean or String?
>
> Strings are more frequent and conventional.

Done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414827142

From duke at openjdk.org  Wed Oct  8 19:38:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 19:38:13 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <r12hXqz53fIrZmJCruGYlJLU1GJhMkSBUOIZe0DC48w=.fdeba537-1885-4c38-b325-3018092d3f79@github.com>

On Wed, 24 Sep 2025 18:36:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 66:
> 
>> 64:     private static final int FLAGS_HAS_NORMAL_VERSION = 0x2;
>> 65:     /** If set, this package exists in preview mode. */
>> 66:     private static final int FLAGS_HAS_PREVIEW_VERSION = 0x4;
> 
> The flags should be aligned with ImageLocation to avoid confusion. Even if in different contexts the meaning (and bits) should be the same to carry-over the concepts.
> 
> The encapsulation of tests for flags helps. It might help in ImageLocation too.

Yes, by making the ImageReader *not* import the flags I can make them private too (thanks for the suggestion).
I will reorder the HAS_PREVIEW_VERSION flag in ModuleReference to have the same value/name.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414838314

From duke at openjdk.org  Wed Oct  8 19:49:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 19:49:02 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <eEadIVC18QiELX5jGiX_UWe-vvYV0cFM_YzNsVSkF4A=.3c3cb92e-0f73-4a00-98ed-1689a2767151@github.com>

On Wed, 24 Sep 2025 18:36:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 86:
> 
>> 84:         return new ModuleReference(moduleName, FLAGS_HAS_CONTENT | previewFlag(isPreview));
>> 85:     }
>> 86: 
> 
> Using "of" as the prefix for the method name instead of "for" would align better with many other APIs.

Hmm, I've always used "ofXxx" only when the `Xxx` is part of the given input.

In this case the term "resource" isn't referring to the input, but the type of thing the reference is used for (something with content). In that situation `ofResource(<none-of-the-parameters-reference-a-resource>)` feels weird to me.

Maybe `forResourceIn(<module-name>, <flag>)` makes it clearer a resource is not being passed into the method.
Thoughts?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414858138

From duke at openjdk.org  Wed Oct  8 19:58:15 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 19:58:15 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <RoyjcAXObvd-fPSmprRP6F-qy3PM3aZKpcX7MQ_PYVY=.e74597ed-35c7-4e06-93d7-55454a67e69d@github.com>

On Wed, 24 Sep 2025 18:54:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 333:
> 
>> 331:                 // it references have that package marked as preview only.
>> 332:                 // Skipping these entries avoids empty package subdirectories.
>> 333:                 if (previewMode || (flags & FLAGS_IS_PREVIEW_ONLY) == 0) {
> 
> Add utility methods for FLAGS_IS_PREVIEW_ONLY == 0

Done (in next push).

> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 122:
> 
>> 120:     public boolean hasContent() {
>> 121:         return ((flags & FLAGS_HAS_CONTENT) != 0);
>> 122:     }
> 
> isEmpty could avoid introducing "content" as a loosely defined term.
> It would be more similar to directories being empty or lists being empty.

I've bounced between this several times. The thing is that a non-empty package directory will not have content if it only contains other directories, and seeing logic talking about a package being "empty" when it has child directories is weird/confusing. I've actually thought about this naming quite hard and I think it's more misleading to use the term "empty". However, since it's obviously still not clear enough maybe a different name altogether?

How about "hasResources()" or "hasResourceContent()" ?

> src/java.base/share/classes/jdk/internal/jimage/PreviewMode.java line 65:
> 
>> 63:     FOR_RUNTIME() {
>> 64:         @Override
>> 65:         boolean resolve() {
> 
> Each of these overrides creates an extra subclass.
> The alternative is for the resolve method use a switch on the ordinal to return or compute the boolean.

Excellent point, I'll fix this in the next push.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414886599
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414884864
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2414885908

From duke at openjdk.org  Wed Oct  8 22:06:24 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 22:06:24 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v5]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <ZHXdHduFUttr22pDfgUq-2r03pAEwuZ8-Of3C_3FC-Y=.13f6791f-494b-4cce-87c7-030184e7127c@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

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

  Feedback changes, and fixing some comments.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1619/files
  - new: https://git.openjdk.org/valhalla/pull/1619/files/c9989bdd..8838ad26

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

  Stats: 172 lines in 7 files changed: 76 ins; 56 del; 40 mod
  Patch: https://git.openjdk.org/valhalla/pull/1619.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1619/head:pull/1619

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

From duke at openjdk.org  Wed Oct  8 22:32:25 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 22:32:25 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
Message-ID: <2MZmCAVfcF7oy1akJQG88r4KX8HQSturSJfaUEPRaic=.f1702032-5dd9-44de-8066-fb0a0c5d0511@github.com>

On Wed, 24 Sep 2025 18:24:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Manually deleting ImageReaderFactory (it returned somehow)
>
> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 104:
> 
>> 102:     /**
>> 103:      * Helper function to calculate preview flags (ATTRIBUTE_PREVIEW_FLAGS).
>> 104:      *
> 
> A summary of what gets what flags might be easier to read than the code.
> Or list the flags and refer to their descriptions (that would describe the paths where the flags would be found)

Done in latest snapshot.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2415162998

From duke at openjdk.org  Wed Oct  8 23:26:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 23:26:55 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v6]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

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

  Changing existing package flags during writing to match altered flag values.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1619/files
  - new: https://git.openjdk.org/valhalla/pull/1619/files/8838ad26..2c0db3d3

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

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

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

From duke at openjdk.org  Wed Oct  8 23:26:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 8 Oct 2025 23:26:57 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <r12hXqz53fIrZmJCruGYlJLU1GJhMkSBUOIZe0DC48w=.fdeba537-1885-4c38-b325-3018092d3f79@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
 <r12hXqz53fIrZmJCruGYlJLU1GJhMkSBUOIZe0DC48w=.fdeba537-1885-4c38-b325-3018092d3f79@github.com>
Message-ID: <TxqAhzLpUbmKQDm7EBKKB-ksu6qZ2GJ83u9bN23SMJU=.dccdf076-832c-41c0-a341-13e78059f251@github.com>

On Wed, 8 Oct 2025 19:35:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 66:
>> 
>>> 64:     private static final int FLAGS_HAS_NORMAL_VERSION = 0x2;
>>> 65:     /** If set, this package exists in preview mode. */
>>> 66:     private static final int FLAGS_HAS_PREVIEW_VERSION = 0x4;
>> 
>> The flags should be aligned with ImageLocation to avoid confusion. Even if in different contexts the meaning (and bits) should be the same to carry-over the concepts.
>> 
>> The encapsulation of tests for flags helps. It might help in ImageLocation too.
>
> Yes, by making the ImageReader *not* import the flags I can make them private too (thanks for the suggestion).
> I will reorder the HAS_PREVIEW_VERSION flag in ModuleReference to have the same value/name.

This also entails a small (temporary) change to image writing code (until the next PR).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2415223171

From jatinbha.cloud at gmail.com  Thu Oct  9 09:15:26 2025
From: jatinbha.cloud at gmail.com (Jatin Bhateja)
Date: Thu, 9 Oct 2025 14:45:26 +0530
Subject: CFV: New Valhalla Committer: Marc Chevalier
In-Reply-To: <SJ2PR10MB7669D74D1AFA7A1BE69C1790A21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <ddbbc523-1d0c-4c55-ae47-04c192fa3a6f@oracle.com>
 <SJ2PR10MB7669D74D1AFA7A1BE69C1790A21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <3ab49d3d-2ca4-408a-b914-0b6bb3ae5340@gmail.com>

Vote: yes


Best Regards


On 9/30/2025 6:43 PM, Chen Liang wrote:
> Vote: yes
>
> Chen Liang
> ------------------------------------------------------------------------
> *From:* valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of 
> Tobias Hartmann <tobias.hartmann at oracle.com>
> *Sent:* Tuesday, September 30, 2025 3:00 AM
> *To:* valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
> *Cc:* Marc Chevalier <marc.chevalier at oracle.com>
> *Subject:* CFV: New Valhalla Committer: Marc Chevalier
> I hereby nominate Marc Chevalier [1] to Valhalla Committer.
>
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 37 
> changes to the JDK project [2] and 12 changes to the Valhalla project [3].
>
> Votes are due by October 14, 2025, 08:00 UTC.
>
> Only current Valhalla Committers [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Lazy Consensus voting instructions, see [5].
>
> Best regards,
> Tobias
>
> [1] https://openjdk.org/census#mchevalier
> [2] 
> https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 
> <https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1>
> [3] 
> https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20mchevalier%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251009/97396ff6/attachment.htm>

From jatinbha.cloud at gmail.com  Thu Oct  9 09:15:53 2025
From: jatinbha.cloud at gmail.com (Jatin Bhateja)
Date: Thu, 9 Oct 2025 14:45:53 +0530
Subject: CFV: New Valhalla Committer: Damon Fenacci
In-Reply-To: <SJ2PR10MB76698C19345A05B625BF2658A21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <0759331b-87d8-413d-82db-ff0ae2b5b090@oracle.com>
 <SJ2PR10MB76698C19345A05B625BF2658A21AA@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <c589e3dc-9d3d-42fa-93aa-57e31cc2007f@gmail.com>

Vote:? yes


Best Regards


On 9/30/2025 6:44 PM, Chen Liang wrote:
> Vote: yes
>
> Chen Liang
> ------------------------------------------------------------------------
> *From:* valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of 
> Tobias Hartmann <tobias.hartmann at oracle.com>
> *Sent:* Tuesday, September 30, 2025 3:04 AM
> *To:* valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
> *Cc:* Damon Fenacci <damon.fenacci at oracle.com>
> *Subject:* CFV: New Valhalla Committer: Damon Fenacci
> I hereby nominate Damon Fenacci [1] to Valhalla Committer.
>
> Marc is a member of the JVM Compiler Team at Oracle. He contributed 36 
> changes to the JDK project [2] and 7 changes to the Valhalla project [3].
>
> Votes are due by October 14, 2025, 08:00 UTC.
>
> Only current Valhalla Committers [4] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing 
> list.
>
> For Lazy Consensus voting instructions, see [5].
>
> Best regards,
> Tobias
>
> [1] https://openjdk.org/census#dfenacci
> [2] 
> https://github.com/search?q=author-name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits 
> <https://github.com/search?q=author-name%3A%22Damon+Fenacci%22+repo%3Aopenjdk%2Fjdk&type=commits>
> [3] 
> https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20dfenacci%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251009/ced05e7c/attachment-0001.htm>

From vromero at openjdk.org  Thu Oct  9 10:46:42 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Oct 2025 10:46:42 GMT
Subject: [lworld] RFR: 8368795: [lworld] javac rejects assignments to
 components of array fields with initializers in the prologue
Message-ID: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>

still a work in progress

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

Commit messages:
 - test
 - bug in proxy generation
 - change variable name
 - 8368795: [lworld] javac rejects assignments to components of array fields with initializers in the prologue
 - Merge branch 'lworld' into JDK-8368795
 - Merge branch 'lworld' into JDK-8368795
 - updating test
 - Merge with lworld
 - Merge branch 'lworld' into JDK-8368795
 - 8368795: [lworld] javac rejects assignments to components of array fields with initializers in the prologue

Changes: https://git.openjdk.org/valhalla/pull/1664/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368795
  Stats: 143 lines in 3 files changed: 54 ins; 81 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1664.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1664/head:pull/1664

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

From vromero at openjdk.org  Thu Oct  9 10:46:43 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Oct 2025 10:46:43 GMT
Subject: [lworld] RFR: 8368795: [lworld] javac rejects assignments to
 components of array fields with initializers in the prologue
In-Reply-To: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
References: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
Message-ID: <RwpA7019yRHd7dazFhAoCoTLUq38UzphTXf93Gn5T80=.d1eaf5c3-5eb0-4b79-b16b-689403df272e@github.com>

On Mon, 6 Oct 2025 16:01:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> still a work in progress

test

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

PR Comment: https://git.openjdk.org/valhalla/pull/1664#issuecomment-3383724365

From liach at openjdk.org  Thu Oct  9 10:46:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 Oct 2025 10:46:44 GMT
Subject: [lworld] RFR: 8368795: [lworld] javac rejects assignments to
 components of array fields with initializers in the prologue
In-Reply-To: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
References: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
Message-ID: <W9FPul5wp3wtwLWyv6CyizC2Ho7ahcORt7v8RCFGUJI=.5ba0f91d-deec-4cd6-b02f-a51f910a84e8@github.com>

On Mon, 6 Oct 2025 16:01:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> still a work in progress

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

> 1361:         @Override
> 1362:         public void visitIndexed(JCArrayAccess tree) {
> 1363:             boolean previewIsIndexed = isIndexed;

Do you mean `previousIsIndexed`?

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

> 1449:                     // Field may not have an initializer
> 1450:                     if ((sym.flags() & HASINIT) != 0) {
> 1451:                         if (!sym.type.hasTag(ARRAY) || !isIndexed) {

Does this work for complex ones like `(this.a = stuff)[b] = 5`?

Maybe we can try updating `isInLHS` to point to a JCTree and all the tests to be something like `tree == isInLHS` so this just won't run for array indexed trees?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1664#discussion_r2408645969
PR Review Comment: https://git.openjdk.org/valhalla/pull/1664#discussion_r2408677604

From vromero at openjdk.org  Thu Oct  9 11:20:30 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Oct 2025 11:20:30 GMT
Subject: [lworld] RFR: 8368795: [lworld] javac rejects assignments to
 components of array fields with initializers in the prologue
In-Reply-To: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
References: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
Message-ID: <fHTFwB7FJMLQTti8EEpn-LWodrCP5XoV2slNfXmhofk=.50bdffa6-0657-49a9-bfd2-def93262d8a2@github.com>

On Mon, 6 Oct 2025 16:01:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> still a work in progress

tier1-3 tests are passing

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

PR Comment: https://git.openjdk.org/valhalla/pull/1664#issuecomment-3385385298

From vromero at openjdk.org  Thu Oct  9 11:20:31 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Oct 2025 11:20:31 GMT
Subject: [lworld] RFR: 8368795: [lworld] javac rejects assignments to
 components of array fields with initializers in the prologue
In-Reply-To: <W9FPul5wp3wtwLWyv6CyizC2Ho7ahcORt7v8RCFGUJI=.5ba0f91d-deec-4cd6-b02f-a51f910a84e8@github.com>
References: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
 <W9FPul5wp3wtwLWyv6CyizC2Ho7ahcORt7v8RCFGUJI=.5ba0f91d-deec-4cd6-b02f-a51f910a84e8@github.com>
Message-ID: <8Xr7rMPHqHU_FOJLIohJT9NEMNRIl3uwQvTqUOn78So=.94f86e2e-1bb9-4a40-9adc-d5549b79e0ff@github.com>

On Mon, 6 Oct 2025 21:30:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> still a work in progress
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1451:
> 
>> 1449:                     // Field may not have an initializer
>> 1450:                     if ((sym.flags() & HASINIT) != 0) {
>> 1451:                         if (!sym.type.hasTag(ARRAY) || !isIndexed) {
> 
> Does this work for complex ones like `(this.a = stuff)[b] = 5`?
> 
> Maybe we can try updating `isInLHS` to point to a JCTree and all the tests to be something like `tree == isInLHS` so this just won't run for array indexed trees?

at least this test case is handled correctly, it could be that other cases won't be treated properly but we would need a test case

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1664#discussion_r2416436916

From liach at openjdk.org  Thu Oct  9 11:55:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 Oct 2025 11:55:31 GMT
Subject: [lworld] RFR: 8368795: [lworld] javac rejects assignments to
 components of array fields with initializers in the prologue
In-Reply-To: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
References: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
Message-ID: <tSQOl9WPGLpn1mfDAuHDM-TVZya5y1jyvRkisjTeh2w=.4b2d4891-e3fa-41c3-b0c4-ecf8afde6cb7@github.com>

On Mon, 6 Oct 2025 16:01:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> there are some cases for which a proxy variable should be generated by javac but it is not. When this happens, the generated class won't pass the verifier. Setting an array component in the prologue is one of those cases but also assigning to a field of an instance field like:
> 
> value class Test {
>     static class Foo { 
>         int x;
>     }
>     private final Foo data = new Foo();
>     Test() {
>         data.x = 12;
>         super();
>     }
> }

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1664#pullrequestreview-3318593157

From vromero at openjdk.org  Thu Oct  9 13:22:36 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Oct 2025 13:22:36 GMT
Subject: [lworld] Integrated: 8368795: [lworld] javac rejects assignments to
 components of array fields with initializers in the prologue
In-Reply-To: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
References: <IYuIu-xCTPdsJLu9xJG_dGLamJmCpp3dkZ-Ui6K2u8M=.1cc20ca8-9671-40c0-a15c-35d7d4eae8d6@github.com>
Message-ID: <0CP4uYZJxXtnnfUA4Yy0hTUsESJbXdEGHZCVSTCZOF8=.ee810936-a9fa-43c3-a5b0-9a2039db00c0@github.com>

On Mon, 6 Oct 2025 16:01:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> there are some cases for which a proxy variable should be generated by javac but it is not. When this happens, the generated class won't pass the verifier. Setting an array component in the prologue is one of those cases but also assigning to a field of an instance field like:
> 
> value class Test {
>     static class Foo { 
>         int x;
>     }
>     private final Foo data = new Foo();
>     Test() {
>         data.x = 12;
>         super();
>     }
> }

This pull request has now been integrated.

Changeset: dd39de49
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/dd39de49a52a93d811206b5d3c369de47fffc464
Stats:     143 lines in 3 files changed: 54 ins; 81 del; 8 mod

8368795: [lworld] javac rejects assignments to components of array fields with initializers in the prologue

Reviewed-by: liach

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

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

From dsimms at openjdk.org  Thu Oct  9 14:56:34 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 9 Oct 2025 14:56:34 GMT
Subject: [lworld] RFR: DEFAULT_PROMOTED_VERSION_PRE=jep401ea2
Message-ID: <UOWfYSQoSbJewoDYEQY7wiTCRz2QfVY7HQgEWWDij9c=.21547cbf-3e1d-4a9b-a54e-24e166fa4538@github.com>

Version name

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

Commit messages:
 - DEFAULT_PROMOTED_VERSION_PRE=jep401ea2

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

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

From matsaave at openjdk.org  Thu Oct  9 15:24:55 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Oct 2025 15:24:55 GMT
Subject: git: openjdk/valhalla: lworld: 8369446: [lworld] Problem list
 LoggingDeadlock2
Message-ID: <b6a1cead-88e8-490a-bae6-f7e09577f630@openjdk.org>

Changeset: 693a5073
Branch: lworld
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2025-10-09 15:24:24 +0000
URL:       https://git.openjdk.org/valhalla/commit/693a5073449e6512ab13d05acc785ea50ddacbab

8369446: [lworld] Problem list LoggingDeadlock2

! test/jdk/ProblemList.txt


From matsaave at openjdk.org  Thu Oct  9 15:27:12 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Oct 2025 15:27:12 GMT
Subject: [lworld] Integrated: 8369446: [lworld] Problem list LoggingDeadlock2
In-Reply-To: <9EoBRBBKe3jvbPhiQf62rym3yrCSkaskyJJ8n6bnxPg=.1b832f03-91d9-4b84-976a-191d96775fc5@github.com>
References: <9EoBRBBKe3jvbPhiQf62rym3yrCSkaskyJJ8n6bnxPg=.1b832f03-91d9-4b84-976a-191d96775fc5@github.com>
Message-ID: <cVOVqN4AGBephbjfPOeAdi6KJMEdWxjTJ9-zsbWQ3DQ=.487bd149-ed08-4812-ad46-bec9a18a08ec@github.com>

On Wed, 8 Oct 2025 17:06:50 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This test fails with -XX:AOTClassLinking but the failure should no longer occur after upstreaming [JDK-8364929](https://bugs.openjdk.org/browse/JDK-8364929). This test should be problem listed for now.

This pull request has now been integrated.

Changeset: 693a5073
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/693a5073449e6512ab13d05acc785ea50ddacbab
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8369446: [lworld] Problem list LoggingDeadlock2

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

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

From rriggs at openjdk.org  Thu Oct  9 20:08:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Oct 2025 20:08:29 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <ZwJOK9d6uUxsIiow5ML_-scXFaJHrlcoeCbfsaGCe0U=.7639d8b2-a3f8-4777-a104-0ea77edc8ecb@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <STcHR1GN0xmHp6VdRSx8z6N8GSslssb2TXqU9jr73Z8=.665dfa6d-a006-45ca-a226-1dc54d95bbf2@github.com>
 <ZwJOK9d6uUxsIiow5ML_-scXFaJHrlcoeCbfsaGCe0U=.7639d8b2-a3f8-4777-a104-0ea77edc8ecb@github.com>
Message-ID: <5nrgSGmjdx4kF9E1Va1vGmA6l5ECmtZaCI4V11HeEIU=.bf1f05fa-009a-4aa3-8040-fc4f0793833d@github.com>

On Wed, 8 Oct 2025 11:35:15 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/native/libjimage/imageFile.hpp line 253:
>> 
>>> 251:         // Set on a "normal" (non-preview) location if a preview version of
>>> 252:         // it exists in the same module.
>>> 253:         FLAGS_HAS_PREVIEW_VERSION = 0x1,
>> 
>> To avoid confusion, the value and spelling of the flag should agree across all modules.
>> In ImageLocation and jimage/ModulesReference.
>
> ModulesReference are different flags, with different semantics. That's why I made sure they were private and provided helper methods for reading/writing the package directory offsets (because I did trip over using the wrong constants at one point).
> 
> I agree it's weird/annoying to have this similar-but-different set of flags, but the ModuleReference flags are completely encapsulated in one place, so cannot be accidentally confused with, or misused in place of the ImageLocation flags.
> 
> These flags have a requirement of being zero for almost all entries to reduce image file size, while the ModulesReference flags need to additive for merging (and are not stored in the same part of the jimage file).
> 
> I could change flag ordering to make the values of the "has preview version" flags match, but since these sets of flags must never be mistaken for each other, I'm not sure that's beneficial (if anything it might foster the idea that they can be used interchangeably in some way).

If they have the same spelling, they will cause confusion if they have different semantics and usages.
All of imageFile, jimage, and the file system provider and classloader are in a single scope of operation.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2417809579

From rriggs at openjdk.org  Thu Oct  9 20:08:32 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Oct 2025 20:08:32 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
Message-ID: <bxP9Kn1AdoiFnrY7lIp2thk9KZwmNNKlZs_5E5EleKQ=.ac2b3e2e-3290-4d21-a404-bf772f242a45@github.com>

On Tue, 23 Sep 2025 19:11:41 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

src/java.base/share/native/libjimage/jimage.cpp line 114:

> 112:     size_t preview_infix_len = strlen(preview_infix);
> 113: 
> 114:     // TBD:   assert(module_name_len > 0 && "module name must be non-empty");

TBD: is obsolete?

src/java.base/share/native/libjimage/jimage.cpp line 157:

> 155:     // No preview flags means "a normal resource, without a preview version".
> 156:     // This is the overwhelmingly common case, with or without preview mode.
> 157:     if (flags == 0) {

Should test for defined flags, ignoring bits outside of the defined bits.

src/java.base/share/native/libjimage/jimage.cpp line 164:

> 162:     if ((flags & ImageLocation::FLAGS_IS_PREVIEW_VERSION) != 0) {
> 163:         return 0L;
> 164:     }

How can this occur?
classloader is the only client and does not pass arbitrary paths.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2417788703
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2417795963
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2417791849

From duke at openjdk.org  Thu Oct  9 20:08:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 9 Oct 2025 20:08:32 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <bxP9Kn1AdoiFnrY7lIp2thk9KZwmNNKlZs_5E5EleKQ=.ac2b3e2e-3290-4d21-a404-bf772f242a45@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <bxP9Kn1AdoiFnrY7lIp2thk9KZwmNNKlZs_5E5EleKQ=.ac2b3e2e-3290-4d21-a404-bf772f242a45@github.com>
Message-ID: <51Vshpfe07kULcYbJzbGPjnl2GHdE11pPpFEqtyUUNg=.1e5ed0e4-e922-4512-a980-6e1d4fba9f33@github.com>

On Thu, 9 Oct 2025 19:41:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> src/java.base/share/native/libjimage/jimage.cpp line 114:
> 
>> 112:     size_t preview_infix_len = strlen(preview_infix);
>> 113: 
>> 114:     // TBD:   assert(module_name_len > 0 && "module name must be non-empty");
> 
> TBD: is obsolete?

I don't use multiple white-space, so this wasn't me. It's just line 113 in the old code moved.
I don't know enough to change it confidently.

> src/java.base/share/native/libjimage/jimage.cpp line 157:
> 
>> 155:     // No preview flags means "a normal resource, without a preview version".
>> 156:     // This is the overwhelmingly common case, with or without preview mode.
>> 157:     if (flags == 0) {
> 
> Should test for defined flags, ignoring bits outside of the defined bits.

No, this really needs to be zero in this case, because otherwise it will be adding a lot of space to the jimage file for all the attributes that need to be encoded.

> src/java.base/share/native/libjimage/jimage.cpp line 164:
> 
>> 162:     if ((flags & ImageLocation::FLAGS_IS_PREVIEW_VERSION) != 0) {
>> 163:         return 0L;
>> 164:     }
> 
> How can this occur?
> classloader is the only client and does not pass arbitrary paths.

Hopefully it can't, but I'm not taking chances.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2417833779
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2417836907
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2417831468

From duke at openjdk.org  Thu Oct  9 20:14:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 9 Oct 2025 20:14:40 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <5nrgSGmjdx4kF9E1Va1vGmA6l5ECmtZaCI4V11HeEIU=.bf1f05fa-009a-4aa3-8040-fc4f0793833d@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <STcHR1GN0xmHp6VdRSx8z6N8GSslssb2TXqU9jr73Z8=.665dfa6d-a006-45ca-a226-1dc54d95bbf2@github.com>
 <ZwJOK9d6uUxsIiow5ML_-scXFaJHrlcoeCbfsaGCe0U=.7639d8b2-a3f8-4777-a104-0ea77edc8ecb@github.com>
 <5nrgSGmjdx4kF9E1Va1vGmA6l5ECmtZaCI4V11HeEIU=.bf1f05fa-009a-4aa3-8040-fc4f0793833d@github.com>
Message-ID: <RTqKteTDfEgzcbdNKI7lXCi6UpoUrAmVxPP3qrX_ZaY=.0bf55508-658c-4ae8-a106-93f3110dfcc0@github.com>

On Thu, 9 Oct 2025 19:51:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ModulesReference are different flags, with different semantics. That's why I made sure they were private and provided helper methods for reading/writing the package directory offsets (because I did trip over using the wrong constants at one point).
>> 
>> I agree it's weird/annoying to have this similar-but-different set of flags, but the ModuleReference flags are completely encapsulated in one place, so cannot be accidentally confused with, or misused in place of the ImageLocation flags.
>> 
>> These flags have a requirement of being zero for almost all entries to reduce image file size, while the ModulesReference flags need to additive for merging (and are not stored in the same part of the jimage file).
>> 
>> I could change flag ordering to make the values of the "has preview version" flags match, but since these sets of flags must never be mistaken for each other, I'm not sure that's beneficial (if anything it might foster the idea that they can be used interchangeably in some way).
>
> If they have the same spelling, they will cause confusion if they have different semantics and usages.
> All of imageFile, jimage, and the file system provider and classloader are in a single scope of operation.

I've done this now (but I don't really agree with the argument that it will be likely to cause confusion however, since the flags are stored in different data structures and their use is carefully encapsulated).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2417850049

From dsimms at openjdk.org  Fri Oct 10 07:36:33 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 10 Oct 2025 07:36:33 GMT
Subject: [lworld] Integrated: DEFAULT_PROMOTED_VERSION_PRE=jep401ea2
In-Reply-To: <UOWfYSQoSbJewoDYEQY7wiTCRz2QfVY7HQgEWWDij9c=.21547cbf-3e1d-4a9b-a54e-24e166fa4538@github.com>
References: <UOWfYSQoSbJewoDYEQY7wiTCRz2QfVY7HQgEWWDij9c=.21547cbf-3e1d-4a9b-a54e-24e166fa4538@github.com>
Message-ID: <v4syxo4H1rEwY2fytOcoTr-KQYFdXksA4qrtZujnZ9A=.55e0108e-6555-4f84-abef-2b747932fff2@github.com>

On Thu, 9 Oct 2025 14:51:40 GMT, David Simms <dsimms at openjdk.org> wrote:

> Version name

This pull request has now been integrated.

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

DEFAULT_PROMOTED_VERSION_PRE=jep401ea2

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

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

From dsimms at openjdk.org  Fri Oct 10 07:59:33 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 10 Oct 2025 07:59:33 GMT
Subject: Integrated: Version flick
In-Reply-To: <w-0poiGz13u_cQX4npSMoSjptr2ZTbC3Oq2Q3e8Au_s=.a3e2eb96-1dfb-4057-8484-745620eebe3e@github.com>
References: <w-0poiGz13u_cQX4npSMoSjptr2ZTbC3Oq2Q3e8Au_s=.a3e2eb96-1dfb-4057-8484-745620eebe3e@github.com>
Message-ID: <bprfHRm97mnvjqGZrjS2T4taD1qs1M8NFkwhMJbR_x8=.f14c523a-5f93-41ad-aa34-627da4c46299@github.com>

On Fri, 10 Oct 2025 07:48:37 GMT, David Simms <dsimms at openjdk.org> wrote:

> DEFAULT_PROMOTED_VERSION_PRE=jep401ea2

This pull request has now been integrated.

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

Version flick

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

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

From dsimms at openjdk.org  Fri Oct 10 07:55:48 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 10 Oct 2025 07:55:48 GMT
Subject: RFR: Version flick
Message-ID: <w-0poiGz13u_cQX4npSMoSjptr2ZTbC3Oq2Q3e8Au_s=.a3e2eb96-1dfb-4057-8484-745620eebe3e@github.com>

DEFAULT_PROMOTED_VERSION_PRE=jep401ea2

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

Commit messages:
 - DEFAULT_PROMOTED_VERSION_PRE=jep401ea2

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

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

From phubner at openjdk.org  Fri Oct 10 08:57:30 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 10 Oct 2025 08:57:30 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
Message-ID: <ie5dyd8MJpdLX1kPAE0RSWR8Cr69CWMXysnqowUXUnI=.98109f33-8abe-42c0-bed0-902faca61bd9@github.com>

On Tue, 23 Sep 2025 19:11:41 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

src/hotspot/share/runtime/arguments.cpp line 2088:

> 2086: 
> 2087: bool Arguments::disable_preview_patching() {
> 2088:   const char* prop = get_property("DISABLE_PREVIEW_PATCHING");

Nitpick, feel free to ignore, esp. since this is temporary. I think it would make the code easier to follow if this was enable preview patching, defaulting to true. It stands in contrast to`EnableValhalla` and `enable_preview()`. But as said, not a huge thing.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2418984976

From phubner at openjdk.org  Fri Oct 10 09:03:39 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 10 Oct 2025 09:03:39 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
Message-ID: <jsNkOM3fo_wpmTYmptw8Uz6em8Eivg5yL-U3pl-Txfo=.2b503661-730d-427c-a7c2-cfee634b2a93@github.com>

On Tue, 23 Sep 2025 19:11:41 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

Disclaimer: I can only speak for the runtime portions of the code.

src/hotspot/share/classfile/classLoader.cpp line 251:

> 249: // Closes and clears the JImage file reference (this will only be called during shutdown).
> 250: static void jimage_close() {
> 251:   if (JImage_file != nullptr) {

I'm not familiar with jimage at all, is there as reason we could close a non-open jimage? And following from that, can we guarantee to not call jimage_open on an open jimage? (Maybe an assert should guard it?)

src/hotspot/share/classfile/classLoader.cpp line 291:

> 289: // the preview mode to be manually specified, so must not be accessible outside this
> 290: // class. ClassPathImageEntry manages all calls for resources after startup is complete.
> 291: static JImageLocationRef jimage_find_resource(const char* module_name,

This function makes the rest of the code more legible. Thanks!

src/java.base/share/native/libjimage/imageFile.cpp line 326:

> 324:         // for preview mode. Preview mode changes do not modify any structure,
> 325:         // so a 1.0 file will look like a jimage without any preview resources.
> 326:         // TODO: Restore equality check for MINOR_VERSION.

Is this something you still have to address in this PR?

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1618#pullrequestreview-3322083982
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2418991622
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2418995309
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2418997876

From mhaessig at openjdk.org  Fri Oct 10 09:32:16 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 10 Oct 2025 09:32:16 GMT
Subject: [lworld] RFR: 8369532: [lworld] Increase compilation memory limit for
 TestValueConstruction.java
Message-ID: <6UhG1bqKRdT_Ix7hFSrp2vXpHM_n0rQcDmGG6_dZaGw=.1668cb72-7134-41b0-b7e1-f6a0f097d667@github.com>

This PR increases the compilation memory limit for subtasks of TestValueConstruction.java, which oom during JIT compilation in the CI, to 2G while I am working on a more fundamental fix. The new limit and its sparse application is so that the CI still detects further regressions, so this is preferable to a full problem list.

Testing:
 - [x] repeatedly run failing configurations with a 2G memory limit.

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

Commit messages:
 - Increase MemLimit for a subset of TestValueConstruction

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

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

From thartmann at openjdk.org  Fri Oct 10 09:32:17 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 10 Oct 2025 09:32:17 GMT
Subject: [lworld] RFR: 8369532: [lworld] Increase compilation memory limit
 for TestValueConstruction.java
In-Reply-To: <6UhG1bqKRdT_Ix7hFSrp2vXpHM_n0rQcDmGG6_dZaGw=.1668cb72-7134-41b0-b7e1-f6a0f097d667@github.com>
References: <6UhG1bqKRdT_Ix7hFSrp2vXpHM_n0rQcDmGG6_dZaGw=.1668cb72-7134-41b0-b7e1-f6a0f097d667@github.com>
Message-ID: <WQ-Y9DE2hhHK3rddHY6W0UmzN1-6muUuoeh5r8g_D1E=.b47ad1b2-3710-47ea-9ba2-e3e94e4c99d1@github.com>

On Fri, 10 Oct 2025 09:25:33 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR increases the compilation memory limit for subtasks of TestValueConstruction.java, which oom during JIT compilation in the CI, to 2G while I am working on a more fundamental fix. The new limit and its sparse application is so that the CI still detects further regressions, so this is preferable to a full problem list.
> 
> Testing:
>  - [x] repeatedly run failing configurations with a 2G memory limit.

Looks good and trivial!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1673#pullrequestreview-3322187013

From duke at openjdk.org  Fri Oct 10 10:20:22 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 10 Oct 2025 10:20:22 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <jsNkOM3fo_wpmTYmptw8Uz6em8Eivg5yL-U3pl-Txfo=.2b503661-730d-427c-a7c2-cfee634b2a93@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <jsNkOM3fo_wpmTYmptw8Uz6em8Eivg5yL-U3pl-Txfo=.2b503661-730d-427c-a7c2-cfee634b2a93@github.com>
Message-ID: <opnLu7tLA3d_hsOOhpSP3F5JLX_hZqLtPxBjUPb9YRE=.8d6d48c2-2822-4bca-a886-8385bf63f45d@github.com>

On Fri, 10 Oct 2025 08:56:59 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> src/hotspot/share/classfile/classLoader.cpp line 251:
> 
>> 249: // Closes and clears the JImage file reference (this will only be called during shutdown).
>> 250: static void jimage_close() {
>> 251:   if (JImage_file != nullptr) {
> 
> I'm not familiar with jimage at all, is there as reason we could close a non-open jimage? And following from that, can we guarantee to not call jimage_open on an open jimage? (Maybe an assert should guard it?)

I honestly don't know, so this is the old behaviour, so I'm keeping it for now.
Alan might know more.

> src/java.base/share/native/libjimage/imageFile.cpp line 326:
> 
>> 324:         // for preview mode. Preview mode changes do not modify any structure,
>> 325:         // so a 1.0 file will look like a jimage without any preview resources.
>> 326:         // TODO: Restore equality check for MINOR_VERSION.
> 
> Is this something you still have to address in this PR?

I need to address it later, when the image writing code is changed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2419241260
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2419235251

From duke at openjdk.org  Fri Oct 10 10:23:23 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 10 Oct 2025 10:23:23 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <ie5dyd8MJpdLX1kPAE0RSWR8Cr69CWMXysnqowUXUnI=.98109f33-8abe-42c0-bed0-902faca61bd9@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ie5dyd8MJpdLX1kPAE0RSWR8Cr69CWMXysnqowUXUnI=.98109f33-8abe-42c0-bed0-902faca61bd9@github.com>
Message-ID: <tZssz40mv83DniBMdZk8pa5zxRPIThl-Y0DKTIGV3_s=.77faff02-c9b2-4e23-a26c-f35bc29ad83e@github.com>

On Fri, 10 Oct 2025 08:54:21 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> src/hotspot/share/runtime/arguments.cpp line 2088:
> 
>> 2086: 
>> 2087: bool Arguments::disable_preview_patching() {
>> 2088:   const char* prop = get_property("DISABLE_PREVIEW_PATCHING");
> 
> Nitpick, feel free to ignore, esp. since this is temporary. I think it would make the code easier to follow if this was enable preview patching, defaulting to true. It stands in contrast to`EnableValhalla` and `enable_preview()`. But as said, not a huge thing.

The naming was Roger's, I'm mostly happy with anything really if it's temporary.

I have a similar preference for positive naming ("enable" rather than "disable") to avoid double negatives, but in this case it's probably more work to do that (since it'll cause a rebase of 3 other PRs in progress) than just live with it for a few weeks.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2419257085

From duke at openjdk.org  Fri Oct 10 11:04:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 10 Oct 2025 11:04:40 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v4]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <RcpmoQhwPkPptPeEb47PA5AlA1E2qhjEG1-b6BJqi2U=.09a06ab0-826c-434b-ac6b-9428175bc498@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Resync after dependent PR change.
   
   * new tests for ImageLocation
   * Restoring lost changes and updating some comments.
   * add system property guard to preview mode
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Merge branch 'jdk_8368333_java/squashed' into temp_reader
 - Removing package root flag based on feedback.
 - [[RESET BRANCH FOR MERGE]]
 - Restoring lost changes and updating some comments.
 - add system property guard to preview mode
 - jimage writer changes to support preview mode.
   
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.

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

Changes: https://git.openjdk.org/valhalla/pull/1621/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=03
  Stats: 2042 lines in 14 files changed: 888 ins; 150 del; 1004 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

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

From duke at openjdk.org  Fri Oct 10 11:33:20 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 10 Oct 2025 11:33:20 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v5]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <Zi5iRUXONrboee8eu0o7hzNxd2rEkD8o4Fp-UZdRUsE=.a7d4456c-e98a-4d58-8ed1-3754e52f5907@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

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

  feedback and remove unused code

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1621/files
  - new: https://git.openjdk.org/valhalla/pull/1621/files/5da51973..7b53a721

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

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

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

From duke at openjdk.org  Fri Oct 10 11:33:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 10 Oct 2025 11:33:21 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v5]
In-Reply-To: <Zi5iRUXONrboee8eu0o7hzNxd2rEkD8o4Fp-UZdRUsE=.a7d4456c-e98a-4d58-8ed1-3754e52f5907@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
 <Zi5iRUXONrboee8eu0o7hzNxd2rEkD8o4Fp-UZdRUsE=.a7d4456c-e98a-4d58-8ed1-3754e52f5907@github.com>
Message-ID: <CJ0nv4s6WDsPWq4Rn2M47poBmpna9oi-cinzS0BB_Hw=.ca31f2d3-22f3-4545-8df6-f4f33d88718a@github.com>

On Fri, 10 Oct 2025 11:30:19 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>> 
>> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback and remove unused code

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/BasicImageWriter.java line 39:

> 37:     public static final String MODULES_IMAGE_NAME = "modules";
> 38: 
> 39:     private final ByteOrder byteOrder;

Made obvious fields final and removed unused, non-public, code.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2419590040

From mhaessig at openjdk.org  Fri Oct 10 12:15:56 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 10 Oct 2025 12:15:56 GMT
Subject: [lworld] RFR: 8369532: [lworld] Increase compilation memory limit
 for TestValueConstruction.java
In-Reply-To: <WQ-Y9DE2hhHK3rddHY6W0UmzN1-6muUuoeh5r8g_D1E=.b47ad1b2-3710-47ea-9ba2-e3e94e4c99d1@github.com>
References: <6UhG1bqKRdT_Ix7hFSrp2vXpHM_n0rQcDmGG6_dZaGw=.1668cb72-7134-41b0-b7e1-f6a0f097d667@github.com>
 <WQ-Y9DE2hhHK3rddHY6W0UmzN1-6muUuoeh5r8g_D1E=.b47ad1b2-3710-47ea-9ba2-e3e94e4c99d1@github.com>
Message-ID: <iDO0HB2WfIgV_3PxU8HyEnuywZe7-9AmVYthsar8Cys=.551dc43a-75e6-40c3-8829-1605b38b8fb9@github.com>

On Fri, 10 Oct 2025 09:27:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This PR increases the compilation memory limit for subtasks of TestValueConstruction.java, which oom during JIT compilation in the CI, to 2G while I am working on a more fundamental fix. The new limit and its sparse application is so that the CI still detects further regressions, so this is preferable to a full problem list.
>> 
>> Testing:
>>  - [x] repeatedly run failing configurations with a 2G memory limit.
>
> Looks good and trivial!

Thank you for your review, @TobiHartmann!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1673#issuecomment-3389766951

From duke at openjdk.org  Fri Oct 10 12:18:08 2025
From: duke at openjdk.org (duke)
Date: Fri, 10 Oct 2025 12:18:08 GMT
Subject: [lworld] RFR: 8369532: [lworld] Increase compilation memory limit
 for TestValueConstruction.java
In-Reply-To: <6UhG1bqKRdT_Ix7hFSrp2vXpHM_n0rQcDmGG6_dZaGw=.1668cb72-7134-41b0-b7e1-f6a0f097d667@github.com>
References: <6UhG1bqKRdT_Ix7hFSrp2vXpHM_n0rQcDmGG6_dZaGw=.1668cb72-7134-41b0-b7e1-f6a0f097d667@github.com>
Message-ID: <Ey4yt8kg6d-0hqovZxoJVoG07FvBRowDHtnPX7HYdnk=.8cd939bd-2987-40a3-9d62-1038d262a984@github.com>

On Fri, 10 Oct 2025 09:25:33 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR increases the compilation memory limit for subtasks of TestValueConstruction.java, which oom during JIT compilation in the CI, to 2G while I am working on a more fundamental fix. The new limit and its sparse application is so that the CI still detects further regressions, so this is preferable to a full problem list.
> 
> Testing:
>  - [x] repeatedly run failing configurations with a 2G memory limit.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1673#issuecomment-3389776335

From mhaessig at openjdk.org  Fri Oct 10 12:35:35 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 10 Oct 2025 12:35:35 GMT
Subject: [lworld] Integrated: 8369532: [lworld] Increase compilation memory
 limit for TestValueConstruction.java
In-Reply-To: <6UhG1bqKRdT_Ix7hFSrp2vXpHM_n0rQcDmGG6_dZaGw=.1668cb72-7134-41b0-b7e1-f6a0f097d667@github.com>
References: <6UhG1bqKRdT_Ix7hFSrp2vXpHM_n0rQcDmGG6_dZaGw=.1668cb72-7134-41b0-b7e1-f6a0f097d667@github.com>
Message-ID: <3-gUEZ-jqS0zo3Tu6UUuXjUyCvmV6oodn5_IALc3_OY=.477d3146-ab70-4d3e-aae1-a081d31d3f09@github.com>

On Fri, 10 Oct 2025 09:25:33 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> This PR increases the compilation memory limit for subtasks of TestValueConstruction.java, which oom during JIT compilation in the CI, to 2G while I am working on a more fundamental fix. The new limit and its sparse application is so that the CI still detects further regressions, so this is preferable to a full problem list.
> 
> Testing:
>  - [x] repeatedly run failing configurations with a 2G memory limit.

This pull request has now been integrated.

Changeset: 99f28f59
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/99f28f596693f078c535f5df40b8da6f31148f86
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8369532: [lworld] Increase compilation memory limit for TestValueConstruction.java

Reviewed-by: thartmann

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

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

From jbhateja at openjdk.org  Fri Oct 10 19:45:38 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 10 Oct 2025 19:45:38 GMT
Subject: [lworld] RFR: 8367792: [lworld] Remove the Unsafe remnants of old
 valhalla prototypes
In-Reply-To: <rcxiIhT-6gFMB_vBrh1t03Vwn8xJ_xC30-nc2dBvxck=.4d9f2802-388a-4dc1-8cdb-af240f1140c9@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
 <vnLmnwhpHnh7Wfmmo2TD4qJhDa4dnib4HIXhic3Fsyk=.d4be4aba-4914-4a73-8d21-429ae4e680ae@github.com>
 <CNKXxqFFrRpuApLzmIjDRUSqKNlpntUbmbQHwPnaqEM=.d9c12557-1b16-4d20-af03-e97b5fec8d16@github.com>
 <rcxiIhT-6gFMB_vBrh1t03Vwn8xJ_xC30-nc2dBvxck=.4d9f2802-388a-4dc1-8cdb-af240f1140c9@github.com>
Message-ID: <Ve_IGqeD1cX50IM4wS3Sce3wqmrtSo1K81PicePOmH0=.c5b96205-e7c4-4bbb-b683-3450457b5751@github.com>

On Fri, 26 Sep 2025 22:34:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi @liach , 
>> 
>> Currently, Unsafe.put* APIs expect to operate on a mutable value, without Unsafe.makePrivateBuffer, there is no way to transition a value object to larval state.
>> 
>> <img width="800" height="400" alt="image" src="https://github.com/user-attachments/assets/af826cda-55e1-4b0c-a2ea-62592f7623d6" />
>> 
>> 
>> Here is a typical update kernel for the nary operation fallback implementation. 
>> 
>> <img width="500" height="200" alt="image" src="https://github.com/user-attachments/assets/4a31baa7-52b8-4e0b-8c42-924407bb5665" />
>> 
>> 
>> 
>> **Here are some relevant FAQs on the need for multifield annotation.**
>> 
>> Q. Why do we need @multifield annotated field in VectorPayloads and not just retain the array-backed backing storage?
>> A.  Even currently, Vector instances are immutable, with each modification or application of an operation, a new vector is generated. 
>>       Each new vector has a distinct backing storage in the form of an array; thus, no two vector ever share their backing storage, which makes vectors an immutable quantity. 
>>       
>>      Vector<Float>  newVector  =  Vec1.lanewise(VectorOperators.ADD, Vec2);
>>      
>> Since arrays are always allocated over the heap, they carry an identity, which is the distinctive heap address for each new backing storage array.
>> 
>> This contradicts the philosophy of value type instances, which are identity-free; the compiler treats two values with the same contents as equivalent entities and is free to substitute one with another. 
>> 
>> By replacing existing array-backed storage with a @multifield annotated storage, we ensure that payload adheres to true value semantics, a @multifiled is seen as a bundle of fields, encapsulating payload is a value class, unlike an array, a multifield is never allocated an explicit heap storage. 
>> 
>> Here is an example code
>> 
>>  
>> <img width="400" height="500" alt="image" src="https://github.com/user-attachments/assets/14cb3fbc-15cf-461e-846e-b200f744f793" />
>> 
>> 
>> Even though Payload is a value class, its two instances with the same backing storage are not equal, because arrays have identity.
>> By treating vectors as value objects, we expect that two vectors with the same contents should be equal.
>> 
>> Q.  Is there any alternative to @multifield?
>> A.  All we need to ensure is that the backing storage has no identity.  Thus, we could have multiple primitive type fields in the payload, one for each lane of the vector. 
>> 
>>  
>> <img width="450" height="310" al...
>
> Hi @jatin-bhateja, as I know, the larval bit is completely unused in current Valhalla - I believe what we should do with that assert is to simply remove it. I am thinking of some internal API that accepts a Consumer that handles the "early larval" API via unsafe before returning it.
> 
> I thought the merge of lworld into vector would be trivial, but it turned out troublesome - can you push the merge as soon as it is ready? I am more than happy to help you migrate off makePrivateBuffer and this to-be-removed larval bit.

Hi @liach ,

I am working on refereshing lworld+vector branch and also thinking through some post-merge improvements.
For record sake adding my notes in the comments.

post merge improvements:-
    - Replace VectorBox and VectorBoxAllocate nodes with InlineTypeNode.
    - New Ideal Transforms to sweep intermediate logic after inline expansion.
  
  Code snippet:-


Source:-
       vec1 = fromArray(SRC1)              - [1]
       vec2 = fromArray(SRC2)              - [2]
       res = vec1.lanewise(MUL,vec2)       - [3]
       res.intoArray(RES)                  - [4]


  Intermeridate Rerpresenation for [1][2]
       
       LoadVector 
          |
          v
       InlineTypeNode (VectorPayload)
          |
          v
       InlineTypeNode (Double256Vector)
          |
          v
       CastPP (NotNull) 
          |
          v
       CheckCastPP (Double256Vector)
        |
        v     
       [x] -> AddP -> LoadVector
        |                  |
        |                  v
        |             InlineTypeNode (VectorPayload)      [[[[ make_from_oop ]]]           
        |                  |
        | oop              v
        |-----------> InlineTypeNode (Double256Vector)
                           |
                           v
                          [y]


  Intermediate Represenation for [3]

           [y]         [y]
            |           |
            v           v
      VectorUnbox   VectorUnbox
            |         /
            |        /
            |       /
            |      /
            |     /                                                                                            
            |    /
            |   /
            [Mul]
              |
              v
        InlineTypeNode (VectorPayloadMF)
              |
              v
        InlineTypeNode (Double256Vector)
              |
              v
            CastPP
              |
              v
          CheckCastPP
              |
              v    
             [x] -> AddP -> LoadVector
              |                  |
              |                  v
              |             InlineTypeNode (VectorPayload)      [[[[ make_from_oop ]]]           
              |                  |
              | oop              v
              |-----------> InlineTypeNode (Double256Vector)
                                 |
                                 v
                                [y]
 
 Iintermediate Represenation for [4]

         [y]
          |
          v
    VectorUnboxNode
          |
          v
     StoreVector

New Transforms for boxing + unboxing optimizations :-
-------------------------------------------------------------

- Unboxing simply will simply be reduced to action of fetching correct VectorIR from its preceding input graph snippet.
- In context where boxing is needed we will bank process_inline_types node for bufferning 

   Q. Do we have sufficient infrastructure for lazy buffering during process_inline_types in down stream flow ?
   A. No, buffering is done upfront as it needs precise memory and control edges, currently, compiler performs eager buffering 
        in scenarios which mandates non-scalarized forms of value objects. i.e. non-flat field assignment or passing 
        value type arguments when InlineTypePassFieldsAsArgs is not set.
       
     Q. What if we do upfront buffering of InlineTypeNode corresponding to vector boxes ?
     A. A buffer and its associated InlineTypeNode must be in sync all the time. Any field update of a value object creates a new value. This can only be achieved through a new value instance allocation i.e. it must go through an intermediate larval state. All the fields of a value instance are final, thus we cannot use putfield to update their contents, getfield does return the initializing value of value instance field.
         
        MyValue (value type)
            - float f1;
            - float f2;
            - float f3;
            - float f4;

        val1 = new MyValue(0.0f, 1.0f, 2.0f, 3.0f);
            -->  new MyValue (oop)
                  |
                  --> make_from_oop(oop) post construction

        val2 = new MyValue(val1.f1, 2.0f, val1.f3, val1.f4)  // getfield val1.f1 will pass 0.0f
                  |                                          // getfield val1.f3 will pass 2.0f
                  |                                          // getfield val1.f4 will pass 3.0f
                  |                                          
                  --> make_from_oop(oop) post construction
                        
        return val2.f1 + val2.f2 ; will return 0.0f + 2.0f, thus there will be no consumer of InlineTypeNodes and they will be sweept 
        out along with their allocations. 

      Q. In new code model, an InlineTypeNode is always backed by an allocation ?
      A. An inline type node is created from initialized this pointer passes as Parma0 of constructor, unless its created through make_from_multi i.e. from scalarize arguments parameters. 


(gdb) l
889         if (cg->method()->is_object_constructor() && receiver != nullptr && gvn().type(receiver)->is_inlinetypeptr()) {
890           InlineTypeNode* non_larval = InlineTypeNode::make_from_oop(this, receiver, gvn().type(receiver)->inline_klass());
891           // Relinquish the oop input, we will delay the allocation to the point it is needed, see the
892           // comments in InlineTypeNode::Ideal for more details
893           non_larval = non_larval->clone_if_required(&gvn(), nullptr);
894           non_larval->set_oop(gvn(), null());
895           non_larval->set_is_buffered(gvn(), false);
896           non_larval = gvn().transform(non_larval)->as_InlineType();
897           map()->replace_edge(receiver, non_larval);
898         }


     
  [Aaction Item] 
        -Try to always link the backing oop to newly scalarized InlineTypeNode, since new code model always creates
          a new larval value on every field modification hence, oop and scalarized nodes are always in sync.

  [Results] 
         Working on stand alone tests, need to regress through performance and validation suite.
            - Functional validation is almost fine.
            - Also, most of the InlineTypeNode are sweeped out unless, there is any specific context which needs materialized
              value.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1593#issuecomment-3392084635

From phubner at openjdk.org  Mon Oct 13 07:04:16 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 13 Oct 2025 07:04:16 GMT
Subject: [lworld] RFR: 8369567: [lworld] Set jtreg timeout factor to 4
Message-ID: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>

Hi all,

To address many timeouts in the tests, we temporarily reset the timeout factor to 4 as mainline is doing.

Testing: tiers 1-3.

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

Commit messages:
 - Set timeout factor to 4.

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

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

From phubner at openjdk.org  Mon Oct 13 09:30:30 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 13 Oct 2025 09:30:30 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word [v3]
In-Reply-To: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
Message-ID: <7Na06zC67tt7CJtx-kTllnRjogeAz6rEiRDcRxryWVY=.0e23c0ec-8f88-45ff-afe0-5f491189bb12@github.com>

> Hi all, 
> 
> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
> 
> Specifically, there are three portions to this change:
> - Moving the age bits lower to their intended position.
> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
> 
> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

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

 - Merge branch 'lworld' into JDK-8367073
 - Remove unused prototype method.
 - Merge branch 'lworld' into JDK-8367073
 - Revise documentation.
 - Fix hashCode intrinsic miscompilation.
 - Fix outdated markWord test semantics.
 - Chuck out weird markWord code.
 - Emulate old Valhalla decode_pointer behavior.
 - Fix typo.
 - Follow JEP450 MarkWord specification.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1578/files
  - new: https://git.openjdk.org/valhalla/pull/1578/files/5b0b70ee..e0eaebf0

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

  Stats: 37184 lines in 1622 files changed: 24715 ins; 6880 del; 5589 mod
  Patch: https://git.openjdk.org/valhalla/pull/1578.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1578/head:pull/1578

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

From phubner at openjdk.org  Mon Oct 13 09:30:34 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 13 Oct 2025 09:30:34 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word [v2]
In-Reply-To: <c3Pnqcwv61vcfdEx1Sh6pebGYPdR9lpYsJnc61E55LE=.f4c2ec4f-949a-49b4-a2e1-042338719f00@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
 <c3Pnqcwv61vcfdEx1Sh6pebGYPdR9lpYsJnc61E55LE=.f4c2ec4f-949a-49b4-a2e1-042338719f00@github.com>
Message-ID: <dDt1zyx1loixrxZGPTbbRkLXMAlq2YDMCfpq7u7s5-g=.328fda5c-9e97-4ee0-9ab7-7d5ccccabc69@github.com>

On Thu, 2 Oct 2025 08:26:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
>> 
>> Specifically, there are three portions to this change:
>> - Moving the age bits lower to their intended position.
>> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
>> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
>> 
>> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Remove unused prototype method.
>  - Merge branch 'lworld' into JDK-8367073
>  - Revise documentation.
>  - Fix hashCode intrinsic miscompilation.
>  - Fix outdated markWord test semantics.
>  - Chuck out weird markWord code.
>  - Emulate old Valhalla decode_pointer behavior.
>  - Fix typo.
>  - Follow JEP450 MarkWord specification.

Hi all, I've merged in `84c7c0a2bf8e05d791058acb18f3d0f7032dabbd` and re-run all the tests. I saw no new failures or failures that could not be attributed to known issues. I would like re-approval to proceed with integration.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1578#issuecomment-3396606265

From chagedorn at openjdk.org  Mon Oct 13 10:30:41 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 13 Oct 2025 10:30:41 GMT
Subject: [lworld] RFR: 8369567: [lworld] Set jtreg timeout factor to 4
In-Reply-To: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>
References: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>
Message-ID: <N_kIeDFYkNgbVuV2HPN5MBiTgT38Ybq-wDYQREN34Z8=.47be8cf0-5a32-4f1e-b637-4ab8d75dcde6@github.com>

On Fri, 10 Oct 2025 13:47:58 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> To address many timeouts in the tests, we temporarily reset the timeout factor to 4 as mainline is doing.
> 
> Testing: tiers 1-3.

Looks good, thanks!

make/RunTests.gmk line 949:

> 947: 
> 948:   JTREG_AUTO_PROBLEM_LISTS :=
> 949:   # Please reach consensus before changing this. It was not easy changing it to a `1`.

Maybe also adjust this as proposed currently in mainline:

Suggestion:

  # Please reach consensus before changing this.

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1674#pullrequestreview-3330897632
PR Review Comment: https://git.openjdk.org/valhalla/pull/1674#discussion_r2425863610

From phubner at openjdk.org  Mon Oct 13 11:16:10 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 13 Oct 2025 11:16:10 GMT
Subject: [lworld] RFR: 8369567: [lworld] Set jtreg timeout factor to 4 [v2]
In-Reply-To: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>
References: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>
Message-ID: <cW9ksK7muNa_R6rb1qkox7yaiKYTqTXW1sOffSpF7AQ=.038e33c2-6e62-4000-aa9f-535271c4110f@github.com>

> Hi all,
> 
> To address many timeouts in the tests, we temporarily reset the timeout factor to 4 as mainline is doing.
> 
> Testing: tiers 1-3.

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

  Update make/RunTests.gmk
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1674/files
  - new: https://git.openjdk.org/valhalla/pull/1674/files/e43466fa..5f1f03f2

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

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

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

From duke at openjdk.org  Mon Oct 13 11:21:29 2025
From: duke at openjdk.org (duke)
Date: Mon, 13 Oct 2025 11:21:29 GMT
Subject: [lworld] RFR: 8369567: [lworld] Set jtreg timeout factor to 4 [v2]
In-Reply-To: <cW9ksK7muNa_R6rb1qkox7yaiKYTqTXW1sOffSpF7AQ=.038e33c2-6e62-4000-aa9f-535271c4110f@github.com>
References: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>
 <cW9ksK7muNa_R6rb1qkox7yaiKYTqTXW1sOffSpF7AQ=.038e33c2-6e62-4000-aa9f-535271c4110f@github.com>
Message-ID: <1lAlYIpObjIdAjn-mSS7zOPLYe_Nb9ebMvtwtJ0uXqc=.4364653d-c7d2-4d33-a234-a971c5d23bfd@github.com>

On Mon, 13 Oct 2025 11:16:10 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> To address many timeouts in the tests, we temporarily reset the timeout factor to 4 as mainline is doing.
>> 
>> Testing: tiers 1-3.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/RunTests.gmk
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

@Arraying 
Your change (at version 5f1f03f2ff75c6e0de4b79cbe8ca135f990cc58b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1674#issuecomment-3397085215

From liach at openjdk.org  Mon Oct 13 20:19:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 13 Oct 2025 20:19:31 GMT
Subject: [lworld] RFR: 8369567: [lworld] Set jtreg timeout factor to 4 [v2]
In-Reply-To: <cW9ksK7muNa_R6rb1qkox7yaiKYTqTXW1sOffSpF7AQ=.038e33c2-6e62-4000-aa9f-535271c4110f@github.com>
References: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>
 <cW9ksK7muNa_R6rb1qkox7yaiKYTqTXW1sOffSpF7AQ=.038e33c2-6e62-4000-aa9f-535271c4110f@github.com>
Message-ID: <UAXs8BTYJlaSJWiuB6XeHwvCO-zx4ELuk05mmN2qZdU=.0ad1d53c-a94d-47dc-a2e7-41bd207c7f28@github.com>

On Mon, 13 Oct 2025 11:16:10 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> To address many timeouts in the tests, we temporarily reset the timeout factor to 4 as mainline is doing.
>> 
>> Testing: tiers 1-3.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/RunTests.gmk
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

Should be safe since we have this in mainline too.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1674#issuecomment-3398928678

From phubner at openjdk.org  Mon Oct 13 20:19:33 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 13 Oct 2025 20:19:33 GMT
Subject: [lworld] Integrated: 8369567: [lworld] Set jtreg timeout factor to 4
In-Reply-To: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>
References: <8SUU4754VrGAD0DEaX-qGCvEkHM4pVymSQ9lexUgeoc=.4a071580-e5b8-4639-9323-6a270f104385@github.com>
Message-ID: <BXzH5y8J2_jRV9N0_OjzNI06N-MkEP4dZUX_cjGmbjc=.7d484bda-85e2-4f13-99c6-2ed06c3352d2@github.com>

On Fri, 10 Oct 2025 13:47:58 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> To address many timeouts in the tests, we temporarily reset the timeout factor to 4 as mainline is doing.
> 
> Testing: tiers 1-3.

This pull request has now been integrated.

Changeset: 849c84dd
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/849c84dde8d494a62ce9cc692598c5bea2ceaba2
Stats:     4 lines in 3 files changed: 0 ins; 0 del; 4 mod

8369567: [lworld] Set jtreg timeout factor to 4

Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Reviewed-by: chagedorn

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

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

From tobias.hartmann at oracle.com  Tue Oct 14 07:32:29 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Oct 2025 09:32:29 +0200
Subject: Result: New Valhalla Committer: Marc Chevalier
Message-ID: <36c1df66-f420-4395-9142-c4b6d75abcb0@oracle.com>

Voting [1] for Marc Chevalier [2] is now closed.

Yes: 8
Veto: 0
Abstain: 0

According to the bylaw's definition of Lazy Consensus [3], this is sufficient to approve the nomination.

Thanks,
Tobias

[1] https://mail.openjdk.org/pipermail/valhalla-dev/2025-September/015411.html
[2] https://openjdk.org/census#mchevalier
[3] https://openjdk.org/bylaws#lazy-consensus

From tobias.hartmann at oracle.com  Tue Oct 14 07:32:32 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 14 Oct 2025 09:32:32 +0200
Subject: Result: New Valhalla Committer: Damon Fenacci
Message-ID: <dc45e71d-ce4a-455e-a523-f08db343cf3c@oracle.com>

Voting [1] for Damon Fenacci [2] is now closed.

Yes: 8
Veto: 0
Abstain: 0

According to the bylaw's definition of Lazy Consensus [3], this is sufficient to approve the nomination.

Thanks,
Tobias

[1] https://mail.openjdk.org/pipermail/valhalla-dev/2025-September/015412.html
[2] https://openjdk.org/census#dfenacci
[3] https://openjdk.org/bylaws#lazy-consensus

From mchevalier at openjdk.org  Tue Oct 14 09:15:38 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 14 Oct 2025 09:15:38 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod
Message-ID: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>

When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.

The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.

The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.

First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376

This fixes the original problems, but create a lot more! Well, just flavor of the same thing.

They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatch. 
 It mostly behaves live the `evol_method` but it's not the same, so we can tell them apart.

And so, it comes with the newly regenerated `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`.

Thanks,
Marc

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

Commit messages:
 - Comment a bit, restore copyright
 - New dep type
 - Not using scalarized adapter even if virtual call is optimized.

Changes: https://git.openjdk.org/valhalla/pull/1677/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369185
  Stats: 630 lines in 11 files changed: 126 ins; 112 del; 392 mod
  Patch: https://git.openjdk.org/valhalla/pull/1677.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1677/head:pull/1677

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

From mchevalier at openjdk.org  Tue Oct 14 09:15:40 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 14 Oct 2025 09:15:40 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod
In-Reply-To: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
Message-ID: <yk9ctD0Ef5C6AkRFNul-0oKlZchG7gaxqPCI-_2WlLs=.1433bdc2-bbf8-4708-bfff-e10a8fb6b0e2@github.com>

On Tue, 14 Oct 2025 08:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.
> 
> The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.
> 
> The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.
> 
> First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376
> 
> This fixes the original problems, but create a lot more! Well, just flavor of the same thing.
> 
> They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatch
 . It mostly behaves live the `evol_method` but it's not the sa...

src/hotspot/share/code/nmethod.hpp line 1066:

> 1064:   // Used for fast breakpoint support if only_calling_convention is false;
> 1065:   // used for updating the calling convention if true.
> 1066:   bool is_dependent_on_method(Method* dependee, bool only_calling_convention);

I'm not really happy about this `bool only_calling_convention`. I'd rather like a `Dependencies::DepType` instead because it is only used in

Dependencies::DepType dep_type = only_calling_convention ? Dependencies::mismatch_calling_convention : Dependencies::evol_method;


The problem is that then I get a cyclic include between `nmethod.hpp` and `dependencies.hpp`. It's probably avoidable, but I need to refactor a bit too intensely than I feel comfortable in such a small fix.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod line 116:

> 114:             0x2AB40007102A9F00;
> 115:             0x0DBB000D59120FB7;
> 116:             0x0011BFB1;

Interesting how `javac` now simplifies it into a "return void".

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod line 996:

> 994:     Attr(#20) { // LoadableDescriptors
> 995:       0x00010015;
> 996:     } // end LoadableDescriptors

That was missing. If we read a bit, it means: there is 0x0001 = 1 class to preload. And it is the number 0x0015 = 21, which is `LMyValue1` in the constant pool. Which is pretty much what we expect.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1677#discussion_r2428453083
PR Review Comment: https://git.openjdk.org/valhalla/pull/1677#discussion_r2428433306
PR Review Comment: https://git.openjdk.org/valhalla/pull/1677#discussion_r2428439996

From dsimms at openjdk.org  Tue Oct 14 09:21:20 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 14 Oct 2025 09:21:20 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <NXBEkuTwVcaX2KawM7B3oSWlmF4L6K_MFBuFJkv-fpI=.3e724b1d-2102-419c-84fe-33e8b479714c@github.com>

Merge jdk-26+15

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_26_15
 - Merge jdk
 - 8367268: Remove unused os::numa_topology_changed()
 - 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null
 - 8366951: Test runtime/logging/StressAsyncUL.java is timing out
 - 8366342: Key generator and key pair generator tests skipping, but showing as passed
 - 8367243: Format issues with dist dump debug output in PhaseGVN::dead_loop_check
 - 8366702: C2 SuperWord: refactor VTransform vector nodes
 - 8361530: Test javax/swing/GraphicsConfigNotifier/StalePreferredSize.java timed out
 - 8367293: RISC-V: enable vectorapi test for VectorMask.laneIsSet
 - ... and 102 more: https://git.openjdk.org/valhalla/compare/849c84dd...a2296c29

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

Changes: https://git.openjdk.org/valhalla/pull/1678/files
  Stats: 19179 lines in 590 files changed: 9565 ins; 6574 del; 3040 mod
  Patch: https://git.openjdk.org/valhalla/pull/1678.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1678/head:pull/1678

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

From duke at openjdk.org  Tue Oct 14 10:16:58 2025
From: duke at openjdk.org (amr01060)
Date: Tue, 14 Oct 2025 10:16:58 GMT
Subject: [lworld] RFR: Merge jdk
In-Reply-To: <NXBEkuTwVcaX2KawM7B3oSWlmF4L6K_MFBuFJkv-fpI=.3e724b1d-2102-419c-84fe-33e8b479714c@github.com>
References: <NXBEkuTwVcaX2KawM7B3oSWlmF4L6K_MFBuFJkv-fpI=.3e724b1d-2102-419c-84fe-33e8b479714c@github.com>
Message-ID: <Ajsr4f_TNxso6M8mIT77yePUZ5TDvr_TrdOu5I9RGR4=.570b1a4a-3ec7-4d9e-9ba9-c7e176325289@github.com>

On Tue, 14 Oct 2025 09:12:12 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+15

Marked as reviewed by amr01060 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/valhalla/pull/1678#pullrequestreview-3334864605

From dsimms at openjdk.org  Tue Oct 14 11:07:08 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 14 Oct 2025 11:07:08 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <NXBEkuTwVcaX2KawM7B3oSWlmF4L6K_MFBuFJkv-fpI=.3e724b1d-2102-419c-84fe-33e8b479714c@github.com>
References: <NXBEkuTwVcaX2KawM7B3oSWlmF4L6K_MFBuFJkv-fpI=.3e724b1d-2102-419c-84fe-33e8b479714c@github.com>
Message-ID: <pNXAznLPE9nbINDhyQ_fAomt1ZR5610isy0mCT1xbR0=.d1c0832d-6414-46d5-96ec-99d90d500881@github.com>

On Tue, 14 Oct 2025 09:12:12 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+15

This pull request has now been integrated.

Changeset: dd10b98e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/dd10b98e74443d2a2defa4cdfeb4d4b2f46e54bd
Stats:     19179 lines in 590 files changed: 9565 ins; 6574 del; 3040 mod

Merge jdk

Merge jdk-26+15

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

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

From qamai at openjdk.org  Tue Oct 14 11:57:53 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 14 Oct 2025 11:57:53 GMT
Subject: [lworld] RFR: 8348547: [lworld] Investigate false adapter sharing due
 to inherited fields in the calling convention
Message-ID: <04oow_W9U7ABfK5N_StB4eqw0kHR5Em0uhztr02tQi4=.a7ed1a19-70d8-4658-bdc0-4cfe61081194@github.com>

Hi,

Currently, the class `AdapterFingerPrint` only tracks the types of the arguments in the calling convention. This does not work well with the inclusion of value classes which need to be packed and unpacked when passed between different tiers. This is because 2 types can have the same sequence of field types, yet the fields are placed at different offsets. In those cases, the code to pack those types cannot be the same, hence the adapter code cannot be shared. Currently, a hack is implemented to cover the cases of inherited fields. For example:

    value class MyAbstract {
        int x;
    }

    value class MyValue1 extends MyAbstract {}

    value class MyValue2 {
        int x;
    }

In this case, since `MyAbstract` is an abstract class, we do not know the complete field sequence of every class that has the field `MyAbstract.x`. Moreover, we need to ensure that the payload of a value class is stable when it is flattened, and it can be accessed atomically if atomicity is required. As a result, `MyAbstract.x` must have the highest alignment, which is currently 8 because the largest atomic flat access is 8-byte. However, `MyValue2.x` does not need such a large alignment.

The current hack put a pair of `T_METADATA`, `T_VOID` before an inherited field. This is fine for the case above, but it clashes with another case:

    value class MyValue3 {
        @NullRestricted
        Empty e;
        int x;
    }

The solution I propose is to add field offsets into `AdapterFingerPrint`, as well as removing the current hack. Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - Fix incorrect adapter sharing with value classes

Changes: https://git.openjdk.org/valhalla/pull/1679/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348547
  Stats: 252 lines in 3 files changed: 139 ins; 59 del; 54 mod
  Patch: https://git.openjdk.org/valhalla/pull/1679.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1679/head:pull/1679

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

From dsimms at openjdk.org  Tue Oct 14 12:17:35 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 14 Oct 2025 12:17:35 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <3cmBA9MpXHozW6ZAhvvVcq4spwe0-HvT2tz4RS7KJkI=.71ad4737-25f4-4734-b3c9-7f75bf1f0d09@github.com>

Merge tag 'jdk-26+16' into lworld_merge_jdk_26_16
Added tag jdk-26+16 for changeset a49856bb

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

Commit messages:
 - Merge tag 'jdk-26+16' into lworld_merge_jdk_26_16
 - 8367969: C2: compiler/vectorapi/TestVectorMathLib.java fails without UnlockDiagnosticVMOptions
 - 8367740: assembler_<cpu>.inline.hpp should not include assembler.inline.hpp
 - 8367721: Test compiler/arguments/TestCompileTaskTimeout.java crashed: SIGSEGV
 - 8367689: Revert removal of several compilation-related vmStructs fields
 - 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java
 - 8367278: Test compiler/startup/StartupOutput.java timed out after completion on Windows
 - 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive
 - 8367333: C2: Vector math operation intrinsification failure
 - 8367787: Expand use of representation equivalence terminology in Float16
 - ... and 91 more: https://git.openjdk.org/valhalla/compare/dd10b98e...35f89535

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

Changes: https://git.openjdk.org/valhalla/pull/1680/files
  Stats: 25409 lines in 698 files changed: 13211 ins; 6533 del; 5665 mod
  Patch: https://git.openjdk.org/valhalla/pull/1680.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1680/head:pull/1680

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

From duke at openjdk.org  Tue Oct 14 12:34:14 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 14 Oct 2025 12:34:14 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
Message-ID: <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>

> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

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

  Reorganising to catch preview-only cases

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1618/files
  - new: https://git.openjdk.org/valhalla/pull/1618/files/9ca6c473..2b805fb0

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

  Stats: 41 lines in 1 file changed: 20 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1618.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1618/head:pull/1618

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

From duke at openjdk.org  Tue Oct 14 14:03:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 14 Oct 2025 14:03:56 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
Message-ID: <x2dFw2fk7kOAmUqdyQ5eXqj2kZyvV7l-lOdyh77VItw=.ef2ed0b9-91e7-4b69-a844-324fea8180b6@github.com>

On Tue, 14 Oct 2025 12:34:14 GMT, David Beaumont <duke at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorganising to catch preview-only cases

src/java.base/share/native/libjimage/jimage.cpp line 145:

> 143:     }
> 144: 
> 145:     // find_location_index() returns the data "offset", not an index.

I reworked this code slightly and added more comments explaining why the "do two lookups if the resource doesn't exist" should not risk performance issues (we should only be being asked for things that are expected to exist). Of course if anyone reviewing this thinks this is not a correct statement, please speak up!!

Right now, the flags are definitely zero (the new attribute is never written and defaults to zero) so the preview specific code is unreachable code until the jimage creation is modified (even if `is_preview_mode` were true, which it isn't).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2429322847

From rriggs at openjdk.org  Tue Oct 14 14:57:20 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Oct 2025 14:57:20 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
Message-ID: <HvAdTERgJz5lcdc_CbO8IRQfGsQ1C7dUidf05cn1piU=.fd4daadd-e10a-43a3-8f85-b04b385be1b1@github.com>

On Tue, 14 Oct 2025 12:34:14 GMT, David Beaumont <duke at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorganising to catch preview-only cases

Marked as reviewed by rriggs (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1618#pullrequestreview-3336125130

From rriggs at openjdk.org  Tue Oct 14 14:57:21 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Oct 2025 14:57:21 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <51Vshpfe07kULcYbJzbGPjnl2GHdE11pPpFEqtyUUNg=.1e5ed0e4-e922-4512-a980-6e1d4fba9f33@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <bxP9Kn1AdoiFnrY7lIp2thk9KZwmNNKlZs_5E5EleKQ=.ac2b3e2e-3290-4d21-a404-bf772f242a45@github.com>
 <51Vshpfe07kULcYbJzbGPjnl2GHdE11pPpFEqtyUUNg=.1e5ed0e4-e922-4512-a980-6e1d4fba9f33@github.com>
Message-ID: <b3bDQDyDs78OsileQDuzLrjZMXagkMn0lSFIZaChsgI=.33550e3e-01aa-442d-8d78-01945171f902@github.com>

On Thu, 9 Oct 2025 20:03:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/native/libjimage/jimage.cpp line 114:
>> 
>>> 112:     size_t preview_infix_len = strlen(preview_infix);
>>> 113: 
>>> 114:     // TBD:   assert(module_name_len > 0 && "module name must be non-empty");
>> 
>> TBD: is obsolete?
>
> I don't use multiple white-space, so this wasn't me. It's just line 113 in the old code moved.
> I don't know enough to change it confidently.

The assert is live, so the comment can be removed.  non-empty module name seems like the correct assertion.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2429496535

From duke at openjdk.org  Tue Oct 14 16:04:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 14 Oct 2025 16:04:33 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <b3bDQDyDs78OsileQDuzLrjZMXagkMn0lSFIZaChsgI=.33550e3e-01aa-442d-8d78-01945171f902@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <bxP9Kn1AdoiFnrY7lIp2thk9KZwmNNKlZs_5E5EleKQ=.ac2b3e2e-3290-4d21-a404-bf772f242a45@github.com>
 <51Vshpfe07kULcYbJzbGPjnl2GHdE11pPpFEqtyUUNg=.1e5ed0e4-e922-4512-a980-6e1d4fba9f33@github.com>
 <b3bDQDyDs78OsileQDuzLrjZMXagkMn0lSFIZaChsgI=.33550e3e-01aa-442d-8d78-01945171f902@github.com>
Message-ID: <5wCnjMAoDCptTWtkhhmrvfDqYiXiyVRLAWYlUNUUn7E=.43ba24f1-ebee-4caf-8099-cf5665222c71@github.com>

On Tue, 14 Oct 2025 14:53:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I don't use multiple white-space, so this wasn't me. It's just line 113 in the old code moved.
>> I don't know enough to change it confidently.
>
> The assert is live, so the comment can be removed.  non-empty module name seems like the correct assertion.

name_len and module_name_len are two different things though. The assert for module_name_len is not live.
Does module_name_len perhaps mean something in the context of code not in any module?
The code below would generate an unobtainable path with '//' in (not present in the jimage, but lookup will progress the same as any other non-existent path).
I'll raise a PR for it and see if it can be enabled or (if module names can be empty) be just shortcut and return `0L` if it happens.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2429699003

From duke at openjdk.org  Tue Oct 14 16:09:42 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 14 Oct 2025 16:09:42 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
Message-ID: <Neum5ErJtY8VraUvDEi1hSf-CrBcxUU5KGuwHdbRDZw=.a1b4268b-26b2-4e2e-b5bd-c4d17795a52c@github.com>

On Tue, 14 Oct 2025 12:34:14 GMT, David Beaumont <duke at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorganising to catch preview-only cases

src/hotspot/share/classfile/classLoader.cpp line 471:

> 469: 
> 470:   jlong size;
> 471:   JImageLocationRef location = jimage_find_resource("", name, is_preview, &size);

Actually, now I look at callers, I see this. An empty module name.
So perhaps it should all work and maybe the double '//' isn't what will happen.
The original code also passes "" here, and the old string concatenation code does:

    index = 0;
    fullpath[index++] = '/';
    memcpy(&fullpath[index], module_name, moduleNameLen);
    index += moduleNameLen;
    fullpath[index++] = '/';
    memcpy(&fullpath[index], name, nameLen);
    index += nameLen;
    fullpath[index++] = '\0';


So it too looks like it generates '//' in the name, which really shouldn't result in anything being found (but we're not in Kansas anymore, so I'll save investigating this for the PR).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2429719330

From rriggs at openjdk.org  Tue Oct 14 18:04:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Oct 2025 18:04:55 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <5wCnjMAoDCptTWtkhhmrvfDqYiXiyVRLAWYlUNUUn7E=.43ba24f1-ebee-4caf-8099-cf5665222c71@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <bxP9Kn1AdoiFnrY7lIp2thk9KZwmNNKlZs_5E5EleKQ=.ac2b3e2e-3290-4d21-a404-bf772f242a45@github.com>
 <51Vshpfe07kULcYbJzbGPjnl2GHdE11pPpFEqtyUUNg=.1e5ed0e4-e922-4512-a980-6e1d4fba9f33@github.com>
 <b3bDQDyDs78OsileQDuzLrjZMXagkMn0lSFIZaChsgI=.33550e3e-01aa-442d-8d78-01945171f902@github.com>
 <5wCnjMAoDCptTWtkhhmrvfDqYiXiyVRLAWYlUNUUn7E=.43ba24f1-ebee-4caf-8099-cf5665222c71@github.com>
Message-ID: <7byi3jrzJuoBQqMeaEqRAJk8Kn_zDGPwCec-FBPDrho=.b1a7b524-e098-42db-9b21-d8bf45a59b81@github.com>

On Tue, 14 Oct 2025 16:00:03 GMT, David Beaumont <duke at openjdk.org> wrote:

>> The assert is live, so the comment can be removed.  non-empty module name seems like the correct assertion.
>
> name_len and module_name_len are two different things though. The assert for module_name_len is not live.
> Does module_name_len perhaps mean something in the context of code not in any module?
> The code below would generate an unobtainable path with '//' in (not present in the jimage, but lookup will progress the same as any other non-existent path).
> I'll raise a PR for it and see if it can be enabled or (if module names can be empty) be just shortcut and return `0L` if it happens.

ok, a separate PR is a good idea to resolve that.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2430020063

From duke at openjdk.org  Tue Oct 14 18:28:48 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 14 Oct 2025 18:28:48 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v7]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

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

 - Rolled up changes after rebase.
   
   * Removing package root flag based on feedback.
   * Changing existing package flags during writing to match altered flag values.
   * Feedback changes, and fixing some comments.
   * Renaming slightly confusing "testEncoder" method.
   * Fixing unit tests to use new constructor.
   * Word smithing flags definitions.
   * Add workaround until new image writing code is in
   * Clarifying flag docs for /packages/xxx case
   * Java ImageReader changes for preview mode
 - Merge branch 'jdk_8366093_cpp/squashed' into jdk_8368333_java/squashed
 - [[RESET BRANCH FOR MERGE]]
 - Removing package root flag based on feedback.
 - Changing existing package flags during writing to match altered flag values.
 - Feedback changes, and fixing some comments.
 - Test fixes and feedback changes.
   
   * Renaming slightly confusing "testEncoder" method.
   * Fixing unit tests to use new constructor.
 - Manually deleting ImageReaderFactory (it returned somehow)
 - Word smithing flags definitions.
 - Add workaround until new image writing code is in
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/77039d1f...9bbc26c1

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1619/files
  - new: https://git.openjdk.org/valhalla/pull/1619/files/2c0db3d3..9bbc26c1

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

  Stats: 72 lines in 2 files changed: 24 ins; 25 del; 23 mod
  Patch: https://git.openjdk.org/valhalla/pull/1619.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1619/head:pull/1619

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

From duke at openjdk.org  Tue Oct 14 18:34:59 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 14 Oct 2025 18:34:59 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v7]
In-Reply-To: <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
Message-ID: <LrQBgGjsuuLN7OKcQBlqnv9JhXKwCxUtTF0h_nEvGKQ=.fef1a41e-a269-4679-9c03-ca0c325fe26b@github.com>

On Tue, 14 Oct 2025 18:28:48 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
>> 
>> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Rolled up changes after rebase.
>    
>    * Removing package root flag based on feedback.
>    * Changing existing package flags during writing to match altered flag values.
>    * Feedback changes, and fixing some comments.
>    * Renaming slightly confusing "testEncoder" method.
>    * Fixing unit tests to use new constructor.
>    * Word smithing flags definitions.
>    * Add workaround until new image writing code is in
>    * Clarifying flag docs for /packages/xxx case
>    * Java ImageReader changes for preview mode
>  - Merge branch 'jdk_8366093_cpp/squashed' into jdk_8368333_java/squashed
>  - [[RESET BRANCH FOR MERGE]]
>  - Removing package root flag based on feedback.
>  - Changing existing package flags during writing to match altered flag values.
>  - Feedback changes, and fixing some comments.
>  - Test fixes and feedback changes.
>    
>    * Renaming slightly confusing "testEncoder" method.
>    * Fixing unit tests to use new constructor.
>  - Manually deleting ImageReaderFactory (it returned somehow)
>  - Word smithing flags definitions.
>  - Add workaround until new image writing code is in
>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/a993aa4a...9bbc26c1

test/jdk/tools/jimage/ImageReaderDuplicateChildNodesTest.java line 2:

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

Restoring the copyright year accidentally removed in the last change.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2430086433

From chagedorn at openjdk.org  Wed Oct 15 07:04:02 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 15 Oct 2025 07:04:02 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks
Message-ID: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>

This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.

I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.

#### Changes
- Split into separate `@test` blocks.
- Added packages where we missed them for consistency.
- Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).

#### Test Execution Time
Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):

|  | lworld | lworld + patch | improvement |
|-----|----------|----------|----------|
| tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
| tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
| tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
| tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |

We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.

Thanks,
Christian

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

Commit messages:
 - 8369437: [lworld] Split multiple @run statements in compiler tests into separate groups

Changes: https://git.openjdk.org/valhalla/pull/1681/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1681&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369437
  Stats: 1189 lines in 29 files changed: 969 ins; 8 del; 212 mod
  Patch: https://git.openjdk.org/valhalla/pull/1681.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1681/head:pull/1681

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

From thartmann at openjdk.org  Wed Oct 15 07:04:44 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 15 Oct 2025 07:04:44 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod
In-Reply-To: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
Message-ID: <997khsN9jZkyfFqNWfipTnk33KEVhI8YfHYcH4BZzXo=.e9daac3a-80ee-47cd-86f1-601fdfe85385@github.com>

On Tue, 14 Oct 2025 08:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.
> 
> The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.
> 
> The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.
> 
> First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376
> 
> This fixes the original problems, but create a lot more! Well, just flavor of the same thing.
> 
> They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatch
 . It mostly behaves live the `evol_method` but it's not the sa...

Nice analysis, Marc! Fix looks good to me, I just added a few suggestions.

src/hotspot/share/code/dependencies.hpp line 120:

> 118:     // was assumed to be callable with the scalar calling convention.
> 119:     // In case of a mismatch, because of future class loading, the
> 120:     // nmethod must be recompiled to use the non-scalar calling convention.

This comment is a bit imprecise. The problem is that **some** argument of this method was assumed to be always passed in scalarized form. Due to a mismatch with two super methods (one assuming scalarized and one assuming non-scalarized), all **callers** of this method (via virtual calls) now need to be recompiled. Right? Maybe refer to the code in `CompiledEntrySignature::compute_calling_conventions` for details.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1677#pullrequestreview-3338417741
PR Review Comment: https://git.openjdk.org/valhalla/pull/1677#discussion_r2431166901

From thartmann at openjdk.org  Wed Oct 15 07:04:46 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 15 Oct 2025 07:04:46 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod
In-Reply-To: <yk9ctD0Ef5C6AkRFNul-0oKlZchG7gaxqPCI-_2WlLs=.1433bdc2-bbf8-4708-bfff-e10a8fb6b0e2@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
 <yk9ctD0Ef5C6AkRFNul-0oKlZchG7gaxqPCI-_2WlLs=.1433bdc2-bbf8-4708-bfff-e10a8fb6b0e2@github.com>
Message-ID: <_3ftW6B_y8q-nL-UYSwJujjoQs6Sv-UCU9k3RaR-hnA=.2b7a14d1-c550-4d6f-8796-d0621982c572@github.com>

On Tue, 14 Oct 2025 09:08:33 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.
>> 
>> The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.
>> 
>> The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.
>> 
>> First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
>> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376
>> 
>> This fixes the original problems, but create a lot more! Well, just flavor of the same thing.
>> 
>> They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatc
 h. It mostly behaves live the `evol_met...
>
> src/hotspot/share/code/nmethod.hpp line 1066:
> 
>> 1064:   // Used for fast breakpoint support if only_calling_convention is false;
>> 1065:   // used for updating the calling convention if true.
>> 1066:   bool is_dependent_on_method(Method* dependee, bool only_calling_convention);
> 
> I'm not really happy about this `bool only_calling_convention`. I'd rather like a `Dependencies::DepType` instead because it is only used in
> 
> Dependencies::DepType dep_type = only_calling_convention ? Dependencies::mismatch_calling_convention : Dependencies::evol_method;
> 
> 
> The problem is that then I get a cyclic include between `nmethod.hpp` and `dependencies.hpp`. It's probably avoidable, but I need to refactor a bit too intensely than I feel comfortable in such a small fix.

I guess an alternative would be to add separate methods, similar to what we have for `CodeCache::mark_dependents_on_method_for_breakpoint` -> `CodeCache::mark_dependents_on_method_for_mismatch` or something. That would at least limit the `only_calling_convention` arg to `is_dependent_on_method`.

Or what about always checking both dependencies in `nmethod::is_dependent_on_method`? After all, both dependencies represent an actual dependency:
- If the nmethod has a `evol_method` dependency, it's supposed to be deopted anyway. It doesn't matter where this happens.
- If the nmethod has a `mismatch_calling_convention` dependency, in the worst case we deopt it when we reach this code via `CodeCache::mark_dependents_on_method_for_breakpoint` or `WB_DeoptimizeMethod`, i.e. when we want to make sure that all compiled versions (via inlining) of a method are deopted. So we would unnecessarily deopt the caller of a mismatched method when we set a breakpoint in that mismatched method (or deopt it via the WB API). I think that's fine.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1677#discussion_r2431344991

From dsimms at openjdk.org  Wed Oct 15 09:04:50 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 15 Oct 2025 09:04:50 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <3cmBA9MpXHozW6ZAhvvVcq4spwe0-HvT2tz4RS7KJkI=.71ad4737-25f4-4734-b3c9-7f75bf1f0d09@github.com>
References: <3cmBA9MpXHozW6ZAhvvVcq4spwe0-HvT2tz4RS7KJkI=.71ad4737-25f4-4734-b3c9-7f75bf1f0d09@github.com>
Message-ID: <MAQQssF8WNoZKfnEIixtWqWBrg9DjqTyDTY4G69Jb_s=.07995cff-9f3f-4ba5-b3e6-ad3e2070b160@github.com>

> Merge tag 'jdk-26+16' into lworld_merge_jdk_26_16
> Added tag jdk-26+16 for changeset a49856bb

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

  Array.get() is not native

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1680/files
  - new: https://git.openjdk.org/valhalla/pull/1680/files/35f89535..5f595dc1

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

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

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

From dsimms at openjdk.org  Wed Oct 15 09:04:52 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 15 Oct 2025 09:04:52 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <3cmBA9MpXHozW6ZAhvvVcq4spwe0-HvT2tz4RS7KJkI=.71ad4737-25f4-4734-b3c9-7f75bf1f0d09@github.com>
References: <3cmBA9MpXHozW6ZAhvvVcq4spwe0-HvT2tz4RS7KJkI=.71ad4737-25f4-4734-b3c9-7f75bf1f0d09@github.com>
Message-ID: <shYZPn3cInP_kc9Ox4UYsyzoelHMADfoVZgBBgT-dHM=.89b60108-dd5d-45cd-8906-06d67659a6e3@github.com>

On Tue, 14 Oct 2025 12:11:09 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+16' into lworld_merge_jdk_26_16
> Added tag jdk-26+16 for changeset a49856bb

This pull request has now been integrated.

Changeset: c1774b0b
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c1774b0b6b129623f77fbb7096d332565f148677
Stats:     25409 lines in 698 files changed: 13211 ins; 6533 del; 5665 mod

Merge jdk

Merge jdk-26+16

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

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

From phubner at openjdk.org  Wed Oct 15 09:10:31 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 15 Oct 2025 09:10:31 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
Message-ID: <0w4DRW58XsZbEEgPVpmVPj9iDgTeSwABKe-9gk2h3mw=.38539872-4ece-473d-8834-07b76109bdb4@github.com>

On Tue, 14 Oct 2025 12:34:14 GMT, David Beaumont <duke at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorganising to catch preview-only cases

Marked as reviewed by phubner (Author).

src/java.base/share/native/libjimage/jimage.cpp line 115:

> 113: 
> 114:     // TBD:   assert(module_name_len > 0 && "module name must be non-empty");
> 115:     assert(name_len > 0 && "name must non-empty");

Nitpick: `assert(expr, msg)` vs `assert(expr && msg)`.

src/java.base/share/native/libjimage/jimage.cpp line 190:

> 188:         index += preview_infix_len;
> 189:         // Check we copied up to the expected '/' separator.
> 190:         assert(name_buffer[index] == '/' && "bad string concatenation");

Here as well fwiw.

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

PR Review: https://git.openjdk.org/valhalla/pull/1618#pullrequestreview-3339245357
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2431752110
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2431754458

From thartmann at openjdk.org  Wed Oct 15 09:27:08 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 15 Oct 2025 09:27:08 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks
In-Reply-To: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
Message-ID: <d2xaEvVN1vhyNioyvZEsYaCE9EB3c6ji1Cz-rgZBrj4=.6cce5e6e-2e7d-4bc7-8a05-f15e171b2d3d@github.com>

On Wed, 15 Oct 2025 06:56:37 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
> 
> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
> 
> #### Changes
> - Split into separate `@test` blocks.
> - Added packages where we missed them for consistency.
> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
> - Introduced ids for the different `@test` blocks.
> 
> #### Test Execution Time
> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
> 
> |  | lworld | lworld + patch | improvement |
> |-----|----------|----------|----------|
> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
> 
> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
> 
> Thanks,
> Christian

Nice improvements! Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1681#pullrequestreview-3339333847

From chagedorn at openjdk.org  Wed Oct 15 09:27:08 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 15 Oct 2025 09:27:08 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks
In-Reply-To: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
Message-ID: <LPsU3Sanf3JtfdH3BKKGxtwgZfX5v4L9yukw4Gyvteg=.facd0edc-2839-4118-ae78-84cf6ee4e30e@github.com>

On Wed, 15 Oct 2025 06:56:37 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
> 
> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
> 
> #### Changes
> - Split into separate `@test` blocks.
> - Added packages where we missed them for consistency.
> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
> - Introduced ids for the different `@test` blocks.
> 
> #### Test Execution Time
> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
> 
> |  | lworld | lworld + patch | improvement |
> |-----|----------|----------|----------|
> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
> 
> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
> 
> Thanks,
> Christian

Thanks Tobias for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1681#issuecomment-3405436440

From thartmann at openjdk.org  Wed Oct 15 10:31:16 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 15 Oct 2025 10:31:16 GMT
Subject: [lworld] RFR: 8348547: [lworld] Investigate false adapter sharing
 due to inherited fields in the calling convention
In-Reply-To: <04oow_W9U7ABfK5N_StB4eqw0kHR5Em0uhztr02tQi4=.a7ed1a19-70d8-4658-bdc0-4cfe61081194@github.com>
References: <04oow_W9U7ABfK5N_StB4eqw0kHR5Em0uhztr02tQi4=.a7ed1a19-70d8-4658-bdc0-4cfe61081194@github.com>
Message-ID: <wnpWbx1_6y6RUL9OZ7EeL5qRGftx_7ir6Py9e7B-n-0=.9bd45679-4c39-4bbb-a8aa-d0359c918127@github.com>

On Tue, 14 Oct 2025 11:51:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Currently, the class `AdapterFingerPrint` only tracks the types of the arguments in the calling convention. This does not work well with the inclusion of value classes which need to be packed and unpacked when passed between different tiers. This is because 2 types can have the same sequence of field types, yet the fields are placed at different offsets. In those cases, the code to pack those types cannot be the same, hence the adapter code cannot be shared. Currently, a hack is implemented to cover the cases of inherited fields. For example:
> 
>     value class MyAbstract {
>         int x;
>     }
> 
>     value class MyValue1 extends MyAbstract {}
> 
>     value class MyValue2 {
>         int x;
>     }
> 
> In this case, since `MyAbstract` is an abstract class, we do not know the complete field sequence of every class that has the field `MyAbstract.x`. Moreover, we need to ensure that the payload of a value class is stable when it is flattened, and it can be accessed atomically if atomicity is required. As a result, `MyAbstract.x` must have the highest alignment, which is currently 8 because the largest atomic flat access is 8-byte. However, `MyValue2.x` does not need such a large alignment.
> 
> The current hack put a pair of `T_METADATA`, `T_VOID` before an inherited field. This is fine for the case above, but it clashes with another case:
> 
>     value class MyValue3 {
>         @NullRestricted
>         Empty e;
>         int x;
>     }
> 
> The solution I propose is to add field offsets into `AdapterFingerPrint`, as well as removing the current hack. Please take a look and leave your reviews, thanks a lot.

Thanks for working on this! The fix looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1679#pullrequestreview-3339644844

From mchevalier at openjdk.org  Wed Oct 15 13:08:15 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 15 Oct 2025 13:08:15 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod [v2]
In-Reply-To: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
Message-ID: <l8hp1A8x5Wlf959IveOwJcbN3MwUd5Uiwh9fOvno7D4=.6c3ea210-72f0-46e1-b73d-5303dde5032e@github.com>

> When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.
> 
> The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.
> 
> The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.
> 
> First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376
> 
> This fixes the original problems, but create a lot more! Well, just flavor of the same thing.
> 
> They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatch
 . It mostly behaves live the `evol_method` but it's not the sa...

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

 - comment
 - review

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1677/files
  - new: https://git.openjdk.org/valhalla/pull/1677/files/524be8bc..c7c14ec7

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

  Stats: 26 lines in 7 files changed: 6 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1677.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1677/head:pull/1677

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

From mchevalier at openjdk.org  Wed Oct 15 13:08:17 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 15 Oct 2025 13:08:17 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod [v2]
In-Reply-To: <997khsN9jZkyfFqNWfipTnk33KEVhI8YfHYcH4BZzXo=.e9daac3a-80ee-47cd-86f1-601fdfe85385@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
 <997khsN9jZkyfFqNWfipTnk33KEVhI8YfHYcH4BZzXo=.e9daac3a-80ee-47cd-86f1-601fdfe85385@github.com>
Message-ID: <qTmj4r3L2IDdgoBCqKKJUrm98TT0lRT9d3QRSkZ8QXA=.144d24ad-b48f-4886-baa2-aafa1fec31e4@github.com>

On Wed, 15 Oct 2025 05:30:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - comment
>>  - review
>
> src/hotspot/share/code/dependencies.hpp line 120:
> 
>> 118:     // was assumed to be callable with the scalar calling convention.
>> 119:     // In case of a mismatch, because of future class loading, the
>> 120:     // nmethod must be recompiled to use the non-scalar calling convention.
> 
> This comment is a bit imprecise. The problem is that **some** argument of this method was assumed to be always passed in scalarized form. Due to a mismatch with two super methods (one assuming scalarized and one assuming non-scalarized), all **callers** of this method (via virtual calls) now need to be recompiled. Right? Maybe refer to the code in `CompiledEntrySignature::compute_calling_conventions` for details.

I've tried to improve it, largely based on this comment.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1677#discussion_r2432484875

From mchevalier at openjdk.org  Wed Oct 15 13:08:19 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 15 Oct 2025 13:08:19 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod [v2]
In-Reply-To: <_3ftW6B_y8q-nL-UYSwJujjoQs6Sv-UCU9k3RaR-hnA=.2b7a14d1-c550-4d6f-8796-d0621982c572@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
 <yk9ctD0Ef5C6AkRFNul-0oKlZchG7gaxqPCI-_2WlLs=.1433bdc2-bbf8-4708-bfff-e10a8fb6b0e2@github.com>
 <_3ftW6B_y8q-nL-UYSwJujjoQs6Sv-UCU9k3RaR-hnA=.2b7a14d1-c550-4d6f-8796-d0621982c572@github.com>
Message-ID: <TC_sTJjcNJMm6OKeGsR1DxxbtHhcuCqoQJzar7pvjVo=.51671a9a-9c8b-456a-b798-651e27b35872@github.com>

On Wed, 15 Oct 2025 06:56:53 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.hpp line 1066:
>> 
>>> 1064:   // Used for fast breakpoint support if only_calling_convention is false;
>>> 1065:   // used for updating the calling convention if true.
>>> 1066:   bool is_dependent_on_method(Method* dependee, bool only_calling_convention);
>> 
>> I'm not really happy about this `bool only_calling_convention`. I'd rather like a `Dependencies::DepType` instead because it is only used in
>> 
>> Dependencies::DepType dep_type = only_calling_convention ? Dependencies::mismatch_calling_convention : Dependencies::evol_method;
>> 
>> 
>> The problem is that then I get a cyclic include between `nmethod.hpp` and `dependencies.hpp`. It's probably avoidable, but I need to refactor a bit too intensely than I feel comfortable in such a small fix.
>
> I guess an alternative would be to add separate methods, similar to what we have for `CodeCache::mark_dependents_on_method_for_breakpoint` -> `CodeCache::mark_dependents_on_method_for_mismatch` or something. That would at least limit the `only_calling_convention` arg to `is_dependent_on_method`.
> 
> Or what about always checking both dependencies in `nmethod::is_dependent_on_method`? After all, both dependencies represent an actual dependency:
> - If the nmethod has a `evol_method` dependency, it's supposed to be deopted anyway. It doesn't matter where this happens.
> - If the nmethod has a `mismatch_calling_convention` dependency, in the worst case we deopt it when we reach this code via `CodeCache::mark_dependents_on_method_for_breakpoint` or `WB_DeoptimizeMethod`, i.e. when we want to make sure that all compiled versions (via inlining) of a method are deopted. So we would unnecessarily deopt the caller of a mismatched method when we set a breakpoint in that mismatched method (or deopt it via the WB API). I think that's fine.

I started with separate methods, but that was unfortunate duplication. I went for the second option, since testing seems happy. I'm not sure about the new names I introduced tho (`method_types` and `has_method_dep`). If you have better idea, I'll be happy to change them.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1677#discussion_r2432489457

From duke at openjdk.org  Wed Oct 15 13:15:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 15 Oct 2025 13:15:10 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <0w4DRW58XsZbEEgPVpmVPj9iDgTeSwABKe-9gk2h3mw=.38539872-4ece-473d-8834-07b76109bdb4@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
 <0w4DRW58XsZbEEgPVpmVPj9iDgTeSwABKe-9gk2h3mw=.38539872-4ece-473d-8834-07b76109bdb4@github.com>
Message-ID: <RU2ZvdsSdvtNHl6nn_OQP1nuZoHrIbzEmU74TvEf4LQ=.fbf27be0-22cd-4219-9df0-683d963284ad@github.com>

On Wed, 15 Oct 2025 09:06:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reorganising to catch preview-only cases
>
> src/java.base/share/native/libjimage/jimage.cpp line 115:
> 
>> 113: 
>> 114:     // TBD:   assert(module_name_len > 0 && "module name must be non-empty");
>> 115:     assert(name_len > 0 && "name must non-empty");
> 
> Nitpick: `assert(expr, msg)` vs `assert(expr && msg)`.

I was just copying the existing style for consistency. I'll change everything to the other form if that's considered better.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2432517450

From thartmann at openjdk.org  Wed Oct 15 13:24:03 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 15 Oct 2025 13:24:03 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod [v2]
In-Reply-To: <l8hp1A8x5Wlf959IveOwJcbN3MwUd5Uiwh9fOvno7D4=.6c3ea210-72f0-46e1-b73d-5303dde5032e@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
 <l8hp1A8x5Wlf959IveOwJcbN3MwUd5Uiwh9fOvno7D4=.6c3ea210-72f0-46e1-b73d-5303dde5032e@github.com>
Message-ID: <-5wOwCE4QK9RxzlYa72tWlHssRcdcVx3U8IV9P4Abk0=.bef79b8a-1082-4119-b271-df41b3b5d6f4@github.com>

On Wed, 15 Oct 2025 13:08:15 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.
>> 
>> The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.
>> 
>> The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.
>> 
>> First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
>> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376
>> 
>> This fixes the original problems, but create a lot more! Well, just flavor of the same thing.
>> 
>> They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatc
 h. It mostly behaves live the `evol_met...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment
>  - review

Marked as reviewed by thartmann (Committer).

Thanks for the adjustments - looks great!

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

PR Review: https://git.openjdk.org/valhalla/pull/1677#pullrequestreview-3340386092
PR Comment: https://git.openjdk.org/valhalla/pull/1677#issuecomment-3406427727

From phubner at openjdk.org  Wed Oct 15 13:38:49 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 15 Oct 2025 13:38:49 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks
In-Reply-To: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
Message-ID: <NpAuQWEkG1LbJJUX-sL_RzzWsy2sVZO67EnPZ_oiKVM=.3d71ed39-b6b1-4aa8-ad61-7c5da675e08c@github.com>

On Wed, 15 Oct 2025 06:56:37 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
> 
> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
> 
> #### Changes
> - Split into separate `@test` blocks.
> - Added packages where we missed them for consistency.
> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
> - Introduced ids for the different `@test` blocks.
> 
> #### Test Execution Time
> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
> 
> |  | lworld | lworld + patch | improvement |
> |-----|----------|----------|----------|
> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
> 
> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
> 
> Thanks,
> Christian

Looks good, thank you for doing this! I left some nitpicks, as always feel free to disregard.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrayNullMarkers.java line 63:

> 61: 
> 62: /*
> 63:  * @test id=nAVF

Nitpick/FYI: switching from kebab case to camel case. I don't think this matters at all but wanted to point it out just in case.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnexpectedMemBar.java line 38:

> 36: 
> 37: /*
> 38:  * @test id=AII-

I think trailing `-` are awkward? Or is there a convention/reason for this?

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1681#pullrequestreview-3340360748
PR Review Comment: https://git.openjdk.org/valhalla/pull/1681#discussion_r2432528498
PR Review Comment: https://git.openjdk.org/valhalla/pull/1681#discussion_r2432596003

From chagedorn at openjdk.org  Wed Oct 15 14:04:21 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 15 Oct 2025 14:04:21 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks [v2]
In-Reply-To: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
Message-ID: <iHafqJducy8VYG5WFQKRTzDjjR-yGHQNkd634GZT1CY=.697d4366-64a1-42a1-b0f9-e5062c72ca2b@github.com>

> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
> 
> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
> 
> #### Changes
> - Split into separate `@test` blocks.
> - Added packages where we missed them for consistency.
> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
> - Introduced ids for the different `@test` blocks.
> 
> #### Test Execution Time
> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
> 
> |  | lworld | lworld + patch | improvement |
> |-----|----------|----------|----------|
> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
> 
> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
> 
> Thanks,
> Christian

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

  review Paul

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1681/files
  - new: https://git.openjdk.org/valhalla/pull/1681/files/ae093cc7..da6df6ee

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

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

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

From chagedorn at openjdk.org  Wed Oct 15 14:04:23 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 15 Oct 2025 14:04:23 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks
In-Reply-To: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
Message-ID: <HvdSrDYrSvxG-2ah15OP8I5OMWrm-e7W515H7XAGvtQ=.bdcf6b4e-773b-42a5-9160-9b5dc904bd5c@github.com>

On Wed, 15 Oct 2025 06:56:37 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
> 
> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
> 
> #### Changes
> - Split into separate `@test` blocks.
> - Added packages where we missed them for consistency.
> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
> - Introduced ids for the different `@test` blocks.
> 
> #### Test Execution Time
> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
> 
> |  | lworld | lworld + patch | improvement |
> |-----|----------|----------|----------|
> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
> 
> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
> 
> Thanks,
> Christian

Thanks Paul for your review! Pushed a small update.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1681#issuecomment-3406578692

From chagedorn at openjdk.org  Wed Oct 15 14:04:26 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 15 Oct 2025 14:04:26 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks [v2]
In-Reply-To: <NpAuQWEkG1LbJJUX-sL_RzzWsy2sVZO67EnPZ_oiKVM=.3d71ed39-b6b1-4aa8-ad61-7c5da675e08c@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
 <NpAuQWEkG1LbJJUX-sL_RzzWsy2sVZO67EnPZ_oiKVM=.3d71ed39-b6b1-4aa8-ad61-7c5da675e08c@github.com>
Message-ID: <wZOUvBcJbikWdH2pXvJA16KZWmjSjLbPYStLeuVctOc=.b6c4dcf8-ce3f-4dd7-8be8-782346b94786@github.com>

On Wed, 15 Oct 2025 13:16:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review Paul
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrayNullMarkers.java line 63:
> 
>> 61: 
>> 62: /*
>> 63:  * @test id=nAVF
> 
> Nitpick/FYI: switching from kebab case to camel case. I don't think this matters at all but wanted to point it out just in case.

Good observation! I used it for "non-atomic" because it still belongs to the "A" and I did not want to confuse it with "N" for Nullable. It's a little unfortunate, though.

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnexpectedMemBar.java line 38:
> 
>> 36: 
>> 37: /*
>> 38:  * @test id=AII-
> 
> I think trailing `-` are awkward? Or is there a convention/reason for this?

Good catch! Fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1681#discussion_r2432660376
PR Review Comment: https://git.openjdk.org/valhalla/pull/1681#discussion_r2432664035

From phubner at openjdk.org  Wed Oct 15 14:04:22 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 15 Oct 2025 14:04:22 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks [v2]
In-Reply-To: <iHafqJducy8VYG5WFQKRTzDjjR-yGHQNkd634GZT1CY=.697d4366-64a1-42a1-b0f9-e5062c72ca2b@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
 <iHafqJducy8VYG5WFQKRTzDjjR-yGHQNkd634GZT1CY=.697d4366-64a1-42a1-b0f9-e5062c72ca2b@github.com>
Message-ID: <O_a9XohsduAlf667XVZ2XhfVKUOpQP6Gcryzr42qBgo=.538a9fa3-9379-4c10-a21a-6d41e7089b46@github.com>

On Wed, 15 Oct 2025 14:01:16 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
>> 
>> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
>> 
>> #### Changes
>> - Split into separate `@test` blocks.
>> - Added packages where we missed them for consistency.
>> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
>> - Introduced ids for the different `@test` blocks.
>> 
>> #### Test Execution Time
>> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
>> 
>> |  | lworld | lworld + patch | improvement |
>> |-----|----------|----------|----------|
>> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
>> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
>> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
>> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
>> 
>> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review Paul

LGTM! Thanks again.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1681#pullrequestreview-3340578410

From mchevalier at openjdk.org  Wed Oct 15 14:32:34 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 15 Oct 2025 14:32:34 GMT
Subject: [lworld] RFR: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod [v2]
In-Reply-To: <l8hp1A8x5Wlf959IveOwJcbN3MwUd5Uiwh9fOvno7D4=.6c3ea210-72f0-46e1-b73d-5303dde5032e@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
 <l8hp1A8x5Wlf959IveOwJcbN3MwUd5Uiwh9fOvno7D4=.6c3ea210-72f0-46e1-b73d-5303dde5032e@github.com>
Message-ID: <ObJMo_WqbRC12eym3Ogi1kOh78hNkjNIs9vPwiuRDvM=.4c6129fd-2351-40bb-941d-9586ae0165ff@github.com>

On Wed, 15 Oct 2025 13:08:15 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.
>> 
>> The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.
>> 
>> The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.
>> 
>> First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
>> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376
>> 
>> This fixes the original problems, but create a lot more! Well, just flavor of the same thing.
>> 
>> They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatc
 h. It mostly behaves live the `evol_met...
>
> Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment
>  - review

Thanks @TobiHartmann, and now to use my new Committer powers!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1677#issuecomment-3406744473

From liach at openjdk.org  Wed Oct 15 14:32:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 14:32:46 GMT
Subject: [lworld] RFR: Regression~30% in jvm2008 Serial with
 -XX:-EnableValhalla
Message-ID: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>

There's a spike of calls to `Unsafe.isFlatField` in serialzation workloads. The layout information can be prepared with FieldReflector and cached. CI looks good, need to verify the regression is fixed.

The old perfasm profile was:
....[Hottest Regions]...............................................................................
   4.66% libjvm.so Unsafe_IsFlatField
   4.13% c2, level 4 java.io.ObjectOutputStream::writeObject0, version 6, compile id 2698
   3.72% c2, level 4 java.io.ObjectInputStream$BlockDataInputStream::readUTFSpan, version 2, compile id 1878
   3.61% c2, level 4 java.io.ObjectInputStream$PeekInputStream::readFully, version 2, compile id 1902

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

Commit messages:
 - Bug
 - 8369719: [lworld] Regression~30% in jvm2008 Serial with -XX:-EnableValhalla

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

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

From mchevalier at openjdk.org  Wed Oct 15 14:32:35 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 15 Oct 2025 14:32:35 GMT
Subject: [lworld] Integrated: 8369185: [lworld] Wrong execution in
 TestMismatchHandling after regenerating TestMismatchHandling.jcod
In-Reply-To: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
References: <6x09E2rCo41lrplSwUCqzpXH1MdmzPiQjbZbNzfEAw8=.66d1caa5-3445-4a72-905f-e3e30d3f14ce@github.com>
Message-ID: <4U0Nh0vVVJ8J2lNhxOP0yitpzzDvaVikPjI4uOpQ9IQ=.4e82b977-9b6d-4da5-85f5-18f597ee392c@github.com>

On Tue, 14 Oct 2025 08:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.
> 
> The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.
> 
> The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.
> 
> First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376
> 
> This fixes the original problems, but create a lot more! Well, just flavor of the same thing.
> 
> They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatch
 . It mostly behaves live the `evol_method` but it's not the sa...

This pull request has now been integrated.

Changeset: 2da79ac2
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2da79ac29d9734ecf36f562924b0af1ab68beef9
Stats:     631 lines in 8 files changed: 131 ins; 112 del; 388 mod

8369185: [lworld] Wrong execution in TestMismatchHandling after regenerating TestMismatchHandling.jcod

Reviewed-by: thartmann

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

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

From thartmann at openjdk.org  Wed Oct 15 14:33:44 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 15 Oct 2025 14:33:44 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks [v2]
In-Reply-To: <iHafqJducy8VYG5WFQKRTzDjjR-yGHQNkd634GZT1CY=.697d4366-64a1-42a1-b0f9-e5062c72ca2b@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
 <iHafqJducy8VYG5WFQKRTzDjjR-yGHQNkd634GZT1CY=.697d4366-64a1-42a1-b0f9-e5062c72ca2b@github.com>
Message-ID: <FL4u_EudcoIPRHnVp6R2_B1eaqi6DWAEL4RzW2oDwXI=.b3965d11-eaae-4db0-86a1-90aae9235e92@github.com>

On Wed, 15 Oct 2025 14:04:21 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
>> 
>> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
>> 
>> #### Changes
>> - Split into separate `@test` blocks.
>> - Added packages where we missed them for consistency.
>> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
>> - Introduced ids for the different `@test` blocks.
>> 
>> #### Test Execution Time
>> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
>> 
>> |  | lworld | lworld + patch | improvement |
>> |-----|----------|----------|----------|
>> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
>> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
>> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
>> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
>> 
>> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review Paul

Marked as reviewed by thartmann (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1681#pullrequestreview-3340744222

From rriggs at openjdk.org  Wed Oct 15 15:26:21 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 15 Oct 2025 15:26:21 GMT
Subject: [lworld] RFR: 8369923: [lworld] Hot call to Unsafe.isFlatField in
 serialization
In-Reply-To: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
References: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
Message-ID: <oBeJZWYzbLRD5QlvOGr2Rpud_OAbf5cn-q5uxY5WcYs=.695bdc22-4055-42d0-a3b5-e77fec20c3ee@github.com>

On Mon, 13 Oct 2025 19:53:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> There's a spike of calls to `Unsafe.isFlatField` in serialzation workloads. The layout information can be prepared with FieldReflector and cached. CI looks good, need to verify the regression is fixed.
> 
> The old perfasm profile was:
> ....[Hottest Regions]...............................................................................
>    4.66% libjvm.so Unsafe_IsFlatField
>    4.13% c2, level 4 java.io.ObjectOutputStream::writeObject0, version 6, compile id 2698
>    3.72% c2, level 4 java.io.ObjectInputStream$BlockDataInputStream::readUTFSpan, version 2, compile id 1878
>    3.61% c2, level 4 java.io.ObjectInputStream$PeekInputStream::readFully, version 2, compile id 1902

looks good

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1676#pullrequestreview-3341005728

From forax at openjdk.org  Wed Oct 15 15:39:40 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 15 Oct 2025 15:39:40 GMT
Subject: [lworld] RFR: 8369923: [lworld] Hot call to Unsafe.isFlatField in
 serialization
In-Reply-To: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
References: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
Message-ID: <PpVoW--UCYudv5snw7Px3K6RSaZtgzLn3ZrYrP7Sx7E=.69cbe4e8-d71e-4405-8b88-79e71181a6b4@github.com>

On Mon, 13 Oct 2025 19:53:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> There's a spike of calls to `Unsafe.isFlatField` in serialzation workloads. The layout information can be prepared with FieldReflector and cached. CI looks good, need to verify the regression is fixed.
> 
> The old perfasm profile was:
> ....[Hottest Regions]...............................................................................
>    4.66% libjvm.so Unsafe_IsFlatField
>    4.13% c2, level 4 java.io.ObjectOutputStream::writeObject0, version 6, compile id 2698
>    3.72% c2, level 4 java.io.ObjectInputStream$BlockDataInputStream::readUTFSpan, version 2, compile id 1878
>    3.61% c2, level 4 java.io.ObjectInputStream$PeekInputStream::readFully, version 2, compile id 1902

The long term fix is to have a value class `FieldLayout` with an int field inside jdk.internal.misc that represent a field layout.

Obviously, it can not be done until Valhalla is out of preview.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1676#issuecomment-3407073614

From liach at openjdk.org  Wed Oct 15 16:08:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 16:08:48 GMT
Subject: [lworld] RFR: 8369923: [lworld] Hot call to Unsafe.isFlatField in
 serialization
In-Reply-To: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
References: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
Message-ID: <WPV3TG9IsjzbLZe04Cr0UqYb_FYdYK5TZpUyOkVO2Do=.f857c25e-c150-4766-bbb1-a47acb5663a3@github.com>

On Mon, 13 Oct 2025 19:53:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> There's a spike of calls to `Unsafe.isFlatField` in serialzation workloads. The layout information can be prepared with FieldReflector and cached. CI looks good, need to verify the regression is fixed.
> 
> The old perfasm profile was:
> ....[Hottest Regions]...............................................................................
>    4.66% libjvm.so Unsafe_IsFlatField
>    4.13% c2, level 4 java.io.ObjectOutputStream::writeObject0, version 6, compile id 2698
>    3.72% c2, level 4 java.io.ObjectInputStream$BlockDataInputStream::readUTFSpan, version 2, compile id 1878
>    3.61% c2, level 4 java.io.ObjectInputStream$PeekInputStream::readFully, version 2, compile id 1902

I don't think FieldLayout is sufficient for the long term - I view this array polymorphism as a baby step towards a polymorphic VM. What should replace an int layout should be a specialization anchor in the long run.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1676#issuecomment-3407229026

From qamai at openjdk.org  Wed Oct 15 16:20:05 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 15 Oct 2025 16:20:05 GMT
Subject: [lworld] RFR: 8348547: [lworld] Investigate false adapter sharing
 due to inherited fields in the calling convention
In-Reply-To: <wnpWbx1_6y6RUL9OZ7EeL5qRGftx_7ir6Py9e7B-n-0=.9bd45679-4c39-4bbb-a8aa-d0359c918127@github.com>
References: <04oow_W9U7ABfK5N_StB4eqw0kHR5Em0uhztr02tQi4=.a7ed1a19-70d8-4658-bdc0-4cfe61081194@github.com>
 <wnpWbx1_6y6RUL9OZ7EeL5qRGftx_7ir6Py9e7B-n-0=.9bd45679-4c39-4bbb-a8aa-d0359c918127@github.com>
Message-ID: <YwvCKfPdjBbI8zC8nbwiTizl8orRw4I0X1dr7muk-RY=.283788c8-389f-41c1-9e17-0f8959db8a6c@github.com>

On Wed, 15 Oct 2025 10:28:36 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, the class `AdapterFingerPrint` only tracks the types of the arguments in the calling convention. This does not work well with the inclusion of value classes which need to be packed and unpacked when passed between different tiers. This is because 2 types can have the same sequence of field types, yet the fields are placed at different offsets. In those cases, the code to pack those types cannot be the same, hence the adapter code cannot be shared. Currently, a hack is implemented to cover the cases of inherited fields. For example:
>> 
>>     value class MyAbstract {
>>         int x;
>>     }
>> 
>>     value class MyValue1 extends MyAbstract {}
>> 
>>     value class MyValue2 {
>>         int x;
>>     }
>> 
>> In this case, since `MyAbstract` is an abstract class, we do not know the complete field sequence of every class that has the field `MyAbstract.x`. Moreover, we need to ensure that the payload of a value class is stable when it is flattened, and it can be accessed atomically if atomicity is required. As a result, `MyAbstract.x` must have the highest alignment, which is currently 8 because the largest atomic flat access is 8-byte. However, `MyValue2.x` does not need such a large alignment.
>> 
>> The current hack put a pair of `T_METADATA`, `T_VOID` before an inherited field. This is fine for the case above, but it clashes with another case:
>> 
>>     value class MyValue3 {
>>         @NullRestricted
>>         Empty e;
>>         int x;
>>     }
>> 
>> The solution I propose is to add field offsets into `AdapterFingerPrint`, as well as removing the current hack. Please take a look and leave your reviews, thanks a lot.
>
> Thanks for working on this! The fix looks good to me.

@TobiHartmann Thanks a lot for your review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1679#issuecomment-3407277997

From qamai at openjdk.org  Wed Oct 15 16:20:08 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 15 Oct 2025 16:20:08 GMT
Subject: [lworld] Integrated: 8348547: [lworld] Investigate false adapter
 sharing due to inherited fields in the calling convention
In-Reply-To: <04oow_W9U7ABfK5N_StB4eqw0kHR5Em0uhztr02tQi4=.a7ed1a19-70d8-4658-bdc0-4cfe61081194@github.com>
References: <04oow_W9U7ABfK5N_StB4eqw0kHR5Em0uhztr02tQi4=.a7ed1a19-70d8-4658-bdc0-4cfe61081194@github.com>
Message-ID: <Ag2Fs7iYPZvXca7AMCfjlQUij39TFTu_OiBE9KViXUM=.4b4ba5af-ac7d-43bb-85c8-5edc789cafb0@github.com>

On Tue, 14 Oct 2025 11:51:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Currently, the class `AdapterFingerPrint` only tracks the types of the arguments in the calling convention. This does not work well with the inclusion of value classes which need to be packed and unpacked when passed between different tiers. This is because 2 types can have the same sequence of field types, yet the fields are placed at different offsets. In those cases, the code to pack those types cannot be the same, hence the adapter code cannot be shared. Currently, a hack is implemented to cover the cases of inherited fields. For example:
> 
>     value class MyAbstract {
>         int x;
>     }
> 
>     value class MyValue1 extends MyAbstract {}
> 
>     value class MyValue2 {
>         int x;
>     }
> 
> In this case, since `MyAbstract` is an abstract class, we do not know the complete field sequence of every class that has the field `MyAbstract.x`. Moreover, we need to ensure that the payload of a value class is stable when it is flattened, and it can be accessed atomically if atomicity is required. As a result, `MyAbstract.x` must have the highest alignment, which is currently 8 because the largest atomic flat access is 8-byte. However, `MyValue2.x` does not need such a large alignment.
> 
> The current hack put a pair of `T_METADATA`, `T_VOID` before an inherited field. This is fine for the case above, but it clashes with another case:
> 
>     value class MyValue3 {
>         @NullRestricted
>         Empty e;
>         int x;
>     }
> 
> The solution I propose is to add field offsets into `AdapterFingerPrint`, as well as removing the current hack. Please take a look and leave your reviews, thanks a lot.

This pull request has now been integrated.

Changeset: 75c007b1
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/75c007b13865a023fb830805436b07f263e4abef
Stats:     252 lines in 3 files changed: 139 ins; 59 del; 54 mod

8348547: [lworld] Investigate false adapter sharing due to inherited fields in the calling convention

Reviewed-by: thartmann

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

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

From liach at openjdk.org  Wed Oct 15 16:46:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 16:46:22 GMT
Subject: [lworld] RFR: 8369923: [lworld] Hot call to Unsafe.isFlatField in
 serialization
In-Reply-To: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
References: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
Message-ID: <WnekWgGswvjPNfgsznZ1Ef2ybj1DvT1wPnI8j4s7j7c=.b57aac67-1e4d-43fc-b08c-97438c13ea84@github.com>

On Mon, 13 Oct 2025 19:53:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> There's a spike of calls to `Unsafe.isFlatField` in serialzation workloads. The layout information can be prepared with FieldReflector and cached. CI looks good, need to verify the regression is fixed.
> 
> The old perfasm profile was:
> ....[Hottest Regions]...............................................................................
>    4.66% libjvm.so Unsafe_IsFlatField
>    4.13% c2, level 4 java.io.ObjectOutputStream::writeObject0, version 6, compile id 2698
>    3.72% c2, level 4 java.io.ObjectInputStream$BlockDataInputStream::readUTFSpan, version 2, compile id 1878
>    3.61% c2, level 4 java.io.ObjectInputStream$PeekInputStream::readFully, version 2, compile id 1902

Thanks for the reviews. Two unrelated hotspot compiler failures in tier 10-3; I think we should be good to go.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1676#issuecomment-3407376360

From liach at openjdk.org  Wed Oct 15 16:46:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 16:46:22 GMT
Subject: [lworld] Integrated: 8369923: [lworld] Hot call to Unsafe.isFlatField
 in serialization
In-Reply-To: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
References: <sD4IJV40ngE9yrtLo7ThptE_bYbTLDTeaH6mKsK2ytg=.895e509d-7bda-40ff-adc4-17f712efc26d@github.com>
Message-ID: <gth5s7HRXt7iCBxxyVFk1dZzzZUaYEX10e9WEIljXJQ=.781f5846-f3be-4e76-a6d9-10beeaf7411f@github.com>

On Mon, 13 Oct 2025 19:53:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> There's a spike of calls to `Unsafe.isFlatField` in serialzation workloads. The layout information can be prepared with FieldReflector and cached. CI looks good, need to verify the regression is fixed.
> 
> The old perfasm profile was:
> ....[Hottest Regions]...............................................................................
>    4.66% libjvm.so Unsafe_IsFlatField
>    4.13% c2, level 4 java.io.ObjectOutputStream::writeObject0, version 6, compile id 2698
>    3.72% c2, level 4 java.io.ObjectInputStream$BlockDataInputStream::readUTFSpan, version 2, compile id 1878
>    3.61% c2, level 4 java.io.ObjectInputStream$PeekInputStream::readFully, version 2, compile id 1902

This pull request has now been integrated.

Changeset: d7e2c65a
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d7e2c65a733d8e40e06a9bb3ea474b525a672290
Stats:     9 lines in 1 file changed: 4 ins; 0 del; 5 mod

8369923: [lworld] Hot call to Unsafe.isFlatField in serialization

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Wed Oct 15 20:17:10 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Oct 2025 20:17:10 GMT
Subject: [lworld] Withdrawn: [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: <Or5aIGMgU8_RR_S15jBcbcOk2-v0W1-dNezIn4gy6SM=.79dca730-21ee-4af5-b525-bc25bd7b643f@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.

This pull request has been closed without being integrated.

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

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

From chagedorn at openjdk.org  Thu Oct 16 07:25:41 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 16 Oct 2025 07:25:41 GMT
Subject: [lworld] RFR: 8369437: [lworld] Split multiple @run statements in
 compiler tests into separate @test blocks [v2]
In-Reply-To: <iHafqJducy8VYG5WFQKRTzDjjR-yGHQNkd634GZT1CY=.697d4366-64a1-42a1-b0f9-e5062c72ca2b@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
 <iHafqJducy8VYG5WFQKRTzDjjR-yGHQNkd634GZT1CY=.697d4366-64a1-42a1-b0f9-e5062c72ca2b@github.com>
Message-ID: <lciThDtyiVPWSg4zMXR1-nxuz1tPZnS60efzC75uX4U=.f388e67c-9d2c-4f03-a2cb-94b851cd7d6b@github.com>

On Wed, 15 Oct 2025 14:04:21 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
>> 
>> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
>> 
>> #### Changes
>> - Split into separate `@test` blocks.
>> - Added packages where we missed them for consistency.
>> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
>> - Introduced ids for the different `@test` blocks.
>> 
>> #### Test Execution Time
>> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
>> 
>> |  | lworld | lworld + patch | improvement |
>> |-----|----------|----------|----------|
>> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
>> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
>> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
>> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
>> 
>> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review Paul

Thanks for your reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1681#issuecomment-3409532805

From chagedorn at openjdk.org  Thu Oct 16 07:25:41 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 16 Oct 2025 07:25:41 GMT
Subject: [lworld] Integrated: 8369437: [lworld] Split multiple @run statements
 in compiler tests into separate @test blocks
In-Reply-To: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
References: <pvqVs0WjAnoG4D18r9Lea2w0fRYyXkX1abjY2YKMLRY=.e140f1e1-95a3-49b0-801a-a94beeaaedb1@github.com>
Message-ID: <DpoKBm7OE-fALDldCPnnJzb0hAnjH6FvVe_NA0cd3S0=.51921ba5-c6db-415e-ad36-0ec3863f02c1@github.com>

On Wed, 15 Oct 2025 06:56:37 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch splits jtreg tests with multiple `@run` statements in one `@test` block into different blocks. This allows jtreg to do better parallelization.
> 
> I walked through all `compiler/valhalla/inlinetypes` tests. Whenever we had 3 or more `@run` statements in a single `@test` block, I compared the test with execution times on Mach5, mainly tier1. If the test needed more time to execute, I split the block into separate blocks. Otherwise, I left them untouched (we can repeat this process if necessary when we see some more opportunities). Note: I did not change anything else in the tests themselves like loop iterations etc.
> 
> #### Changes
> - Split into separate `@test` blocks.
> - Added packages where we missed them for consistency.
> - Changed `othervm/main` into `main` when there was no flag passed (could be left-over from runs that had `-XX:+EnableValhalla` before).
> - Introduced ids for the different `@test` blocks.
> 
> #### Test Execution Time
> Since I changed quite a lot of tests and there is no simple way to run tier1-4 only with `compiler/valhalla/inlinetypes` tests without also running them with flag combos that they normally do not run, I ran it once through these tiers separately. There were no timeouts reported anymore after the timeout factor change back to 4 in Valhalla. Here are the results for the total machine times compared to the last CI run `jdk-26-valhalla+1-83` (could of course have some variance but the numbers are just an indication):
> 
> |  | lworld | lworld + patch | improvement |
> |-----|----------|----------|----------|
> | tier1 | 1d 00h 45m 31s |  14h 37m 43s |  ~ - 10 h |
> | tier2 | 1d 06h 16m 54s | 1d 02h 50m 17s | ~ - 3h 30min |
> | tier3 | 2d 19h 08m 57s | 2d 15h 25m 58s | ~ - 3h 45min |
> | tier4 | 2d 12h 13m 12s | 2d 01h 28m 00s | ~ - 10h 45min |
> 
> We can see quite some improvements by simply doing that. Note that [JDK-8369530](https://bugs.openjdk.org/browse/JDK-8369530) explores improvement opportunities for the actual testing code.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: c42a95f8
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c42a95f8d60d0de265b35fc8bd5e7755e106eccb
Stats:     1189 lines in 29 files changed: 969 ins; 8 del; 212 mod

8369437: [lworld] Split multiple @run statements in compiler tests into separate @test blocks

Reviewed-by: thartmann, phubner

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

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

From coleenp at openjdk.org  Thu Oct 16 15:20:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Oct 2025 15:20:46 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word [v3]
In-Reply-To: <7Na06zC67tt7CJtx-kTllnRjogeAz6rEiRDcRxryWVY=.0e23c0ec-8f88-45ff-afe0-5f491189bb12@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
 <7Na06zC67tt7CJtx-kTllnRjogeAz6rEiRDcRxryWVY=.0e23c0ec-8f88-45ff-afe0-5f491189bb12@github.com>
Message-ID: <-oLNuerM9VP_llEhLEneEE2JdKKMxSEJ5cuOKNYCeJE=.509ee78b-513d-4be6-ba22-135ce06a5dd8@github.com>

On Mon, 13 Oct 2025 09:30:30 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
>> 
>> Specifically, there are three portions to this change:
>> - Moving the age bits lower to their intended position.
>> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
>> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
>> 
>> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8367073
>  - Remove unused prototype method.
>  - Merge branch 'lworld' into JDK-8367073
>  - Revise documentation.
>  - Fix hashCode intrinsic miscompilation.
>  - Fix outdated markWord test semantics.
>  - Chuck out weird markWord code.
>  - Emulate old Valhalla decode_pointer behavior.
>  - Fix typo.
>  - Follow JEP450 MarkWord specification.

This looks really good!

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1578#pullrequestreview-3345513833

From phubner at openjdk.org  Thu Oct 16 15:36:35 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 16 Oct 2025 15:36:35 GMT
Subject: [lworld] RFR: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word [v3]
In-Reply-To: <7Na06zC67tt7CJtx-kTllnRjogeAz6rEiRDcRxryWVY=.0e23c0ec-8f88-45ff-afe0-5f491189bb12@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
 <7Na06zC67tt7CJtx-kTllnRjogeAz6rEiRDcRxryWVY=.0e23c0ec-8f88-45ff-afe0-5f491189bb12@github.com>
Message-ID: <tfxSGnerG49wYpDBeQQaN34Aoo3wdhjGKOB2Tgpv7sA=.0e4c2ca0-a091-435b-ab33-331de6d8df36@github.com>

On Mon, 13 Oct 2025 09:30:30 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
>> 
>> Specifically, there are three portions to this change:
>> - Moving the age bits lower to their intended position.
>> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
>> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
>> 
>> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8367073
>  - Remove unused prototype method.
>  - Merge branch 'lworld' into JDK-8367073
>  - Revise documentation.
>  - Fix hashCode intrinsic miscompilation.
>  - Fix outdated markWord test semantics.
>  - Chuck out weird markWord code.
>  - Emulate old Valhalla decode_pointer behavior.
>  - Fix typo.
>  - Follow JEP450 MarkWord specification.

Thanks for your reviews folks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1578#issuecomment-3411477829

From phubner at openjdk.org  Thu Oct 16 15:36:36 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 16 Oct 2025 15:36:36 GMT
Subject: [lworld] Integrated: 8367073: [lworld] Conform to JEP 450 encoding of
 mark word
In-Reply-To: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
References: <BGH3pFgJmz2FQ35AaBaClHVCwUseZXsdDcrXWeZ_Y44=.cc847a25-c666-4104-8c52-7018dd39b200@github.com>
Message-ID: <zo9jy51JyeKEuMU9LcXWEvdOaOzQbGchQGsYnN90tgk=.03ce082f-15fa-4026-ac4f-72099527a080@github.com>

On Fri, 12 Sep 2025 09:43:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR refactors the mark word to use the order of bits as specified in [JEP 450](https://openjdk.org/jeps/450). 
> 
> Specifically, there are three portions to this change:
> - Moving the age bits lower to their intended position.
> - Fixing a miscompilation in the native `hashCode` intrinsic that got unearthed as a result.
> - Updating the documentation to be more inline with the mainline docs and minimal Valhalla additions.
> 
> Feedback is welcome, especially for the doc changes. If there are any ideas of other places in which similar miscompilations could occur, that would be valuable to know as well.

This pull request has now been integrated.

Changeset: cccb5014
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cccb5014b5f84f8cd57ff808f5bbc07263e25545
Stats:     98 lines in 3 files changed: 8 ins; 74 del; 16 mod

8367073: [lworld] Conform to JEP 450 encoding of mark word

Reviewed-by: coleenp, fparain, thartmann

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

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

From phubner at openjdk.org  Fri Oct 17 08:24:40 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 17 Oct 2025 08:24:40 GMT
Subject: [lworld] RFR: 8314996: [lworld]
 java/lang/Thread/virtual/stress/PingPong.java fails since jdk-22+8
In-Reply-To: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>
References: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>
Message-ID: <ZXutcTKsXbKUymQHrXG1ojkoButhshiapyKRrqaZkhw=.415d4bb6-3e4d-4e35-8e74-7000b758cb00@github.com>

On Fri, 3 Oct 2025 14:54:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> When running with JTREG_REPEAT_COUNT=1000 I get the same error as skynet in [JDK-8342977](https://bugs.openjdk.org/browse/JDK-8342977), so I'm using that number for the ProblemList-Virtual.txt. This fails intermittently without JTREG_TEST_THREAD_FACTORY=Virtual, so maybe this belongs in ProblemList.txt instead, as well as Skynet.

Thanks!

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1657#pullrequestreview-3348845501

From mchevalier at openjdk.org  Fri Oct 17 12:24:05 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 17 Oct 2025 12:24:05 GMT
Subject: [lworld] RFR: 8368988: [lworld] Rename classes in valhalla/inlinetypes
 to be distinct
Message-ID: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>

Various cleanup in test package `compiler.valhalla.inlinetypes`:
- rename duplicated classes so that IDEs are nice, resolve correctly. New names are a bit... arbitrary. I'm happy to rename name if anyone has opinions. When writing new tests, let's prefer nested classes if we can.
- add `package compiler.valhalla.inlinetypes;` where it was missing. IDEs like that, and I vaguely remember we should.
- fix flags to take the new path into account, new package, or class renaming. Please, try to pay attention to that: I've did multiple passes to catch'em all, but this is easy to miss.
- remove some useless `import`.
- some few typos in comments.
- maybe more?

Thanks,
Marc

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

Commit messages:
 - Merge remote-tracking branch 'origin/lworld' into JDK-8368988
 - post rebase fixes
 - Fixes
 - Some cleanup

Changes: https://git.openjdk.org/valhalla/pull/1683/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1683&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368988
  Stats: 1550 lines in 53 files changed: 42 ins; 54 del; 1454 mod
  Patch: https://git.openjdk.org/valhalla/pull/1683.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1683/head:pull/1683

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

From dfenacci at openjdk.org  Fri Oct 17 14:55:51 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 17 Oct 2025 14:55:51 GMT
Subject: [lworld] RFR: 8367405: [lworld] C2 compilation fails with empty
 program detected during loop optimization
Message-ID: <nmya9pXUOg_oIesAvCO-ahc5WHRepMKPu4xbAHa223A=.c431dac2-2d41-402a-b5c9-ba77e83ceaa0@github.com>

## Issue
The symptom is that an empty program is detected during loop optimization when running `compiler/stringopts/TestStackedConcatsAppendUncommonTrap.java` with `-XX:-TieredCompilation -XX:+StressUnstableIfTraps`.

## Cause
The cause's origin is string concatenation failing to bail out. More specifically, at the end of `StringConcat::validate_control_flow`, while validating the results, we miss processing a `Phi` node and wrongly let the validation pass. The starting point is this:

<img width="938" height="820" alt="image" src="https://github.com/user-attachments/assets/b7a3ee17-33d7-4ecb-8fb0-fb962a831f04" />

While processing the `Proj` node and going through its outputs, we reach the `CheckCastPP` and add its uses to the worklist (basically only the `Phi` node).

https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/opto/stringopts.cpp#L1138-L1145

Surprisingly we don't add the `CheckCastPP` node itself. 
In one of the next worklist iterations we process the `Phi` node and its uses and none of them make the validation fail.

Side note: `CheckCastPP` is added as additional profiling in Valhalla when parsing `acmp`
https://github.com/openjdk/valhalla/blob/23dc125e5791238a97923108b77c6fc0b59d894f/src/hotspot/share/opto/parse2.cpp#L2098-L2102

On the other hand in mainline `CheckCastPP` is not added and when processing the `Proj`, `Phi` is encountered as one of its uses and the validation fails straight away.

## Fix

Unfortunately this looks yet like another patch in the stacked optimisation's pattern matching "denylist" approach. As mentioned by @danielogh and @robcasloz in the JBS issue, a long-term better approach would be to limit the concatenation to known safe cases.

While waiting for that, a reasonable ad-hoc solution for this Valhalla case is to add a specific `CheckCastPP` case to the validation of uses that also adds itself to the worklist. This will include `CheckCastPP` nodes added by Valhalla's additional profiling (in all fairness this doesn't exclude potential other origins, but the extend and outcome in terms of concatenation optimisation failures should be quite limited).
Note: `CastPP` has to be treated differently: it seems that not adding itself in the worklist was done on purpose for `CastPP` to skip string null check `Phi` nodes among other things.

## Testing

Tests: tier 1-3

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

Commit messages:
 - JDK-8367405: simplify
 - JDK-8367405: ad-hoc CheckCastPP handling
 - JDK-8367405: add string concatenation output check to Test7179138_1
 - Merge branch 'lworld' into JDK-8367405
 - JDK-8367405: [lworld] C2 compilation fails with empty program detected during loop optimization

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

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

From phubner at openjdk.org  Fri Oct 17 15:34:44 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 17 Oct 2025 15:34:44 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks
Message-ID: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>

Hi all,

This PR mirrors the changes made to [the compiler](https://github.com/openjdk/valhalla/pull/1681) `jtreg` testing setup ([issue](https://bugs.openjdk.org/browse/JDK-8369437)).

**Concretely:**
* Split multiple (independent) `@run`s into separate `@test` blocks, specifying new IDs where appropriate.
* Added packages where we missed them for consistency. This excludes places where the test setup does not allow for packages or for tests that are disabled (some of which don't compile, as our model is evolving). 
* Changed `@run main/othervm` into `@run main` when there was no flag passed.

**Impact:**

I compared machine execution time in tiers 1-4 to `jdk-26-valhalla+1-89` (which my changes are based on). 

| | lworld | lworld + patch | improvement
-- | -- | -- | -- 
tier1 | 1d 00h 26m 16s |  1d 00h 13m 20s | ~ - 3 mins
tier2 | 1d 03h 16m 04s | 1d 01h 24m 05s | ~ -2 hours
tier3 | 2d 17h 29m 13s | 2d 17h 16m 15s | ~ -13 mins
tier4 | 2d 11h 32m 26s | 2d 01h 05m 40s | ~ -10 hours

Overall, the trend shows shorter execution times. (And by extension, probably less electricity usage too :))

Note that the CI ran a few extra tasks at tiers 2,  (two orders of magnitude less compared to the total number of tasks) than my personal run did. I don't think these will impact the results significantly.

*Disclaimers: these measurements were run before adding packages and getting rid of a few leftover `main/othervm`, although these should not change the results significantly. Also, this is very ad-hoc "benchmarking," variance is not measured.*

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

Commit messages:
 - Add package and fix some left over othervm.
 - Refactor ValueTearing.java.
 - TestFlatArrayElementMaxOops.java.
 - Refactor ObjectMethods.java.
 - Refactor InlineTypesTest.java.
 - Refactor InlineTypeDensity.java.
 - Refactor InlineTypeArray.java.
 - First iteration, othervm removal and trivial splits.

Changes: https://git.openjdk.org/valhalla/pull/1682/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369893
  Stats: 418 lines in 52 files changed: 279 ins; 1 del; 138 mod
  Patch: https://git.openjdk.org/valhalla/pull/1682.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1682/head:pull/1682

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

From phubner at openjdk.org  Fri Oct 17 15:54:15 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 17 Oct 2025 15:54:15 GMT
Subject: [lworld] RFR: 8369134: [lworld] We should preserve the markWord for
 all GCs
Message-ID: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>

Hi all,

This PR follows up on changes made in [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875). I updated the documentation to reflect the new information gained.

Furthermore, the investigation described in the issue yielded that we _must_ preserve the larval bit explicitly. I introduce a regression test. If we change the mark word preservation condition to `return (!is_unlocked() || !has_no_hash())` (i.e. what we had before), I have confirmed that we will crash a debug VM via failed assertion. Note that ZGC does not require mark word preservation. I've nonetheless decided to include it in case this behaviour is introduced later.

Testing: tiers 1-3.

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

Commit messages:
 - Flagless VM for larval test.
 - Update documentation.
 - Merge branch 'lworld' into JDK-8369134
 - Recommit the test.
 - Revert "Refactor Parallel mark handling and add test."
 - Refactor Parallel mark handling and add test.

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

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

From fparain at openjdk.org  Fri Oct 17 16:20:17 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 17 Oct 2025 16:20:17 GMT
Subject: [lworld] RFR: 8368933: [lworld] Unsafe.arrayBaseOffset() ambiguous
Message-ID: <qAzU1e-auj7FcvkCj6vMw3aJs1MQ7cA5LSOeRSzzQSA=.5a69cf98-dcc8-4635-8dba-77f8f1b1bef1@github.com>

Renaming of Unsafe methods to prevent ambiguity when null is passed in argument.

Tested with Mach5 tier1-3.

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

Commit messages:
 - Rename ambiguous Unsafe methods

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

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

From liach at openjdk.org  Fri Oct 17 16:34:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 17 Oct 2025 16:34:50 GMT
Subject: [lworld] RFR: 8368933: [lworld] Unsafe.arrayBaseOffset() ambiguous
In-Reply-To: <qAzU1e-auj7FcvkCj6vMw3aJs1MQ7cA5LSOeRSzzQSA=.5a69cf98-dcc8-4635-8dba-77f8f1b1bef1@github.com>
References: <qAzU1e-auj7FcvkCj6vMw3aJs1MQ7cA5LSOeRSzzQSA=.5a69cf98-dcc8-4635-8dba-77f8f1b1bef1@github.com>
Message-ID: <oppPSZ4z-6SrWCNFFXoNJTMnlcztgVKOIpqFpRi1ok0=.0e2a48e2-689d-4b4b-84e0-e1f00135e576@github.com>

On Fri, 17 Oct 2025 16:13:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Renaming of Unsafe methods to prevent ambiguity when null is passed in argument.
> 
> Tested with Mach5 tier1-3.

Marked as reviewed by liach (Committer).

Another way could be that we update AddressComputationContractTest to cast null to Class. That test should be updated to cover the new instance-based offset/scale methods too.

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

PR Review: https://git.openjdk.org/valhalla/pull/1684#pullrequestreview-3351071834
PR Comment: https://git.openjdk.org/valhalla/pull/1684#issuecomment-3416292850

From rriggs at openjdk.org  Fri Oct 17 19:35:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Oct 2025 19:35:06 GMT
Subject: [lworld] RFR: 8369921: [lworld] Remove caches of primitive wrapper
 classes
Message-ID: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>

Disable use of wrapper cached values when --enable-preview and add javadoc descriptions for enable-preview.
The wrapper classes are Byte, Short, Character, Integer, and Long.

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

Commit messages:
 - 8369921: [lworld] Remove caches of primitive wrapper classes

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

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

From coleenp at openjdk.org  Fri Oct 17 20:17:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Oct 2025 20:17:40 GMT
Subject: [lworld] RFR: 8369134: [lworld] We should preserve the markWord
 for all GCs
In-Reply-To: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
References: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
Message-ID: <s26oRQc9xl_goVHO0I_YbNa9x_ruQwXO8WOXd15fZwQ=.5a243930-8ec7-4248-a2ef-323aa94d011c@github.com>

On Tue, 7 Oct 2025 13:02:10 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This PR follows up on changes made in [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875). I updated the documentation to reflect the new information gained.
> 
> Furthermore, the investigation described in the issue yielded that we _must_ preserve the larval bit explicitly. I introduce a regression test. If we change the mark word preservation condition to `return (!is_unlocked() || !has_no_hash())` (i.e. what we had before), I have confirmed that we will crash a debug VM via failed assertion. Note that ZGC does not require mark word preservation. I've nonetheless decided to include it in case this behaviour is introduced later.
> 
> Testing: tiers 1-3.

The comment looks good.

test/hotspot/jtreg/runtime/valhalla/inlinetypes/LarvalMarkWordTest.java line 91:

> 89:   }
> 90: 
> 91:   private static void stressTheGC() {

There's a WhiteBox FullGC that you can call that might be a reliable way of calling System.gc().

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

PR Review: https://git.openjdk.org/valhalla/pull/1666#pullrequestreview-3351870930
PR Review Comment: https://git.openjdk.org/valhalla/pull/1666#discussion_r2441130180

From darcy at openjdk.org  Fri Oct 17 22:01:31 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 17 Oct 2025 22:01:31 GMT
Subject: [lworld] RFR: 8369921: [lworld] Remove caches of primitive wrapper
 classes
In-Reply-To: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
References: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
Message-ID: <3ne8NFGmjaQtQ4OLWkpWevIGWVoWrogmhvpzni2uEQA=.0c62e343-6689-4d1d-91b7-a9010c8b88a5@github.com>

On Fri, 17 Oct 2025 19:28:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Disable use of wrapper cached values when --enable-preview and add javadoc descriptions for enable-preview.
> The wrapper classes are Byte, Short, Character, Integer, and Long.

No tests need to be updated; `java/lang/Integer/ValueOf.java` passes with this change?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1685#issuecomment-3417372908

From vromero at openjdk.org  Fri Oct 17 22:31:36 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 17 Oct 2025 22:31:36 GMT
Subject: [lworld] RFR: 8369860: [lworld] Javac generates duplicate initializer
 code
Message-ID: <GXEjKtDU-Ogny4Zdu0CJ7o3udh7rwD7hhNerHvpX6pE=.c3c6a8c1-130d-42f3-9cd8-6c92ab132ad8@github.com>

For code like:


value class Test {
    static class Foo {
        int x;
        int getX() { return x; }
    }
    private final Foo data = new Foo();
    Test() {
        data.getX();
        super();
    }
}


javac generates code corresponding to the initialization of field `data` twice, which is incorrect

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

Commit messages:
 - 8369860: [lworld] Javac generates duplicate initializer code

Changes: https://git.openjdk.org/valhalla/pull/1686/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1686&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369860
  Stats: 149 lines in 3 files changed: 66 ins; 60 del; 23 mod
  Patch: https://git.openjdk.org/valhalla/pull/1686.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1686/head:pull/1686

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

From qamai at openjdk.org  Sat Oct 18 19:31:20 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 18 Oct 2025 19:31:20 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v4]
In-Reply-To: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
Message-ID: <mWbWFN-vE3sCqTYwt64RuH6tob5BfSANZDH5SDCpObU=.3f0a1e52-dc6f-4e2c-b242-7359ec640149@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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Several fixes
 - fix gc barrier
 - Merge branch 'lworld' into flatfield
 - fix merge, assert GC barriers
 - Merge branch 'lworld' into flatfield
 - fix release build
 - small fix StoreFlatNode::size_of
 - add LoadFlatNode and StoreFlatNode

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

Changes: https://git.openjdk.org/valhalla/pull/1518/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1518&range=03
  Stats: 989 lines in 17 files changed: 775 ins; 188 del; 26 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 thartmann at openjdk.org  Sat Oct 18 19:31:21 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Sat, 18 Oct 2025 19:31:21 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <cDnmfPYgLrvZ4bFNtS9F_fH_WfJWzSNFBV770HPTT8M=.1d80023c-b2a9-4844-b4a0-6248de952169@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>
 <cDnmfPYgLrvZ4bFNtS9F_fH_WfJWzSNFBV770HPTT8M=.1d80023c-b2a9-4844-b4a0-6248de952169@github.com>
Message-ID: <l6VJHl8c7rarxFkrsBMR6rZgohxBFaRp1MwSzc8adNg=.394395eb-3edd-47e3-a5b7-d973ee44216e@github.com>

On Thu, 7 Aug 2025 13:31:53 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> 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 ...
>
> @TobiHartmann Ah dummy mistake, I missed the `NOT_PRODUCT` guard, fixed it now.

Hi @merykitty Sorry for the delay in reviewing this, I was busy with the the [array metadata refactoring](https://github.com/openjdk/valhalla/pull/1452) and hunting down nasty AArch64 crashes ([JDK-8364579](https://bugs.openjdk.org/browse/JDK-8364579) / [JDK-8365996](https://bugs.openjdk.org/browse/JDK-8365996)). This is great work! I see that you converted the PR back to draft, is it still ready to review?

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

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

From qamai at openjdk.org  Sat Oct 18 19:31:21 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 18 Oct 2025 19:31:21 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <l6VJHl8c7rarxFkrsBMR6rZgohxBFaRp1MwSzc8adNg=.394395eb-3edd-47e3-a5b7-d973ee44216e@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>
 <cDnmfPYgLrvZ4bFNtS9F_fH_WfJWzSNFBV770HPTT8M=.1d80023c-b2a9-4844-b4a0-6248de952169@github.com>
 <l6VJHl8c7rarxFkrsBMR6rZgohxBFaRp1MwSzc8adNg=.394395eb-3edd-47e3-a5b7-d973ee44216e@github.com>
Message-ID: <tGHkMBcCCSnJ5iD_J3uk1JK3BuLQG8KI82qmupTrr54=.4104fe9a-8554-44b6-86d4-e4aa25083a4b@github.com>

On Mon, 25 Aug 2025 06:52:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @TobiHartmann Ah dummy mistake, I missed the `NOT_PRODUCT` guard, fixed it now.
>
> Hi @merykitty Sorry for the delay in reviewing this, I was busy with the the [array metadata refactoring](https://github.com/openjdk/valhalla/pull/1452) and hunting down nasty AArch64 crashes ([JDK-8364579](https://bugs.openjdk.org/browse/JDK-8364579) / [JDK-8365996](https://bugs.openjdk.org/browse/JDK-8365996)). This is great work! I see that you converted the PR back to draft, is it still ready to review?

@TobiHartmann Hi Tobias, I am having difficulties understanding how our current flat accesses deal with GC barriers. IIUC, every time an access is made to a memory region that may contain an oop, we need a GC barrier (which itself may be a nop). However, looking at our current implementation, I only see that being handled for G1GC with `StoreLSpecialNode`. For Serial, Parralel, and Shenandoah, the access is made as if the memory is a long, which I assume would not trigger any GC barrier. When I try to add an assertion that a flat access that contains an oop cannot be made for anything other than G1GC, the assert fires.

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

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

From thartmann at openjdk.org  Sat Oct 18 19:31:22 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Sat, 18 Oct 2025 19:31:22 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <tGHkMBcCCSnJ5iD_J3uk1JK3BuLQG8KI82qmupTrr54=.4104fe9a-8554-44b6-86d4-e4aa25083a4b@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>
 <cDnmfPYgLrvZ4bFNtS9F_fH_WfJWzSNFBV770HPTT8M=.1d80023c-b2a9-4844-b4a0-6248de952169@github.com>
 <l6VJHl8c7rarxFkrsBMR6rZgohxBFaRp1MwSzc8adNg=.394395eb-3edd-47e3-a5b7-d973ee44216e@github.com>
 <tGHkMBcCCSnJ5iD_J3uk1JK3BuLQG8KI82qmupTrr54=.4104fe9a-8554-44b6-86d4-e4aa25083a4b@github.com>
Message-ID: <Daz55JVnP_otur_6mngoCTuMG_qj41uKTFWk70Atgtw=.6152829b-8427-4035-a0bb-1f981d86d0e7@github.com>

On Sat, 4 Oct 2025 11:52:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi @merykitty Sorry for the delay in reviewing this, I was busy with the the [array metadata refactoring](https://github.com/openjdk/valhalla/pull/1452) and hunting down nasty AArch64 crashes ([JDK-8364579](https://bugs.openjdk.org/browse/JDK-8364579) / [JDK-8365996](https://bugs.openjdk.org/browse/JDK-8365996)). This is great work! I see that you converted the PR back to draft, is it still ready to review?
>
> @TobiHartmann Hi Tobias, I am having difficulties understanding how our current flat accesses deal with GC barriers. IIUC, every time an access is made to a memory region that may contain an oop, we need a GC barrier (which itself may be a nop). However, looking at our current implementation, I only see that being handled for G1GC with `StoreLSpecialNode`. For Serial, Parralel, and Shenandoah, the access is made as if the memory is a long, which I assume would not trigger any GC barrier. When I try to add an assertion that a flat access that contains an oop cannot be made for anything other than G1GC, the assert fires.

@merykitty Hi Quan-Anh, sorry for the delay, I missed this message. 

> I only see that being handled for G1GC with StoreLSpecialNode

G1 is handled specially because of late barrier expansion:
https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/opto/inlinetypenode.cpp#L660-L693

For the other GCs, we emit the barriers already during parsing (the information is propagated via `C2ParseAccess`):
https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.cpp#L40-L53
and
https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/gc/shared/c2/modRefBarrierSetC2.cpp#L59-L70

I added this with https://github.com/openjdk/valhalla/pull/1318 and as mentioned in the PR, this is a bit of a hacky first implementation. We should refactor / improve this later (tracked by [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865)).

Does that help?

If you get a chance, could you merge this PR with latest `lworld`? We see some issues that look similar to this and would like to verify if your patch helps. Thanks!

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

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

From qamai at openjdk.org  Sat Oct 18 19:31:22 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 18 Oct 2025 19:31:22 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <Daz55JVnP_otur_6mngoCTuMG_qj41uKTFWk70Atgtw=.6152829b-8427-4035-a0bb-1f981d86d0e7@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>
 <cDnmfPYgLrvZ4bFNtS9F_fH_WfJWzSNFBV770HPTT8M=.1d80023c-b2a9-4844-b4a0-6248de952169@github.com>
 <l6VJHl8c7rarxFkrsBMR6rZgohxBFaRp1MwSzc8adNg=.394395eb-3edd-47e3-a5b7-d973ee44216e@github.com>
 <tGHkMBcCCSnJ5iD_J3uk1JK3BuLQG8KI82qmupTrr54=.4104fe9a-8554-44b6-86d4-e4aa25083a4b@github.com>
 <Daz55JVnP_otur_6mngoCTuMG_qj41uKTFWk70Atgtw=.6152829b-8427-4035-a0bb-1f981d86d0e7@github.com>
Message-ID: <s5g9rAftg1MgkGDuiCT85tS296wy69jABNZTUyVW7s4=.b3185b6c-308a-4666-846c-264bbae70e6a@github.com>

On Wed, 15 Oct 2025 11:01:53 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @TobiHartmann Hi Tobias, I am having difficulties understanding how our current flat accesses deal with GC barriers. IIUC, every time an access is made to a memory region that may contain an oop, we need a GC barrier (which itself may be a nop). However, looking at our current implementation, I only see that being handled for G1GC with `StoreLSpecialNode`. For Serial, Parralel, and Shenandoah, the access is made as if the memory is a long, which I assume would not trigger any GC barrier. When I try to add an assertion that a flat access that contains an oop cannot be made for anything other than G1GC, the assert fires.
>
> @merykitty Hi Quan-Anh, sorry for the delay, I missed this message. 
> 
>> I only see that being handled for G1GC with StoreLSpecialNode
> 
> G1 is handled specially because of late barrier expansion:
> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/opto/inlinetypenode.cpp#L660-L693
> 
> For the other GCs, we emit the barriers already during parsing (the information is propagated via `C2ParseAccess`):
> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.cpp#L40-L53
> and
> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/gc/shared/c2/modRefBarrierSetC2.cpp#L59-L70
> 
> I added this with https://github.com/openjdk/valhalla/pull/1318 and as mentioned in the PR, this is a bit of a hacky first implementation. We should refactor / improve this later (tracked by [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865)).
> 
> Does that help?
> 
> If you get a chance, could you merge this PR with latest `lworld`? We see some issues that look similar to this and would like to verify if your patch helps. Thanks!

@TobiHartmann Thanks a lot for your help, I am working on this. However, I think that would mean Shenandoah is broken as I see no similar handling in `ShenandoahBarrierSetC2`?

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

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

From thartmann at openjdk.org  Sat Oct 18 19:31:22 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Sat, 18 Oct 2025 19:31:22 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <s5g9rAftg1MgkGDuiCT85tS296wy69jABNZTUyVW7s4=.b3185b6c-308a-4666-846c-264bbae70e6a@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>
 <cDnmfPYgLrvZ4bFNtS9F_fH_WfJWzSNFBV770HPTT8M=.1d80023c-b2a9-4844-b4a0-6248de952169@github.com>
 <l6VJHl8c7rarxFkrsBMR6rZgohxBFaRp1MwSzc8adNg=.394395eb-3edd-47e3-a5b7-d973ee44216e@github.com>
 <tGHkMBcCCSnJ5iD_J3uk1JK3BuLQG8KI82qmupTrr54=.4104fe9a-8554-44b6-86d4-e4aa25083a4b@github.com>
 <Daz55JVnP_otur_6mngoCTuMG_qj41uKTFWk70Atgtw=.6152829b-8427-4035-a0bb-1f981d86d0e7@github.com>
 <s5g9rAftg1MgkGDuiCT85tS296wy69jABNZTUyVW7s4=.b3185b6c-308a-4666-846c-264bbae70e6a@github.com>
Message-ID: <ta8lOO9MYcSrxEgqDWthBCq7DjQIElz-arOPxrmBC1w=.192d24d7-0d61-480e-bf5e-1f9a76694a85@github.com>

On Thu, 16 Oct 2025 02:54:36 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> @merykitty Hi Quan-Anh, sorry for the delay, I missed this message. 
>> 
>>> I only see that being handled for G1GC with StoreLSpecialNode
>> 
>> G1 is handled specially because of late barrier expansion:
>> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/opto/inlinetypenode.cpp#L660-L693
>> 
>> For the other GCs, we emit the barriers already during parsing (the information is propagated via `C2ParseAccess`):
>> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.cpp#L40-L53
>> and
>> https://github.com/openjdk/valhalla/blob/c1774b0b6b129623f77fbb7096d332565f148677/src/hotspot/share/gc/shared/c2/modRefBarrierSetC2.cpp#L59-L70
>> 
>> I added this with https://github.com/openjdk/valhalla/pull/1318 and as mentioned in the PR, this is a bit of a hacky first implementation. We should refactor / improve this later (tracked by [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865)).
>> 
>> Does that help?
>> 
>> If you get a chance, could you merge this PR with latest `lworld`? We see some issues that look similar to this and would like to verify if your patch helps. Thanks!
>
> @TobiHartmann Thanks a lot for your help, I am working on this. However, I think that would mean Shenandoah is broken as I see no similar handling in `ShenandoahBarrierSetC2`?

@merykitty Yes, I think that's true. I only implemented Oracle-supported builds/configurations for now. Thank you!

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

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

From qamai at openjdk.org  Sat Oct 18 19:31:23 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 18 Oct 2025 19:31:23 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v2]
In-Reply-To: <ta8lOO9MYcSrxEgqDWthBCq7DjQIElz-arOPxrmBC1w=.192d24d7-0d61-480e-bf5e-1f9a76694a85@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>
 <cDnmfPYgLrvZ4bFNtS9F_fH_WfJWzSNFBV770HPTT8M=.1d80023c-b2a9-4844-b4a0-6248de952169@github.com>
 <l6VJHl8c7rarxFkrsBMR6rZgohxBFaRp1MwSzc8adNg=.394395eb-3edd-47e3-a5b7-d973ee44216e@github.com>
 <tGHkMBcCCSnJ5iD_J3uk1JK3BuLQG8KI82qmupTrr54=.4104fe9a-8554-44b6-86d4-e4aa25083a4b@github.com>
 <Daz55JVnP_otur_6mngoCTuMG_qj41uKTFWk70Atgtw=.6152829b-8427-4035-a0bb-1f981d86d0e7@github.com>
 <s5g9rAftg1MgkGDuiCT85tS296wy69jABNZTUyVW7s4=.b3185b6c-308a-4666-846c-264bbae70e6a@github.com>
 <ta8lOO9MYcSrxEgqDWthBCq7DjQIElz-arOPxrmBC1w=.192d24d7-0d61-480e-bf5e-1f9a76694a85@github.com>
Message-ID: <Tm9PDI9BBk_IOkvcZH-sfiDELSKbwXiy_D3LVbwgy9A=.91da824c-586a-43df-8957-abfcb59dd522@github.com>

On Thu, 16 Oct 2025 08:25:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> @TobiHartmann Thanks a lot for your help, I am working on this. However, I think that would mean Shenandoah is broken as I see no similar handling in `ShenandoahBarrierSetC2`?
>
> @merykitty Yes, I think that's true. I only implemented Oracle-supported builds/configurations for now. Thank you!

@TobiHartmann Please review this PR, thanks a lot.

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

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

From qamai at openjdk.org  Sun Oct 19 17:19:19 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 19 Oct 2025 17:19:19 GMT
Subject: [lworld] RFR: 8370195: [lworld] Constant-fold _layout_kind loads from
 constant FlatArrayKlass
Message-ID: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>

Hi,

The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.

Please leave your reviews, thanks a lot.

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

Commit messages:
 - constant fold layout kind loads

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

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

From qamai at openjdk.org  Sun Oct 19 17:19:20 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 19 Oct 2025 17:19:20 GMT
Subject: [lworld] RFR: 8370195: [lworld] Constant-fold _layout_kind loads
 from constant FlatArrayKlass
In-Reply-To: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
References: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
Message-ID: <Tt0dfBfsRJrr3pplml2G-aklXwPu3Z_lyPxbDXdWkNo=.ec23fb6a-6bd0-4144-b306-fdcd04e71ee6@github.com>

On Sun, 19 Oct 2025 17:13:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.
> 
> Please leave your reviews, thanks a lot.

Benchmark result:

    Benchmark                          Mode  Cnt       Score      Error  Units
    HoistArrayChecks.atomicHoisted     avgt   15  358138.658 ? 4705.964  ns/op
    HoistArrayChecks.atomicNaive       avgt   15  576348.282 ? 3179.475  ns/op
    HoistArrayChecks.nonAtomicHoisted  avgt   15  292872.250 ? 9536.215  ns/op
    HoistArrayChecks.nonAtomicNaive    avgt   15  296264.018 ? 2185.786  ns/op
    HoistArrayChecks.nullableHoisted   avgt   15  479879.297 ? 1753.756  ns/op
    HoistArrayChecks.nullableNaive     avgt   15  675267.274 ? 4161.829  ns/op

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

PR Comment: https://git.openjdk.org/valhalla/pull/1687#issuecomment-3419817433

From david.1993grajales at gmail.com  Sun Oct 19 22:56:45 2025
From: david.1993grajales at gmail.com (david Grajales)
Date: Sun, 19 Oct 2025 17:56:45 -0500
Subject: how passing value types will work?
Message-ID: <CADFQZ756qKTKG+P9A3C_Y4-DFgiFeYZgy+VpxYukqQ1Jc621dw@mail.gmail.com>

Java always passes by value. When someone passes a primitive to a method it
passes a copy of the value of the primitive, when one pass a reference type
what is really being passed it's a copy of the "value" of the object (just
happens to be the value of an object is its reference)

When a value object (let's say a value record) is being passed to a method,
does it pass a copy of the values or a reference to where the values are in
memory?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251019/ebcd73a8/attachment.htm>

From liach at openjdk.org  Mon Oct 20 04:03:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 Oct 2025 04:03:45 GMT
Subject: [lworld] RFR: 8370195: [lworld] Constant-fold _layout_kind loads
 from constant FlatArrayKlass
In-Reply-To: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
References: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
Message-ID: <ychd_Oco0K9o59w0uVm_ojZaWqOfyDkG-t1InEJwMjU=.52dc1e19-e38e-419f-a62a-d305ed86b44b@github.com>

On Sun, 19 Oct 2025 17:13:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.
> 
> Please leave your reviews, thanks a lot.

I wonder if the work to constant fold Unsafe.arrayLayout is similar to this - this is currently a bottleneck in core libraries.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1687#issuecomment-3420458613

From liangchenblue at gmail.com  Mon Oct 20 04:11:30 2025
From: liangchenblue at gmail.com (Chen Liang)
Date: Sun, 19 Oct 2025 23:11:30 -0500
Subject: how passing value types will work?
In-Reply-To: <CADFQZ756qKTKG+P9A3C_Y4-DFgiFeYZgy+VpxYukqQ1Jc621dw@mail.gmail.com>
References: <CADFQZ756qKTKG+P9A3C_Y4-DFgiFeYZgy+VpxYukqQ1Jc621dw@mail.gmail.com>
Message-ID: <CABe8uE2d9+n8wZeNUpYNiwNoMmJguQJJNcoQ6JcRduRz7y=u2A@mail.gmail.com>

Good question. The latest valhalla spec is as non-invasive as possible: we
are still passing a value representing the reference pointer to an
immutable value object, which is identical to a copy of the values. This
will be the case for JEP 401, Value Objects.

Ideally, we want the reference to where the values are in memory to be
usable, given this is the most memory-efficient representation. This is
largely equivalent to a copy of the values given value objects are
immutable, except they are different when a value object is stored in a
mutable field in an identity object. In such cases, we may observe a "tear"
when we read the reference to the memory location, meaning we can observe a
value object that was composed from the result of different writes due to
instruction reordering and CPU caches.

We currently prototype to allow such inconsistency to happen by declaring a
value object as "loosely consistent", so all value object instance in the
cartesian product of all legal individual field values are all legal and
expected by programs.


On Sun, Oct 19, 2025 at 7:51?PM david Grajales <david.1993grajales at gmail.com>
wrote:

> Java always passes by value. When someone passes a primitive to a method
> it passes a copy of the value of the primitive, when one pass a reference
> type what is really being passed it's a copy of the "value" of the object
> (just happens to be the value of an object is its reference)
>
> When a value object (let's say a value record) is being passed to a
> method, does it pass a copy of the values or a reference to where the
> values are in memory?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251019/238fb145/attachment.htm>

From thartmann at openjdk.org  Mon Oct 20 05:25:35 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 20 Oct 2025 05:25:35 GMT
Subject: [lworld] RFR: 8370195: [lworld] Constant-fold _layout_kind loads
 from constant FlatArrayKlass
In-Reply-To: <ychd_Oco0K9o59w0uVm_ojZaWqOfyDkG-t1InEJwMjU=.52dc1e19-e38e-419f-a62a-d305ed86b44b@github.com>
References: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
 <ychd_Oco0K9o59w0uVm_ojZaWqOfyDkG-t1InEJwMjU=.52dc1e19-e38e-419f-a62a-d305ed86b44b@github.com>
Message-ID: <_IuzZs7BImbwdZAdHBf1H8z78K7WPHOuvkBhxj9V70M=.e0a991fb-cbfb-40da-a6df-2cc59eab234b@github.com>

On Mon, 20 Oct 2025 04:01:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi,
>> 
>> The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.
>> 
>> Please leave your reviews, thanks a lot.
>
> I wonder if the work to constant fold Unsafe.arrayLayout is similar to this - this is currently a bottleneck in core libraries.

@liach That one ([JDK-8369835](https://bugs.openjdk.org/browse/JDK-8369835)) requires an intrinsic for the Unsafe method which is currently implemented in C++ code (there's no Java code that could be optimized/folded).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1687#issuecomment-3420612504

From thartmann at openjdk.org  Mon Oct 20 05:58:29 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 20 Oct 2025 05:58:29 GMT
Subject: [lworld] RFR: 8367405: [lworld] C2 compilation fails with empty
 program detected during loop optimization
In-Reply-To: <nmya9pXUOg_oIesAvCO-ahc5WHRepMKPu4xbAHa223A=.c431dac2-2d41-402a-b5c9-ba77e83ceaa0@github.com>
References: <nmya9pXUOg_oIesAvCO-ahc5WHRepMKPu4xbAHa223A=.c431dac2-2d41-402a-b5c9-ba77e83ceaa0@github.com>
Message-ID: <KRCQ2EW9T3XeUlv5gyP9utPcybDNSfjLjkgkLhdrWes=.2bcae898-240f-49ec-9765-5ef22f41878f@github.com>

On Mon, 13 Oct 2025 15:38:11 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> The symptom is that an empty program is detected during loop optimization when running `compiler/stringopts/TestStackedConcatsAppendUncommonTrap.java` with `-XX:-TieredCompilation -XX:+StressUnstableIfTraps`.
> 
> ## Cause
> The cause's origin is string concatenation failing to bail out. More specifically, at the end of `StringConcat::validate_control_flow`, while validating the results, we miss processing a `Phi` node and wrongly let the validation pass. The starting point is this:
> 
> <img width="938" height="820" alt="image" src="https://github.com/user-attachments/assets/b7a3ee17-33d7-4ecb-8fb0-fb962a831f04" />
> 
> While processing the `Proj` node and going through its outputs, we reach the `CheckCastPP` and add its uses to the worklist (basically only the `Phi` node).
> 
> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/opto/stringopts.cpp#L1138-L1145
> 
> Surprisingly we don't add the `CheckCastPP` node itself. 
> In one of the next worklist iterations we process the `Phi` node and its uses and none of them make the validation fail.
> 
> Side note: `CheckCastPP` is added as additional profiling in Valhalla when parsing `acmp`
> https://github.com/openjdk/valhalla/blob/23dc125e5791238a97923108b77c6fc0b59d894f/src/hotspot/share/opto/parse2.cpp#L2098-L2102
> 
> On the other hand in mainline `CheckCastPP` is not added and when processing the `Proj`, `Phi` is encountered as one of its uses and the validation fails straight away.
> 
> ## Fix
> 
> Unfortunately this looks yet like another patch in the stacked optimisation's pattern matching "denylist" approach. As mentioned by @danielogh and @robcasloz in the JBS issue, a long-term better approach would be to limit the concatenation to known safe cases.
> 
> While waiting for that, a reasonable ad-hoc solution for this Valhalla case is to add a specific `CheckCastPP` case to the validation of uses that also adds itself to the worklist. This will include `CheckCastPP` nodes added by Valhalla's additional profiling (in all fairness this doesn't exclude potential other origins, but the extend and outcome in terms of concatenation optimisation failures should be quite limited).
> Note: `CastPP` has to be treated differently: it seems that not adding itself in the worklist was done on purpose for `CastPP` to skip string null check `Phi` nodes among other things.
> 
> ## Testing
> 
> Tests: tier 1-3

Thanks for the detailed analysis Damon! The fix looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1675#pullrequestreview-3355093565

From dfenacci at openjdk.org  Mon Oct 20 07:22:45 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 20 Oct 2025 07:22:45 GMT
Subject: [lworld] RFR: 8367405: [lworld] C2 compilation fails with empty
 program detected during loop optimization
In-Reply-To: <KRCQ2EW9T3XeUlv5gyP9utPcybDNSfjLjkgkLhdrWes=.2bcae898-240f-49ec-9765-5ef22f41878f@github.com>
References: <nmya9pXUOg_oIesAvCO-ahc5WHRepMKPu4xbAHa223A=.c431dac2-2d41-402a-b5c9-ba77e83ceaa0@github.com>
 <KRCQ2EW9T3XeUlv5gyP9utPcybDNSfjLjkgkLhdrWes=.2bcae898-240f-49ec-9765-5ef22f41878f@github.com>
Message-ID: <vg7GHR0dLfyTYYB1QeXd6WuAXBStJRPCkZR8nKJ0CI8=.2fb749e5-993b-466d-a0a7-476e0d52e0e7@github.com>

On Mon, 20 Oct 2025 05:56:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> ## Issue
>> The symptom is that an empty program is detected during loop optimization when running `compiler/stringopts/TestStackedConcatsAppendUncommonTrap.java` with `-XX:-TieredCompilation -XX:+StressUnstableIfTraps`.
>> 
>> ## Cause
>> The cause's origin is string concatenation failing to bail out. More specifically, at the end of `StringConcat::validate_control_flow`, while validating the results, we miss processing a `Phi` node and wrongly let the validation pass. The starting point is this:
>> 
>> <img width="938" height="820" alt="image" src="https://github.com/user-attachments/assets/b7a3ee17-33d7-4ecb-8fb0-fb962a831f04" />
>> 
>> While processing the `Proj` node and going through its outputs, we reach the `CheckCastPP` and add its uses to the worklist (basically only the `Phi` node).
>> 
>> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/opto/stringopts.cpp#L1138-L1145
>> 
>> Surprisingly we don't add the `CheckCastPP` node itself. 
>> In one of the next worklist iterations we process the `Phi` node and its uses and none of them make the validation fail.
>> 
>> Side note: `CheckCastPP` is added as additional profiling in Valhalla when parsing `acmp`
>> https://github.com/openjdk/valhalla/blob/23dc125e5791238a97923108b77c6fc0b59d894f/src/hotspot/share/opto/parse2.cpp#L2098-L2102
>> 
>> On the other hand in mainline `CheckCastPP` is not added and when processing the `Proj`, `Phi` is encountered as one of its uses and the validation fails straight away.
>> 
>> ## Fix
>> 
>> Unfortunately this looks yet like another patch in the stacked optimisation's pattern matching "denylist" approach. As mentioned by @danielogh and @robcasloz in the JBS issue, a long-term better approach would be to limit the concatenation to known safe cases.
>> 
>> While waiting for that, a reasonable ad-hoc solution for this Valhalla case is to add a specific `CheckCastPP` case to the validation of uses that also adds itself to the worklist. This will include `CheckCastPP` nodes added by Valhalla's additional profiling (in all fairness this doesn't exclude potential other origins, but the extend and outcome in terms of concatenation optimisation failures should be quite limited).
>> Note: `CastPP` has to be treated differently: it seems that not adding itself in the worklist was done on purpose for `CastPP` to skip string null check `Phi` nodes among other things.
>> 
>> ## Testing
>> 
>> Tests: tier 1-3
>
> Thanks for the detailed analysis Damon! The fix looks good to me.

Thanks for the review @TobiHartmann.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1675#issuecomment-3420877016

From dfenacci at openjdk.org  Mon Oct 20 07:22:46 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 20 Oct 2025 07:22:46 GMT
Subject: [lworld] Integrated: 8367405: [lworld] C2 compilation fails with empty
 program detected during loop optimization
In-Reply-To: <nmya9pXUOg_oIesAvCO-ahc5WHRepMKPu4xbAHa223A=.c431dac2-2d41-402a-b5c9-ba77e83ceaa0@github.com>
References: <nmya9pXUOg_oIesAvCO-ahc5WHRepMKPu4xbAHa223A=.c431dac2-2d41-402a-b5c9-ba77e83ceaa0@github.com>
Message-ID: <ZdkmQ1IVRyVJFRPkq6W23zL7rfRvcXdL03TKvSjkz5I=.7c17a572-190e-4482-8614-dab849aade6f@github.com>

On Mon, 13 Oct 2025 15:38:11 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> ## Issue
> The symptom is that an empty program is detected during loop optimization when running `compiler/stringopts/TestStackedConcatsAppendUncommonTrap.java` with `-XX:-TieredCompilation -XX:+StressUnstableIfTraps`.
> 
> ## Cause
> The cause's origin is string concatenation failing to bail out. More specifically, at the end of `StringConcat::validate_control_flow`, while validating the results, we miss processing a `Phi` node and wrongly let the validation pass. The starting point is this:
> 
> <img width="938" height="820" alt="image" src="https://github.com/user-attachments/assets/b7a3ee17-33d7-4ecb-8fb0-fb962a831f04" />
> 
> While processing the `Proj` node and going through its outputs, we reach the `CheckCastPP` and add its uses to the worklist (basically only the `Phi` node).
> 
> https://github.com/openjdk/valhalla/blob/708b4f92431df90c115dac840fb8194ec3aac3fe/src/hotspot/share/opto/stringopts.cpp#L1138-L1145
> 
> Surprisingly we don't add the `CheckCastPP` node itself. 
> In one of the next worklist iterations we process the `Phi` node and its uses and none of them make the validation fail.
> 
> Side note: `CheckCastPP` is added as additional profiling in Valhalla when parsing `acmp`
> https://github.com/openjdk/valhalla/blob/23dc125e5791238a97923108b77c6fc0b59d894f/src/hotspot/share/opto/parse2.cpp#L2098-L2102
> 
> On the other hand in mainline `CheckCastPP` is not added and when processing the `Proj`, `Phi` is encountered as one of its uses and the validation fails straight away.
> 
> ## Fix
> 
> Unfortunately this looks yet like another patch in the stacked optimisation's pattern matching "denylist" approach. As mentioned by @danielogh and @robcasloz in the JBS issue, a long-term better approach would be to limit the concatenation to known safe cases.
> 
> While waiting for that, a reasonable ad-hoc solution for this Valhalla case is to add a specific `CheckCastPP` case to the validation of uses that also adds itself to the worklist. This will include `CheckCastPP` nodes added by Valhalla's additional profiling (in all fairness this doesn't exclude potential other origins, but the extend and outcome in terms of concatenation optimisation failures should be quite limited).
> Note: `CastPP` has to be treated differently: it seems that not adding itself in the worklist was done on purpose for `CastPP` to skip string null check `Phi` nodes among other things.
> 
> ## Testing
> 
> Tests: tier 1-3

This pull request has now been integrated.

Changeset: 0b87efa5
Author:    Damon Fenacci <dfenacci at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0b87efa5ef4b8595529ade06984ec6f59a7e271f
Stats:     5 lines in 2 files changed: 3 ins; 2 del; 0 mod

8367405: [lworld] C2 compilation fails with empty program detected during loop optimization

Reviewed-by: thartmann

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

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

From thartmann at openjdk.org  Mon Oct 20 08:10:40 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 20 Oct 2025 08:10:40 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v4]
In-Reply-To: <mWbWFN-vE3sCqTYwt64RuH6tob5BfSANZDH5SDCpObU=.3f0a1e52-dc6f-4e2c-b242-7359ec640149@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
 <mWbWFN-vE3sCqTYwt64RuH6tob5BfSANZDH5SDCpObU=.3f0a1e52-dc6f-4e2c-b242-7359ec640149@github.com>
Message-ID: <V7g9KvqosbfPagU1mLHzMzAkORkpgQCsMC9KfTvD1fw=.716d6252-5f2f-4c6a-9a50-6e792ad55743@github.com>

On Sat, 18 Oct 2025 19:31:20 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 with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Several fixes
>  - fix gc barrier
>  - Merge branch 'lworld' into flatfield
>  - fix merge, assert GC barriers
>  - Merge branch 'lworld' into flatfield
>  - fix release build
>  - small fix StoreFlatNode::size_of
>  - add LoadFlatNode and StoreFlatNode

I did some quick testing and I'm seeing this failure:


runtime/valhalla/inlinetypes/verifier/RedefineStrictFieldsTest.java
-Xcomp -XX:-TieredCompilation

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f195cbd8da5, pid=1416875, tid=1416894
#
# JRE version: Java(TM) SE Runtime Environment (26.0) (fastdebug build 26-jep401ea2-2025-10-20-0458161.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-jep401ea2-2025-10-20-0458161.tobias.hartmann.valhalla2, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xdcada5]  ConnectionGraph::has_ea_local_in_scope(SafePointNode*)+0x115

Current CompileTask:
C2:7013 1605    b        java.lang.VersionProps::parseVersionNumbers (154 bytes)

Stack: [0x00007f1948721000,0x00007f1948821000],  sp=0x00007f194881ba70,  free space=1002k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xdcada5]  ConnectionGraph::has_ea_local_in_scope(SafePointNode*)+0x115  (callnode.hpp:383)
V  [libjvm.so+0xde6e68]  ConnectionGraph::compute_escape()+0x2e88  (escape.cpp:469)
V  [libjvm.so+0xde734a]  ConnectionGraph::do_analysis(Compile*, PhaseIterGVN*)+0x15a  (escape.cpp:120)
V  [libjvm.so+0xbcbe4d]  Compile::Optimize()+0x65d  (compile.cpp:2942)
V  [libjvm.so+0xbcf86f]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x207f  (compile.cpp:878)
V  [libjvm.so+0x9dc0b3]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x483  (c2compiler.cpp:149)
V  [libjvm.so+0xbdee38]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb48  (compileBroker.cpp:2345)
V  [libjvm.so+0xbdffc0]  CompileBroker::compiler_thread_loop()+0x530  (compileBroker.cpp:1989)
V  [libjvm.so+0x11701db]  JavaThread::thread_main_inner()+0x13b  (javaThread.cpp:776)
V  [libjvm.so+0x1c23c56]  Thread::call_run()+0xb6  (thread.cpp:243)
V  [libjvm.so+0x185eb58]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:898)


The `serviceability/jvmti/valhalla/` tests also fail with the same SIGSEGV when executed with `-Xcomp -XX:-TieredCompilation`.

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

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

From qamai at openjdk.org  Mon Oct 20 08:10:36 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 20 Oct 2025 08:10:36 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v5]
In-Reply-To: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
Message-ID: <Sy4EbGkwlrz1fKQXdOcuVK_UjAT3f8W10SUzjxLImGU=.895e489c-03a6-4bee-9dbe-77af095a757c@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 two additional commits since the last revision:

 - revert redundant changes
 - revert redundant changes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1518/files
  - new: https://git.openjdk.org/valhalla/pull/1518/files/43729677..7c51d242

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

  Stats: 4 lines in 2 files changed: 0 ins; 3 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 thartmann at openjdk.org  Mon Oct 20 08:10:48 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 20 Oct 2025 08:10:48 GMT
Subject: [lworld] RFR: 8370195: [lworld] Constant-fold _layout_kind loads
 from constant FlatArrayKlass
In-Reply-To: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
References: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
Message-ID: <c8plog5bsX8fYNEkbl1HrK4y0KICFBVRbEr1zRj7kqY=.e118f37e-7927-4df7-a741-d2aa1d2202fa@github.com>

On Sun, 19 Oct 2025 17:13:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.
> 
> Please leave your reviews, thanks a lot.

Looks good to me. Thanks for fixing!

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java line 3778:

> 3776: 
> 3777:     @Test
> 3778:     @IR(applyIf = {"UseArrayLoadStoreProfile", "true"},

Maybe add a small comment here explaining what the test / IR rule is supposed to catch.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1687#pullrequestreview-3355379438
PR Review Comment: https://git.openjdk.org/valhalla/pull/1687#discussion_r2444098599

From chagedorn at openjdk.org  Mon Oct 20 08:48:33 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 20 Oct 2025 08:48:33 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks
In-Reply-To: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
Message-ID: <60B4MRWDJhS-wMpIAhz_8msdcM6FqzMTYU5ZVJIFHZ0=.f85a1a9f-d4ef-4070-a812-8a24e918b35b@github.com>

On Fri, 17 Oct 2025 07:59:24 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This PR mirrors the changes made to [the compiler](https://github.com/openjdk/valhalla/pull/1681) `jtreg` testing setup ([issue](https://bugs.openjdk.org/browse/JDK-8369437)).
> 
> **Concretely:**
> * Split multiple (independent) `@run`s into separate `@test` blocks, specifying new IDs where appropriate.
> * Added packages where we missed them for consistency. This excludes places where the test setup does not allow for packages or for tests that are disabled (some of which don't compile, as our model is evolving). 
> * Changed `@run main/othervm` into `@run main` when there was no flag passed.
> 
> **Impact:**
> 
> I compared machine execution time in tiers 1-4 to `jdk-26-valhalla+1-89` (which my changes are based on). 
> 
> | | lworld | lworld + patch | improvement
> -- | -- | -- | -- 
> tier1 | 1d 00h 26m 16s |  1d 00h 13m 20s | ~ - 3 mins
> tier2 | 1d 03h 16m 04s | 1d 01h 24m 05s | ~ -2 hours
> tier3 | 2d 17h 29m 13s | 2d 17h 16m 15s | ~ -13 mins
> tier4 | 2d 11h 32m 26s | 2d 01h 05m 40s | ~ -10 hours
> 
> Overall, the trend shows shorter execution times. (And by extension, probably less electricity usage too :))
> 
> Note that the CI ran a few extra tasks at tiers 2,  (two orders of magnitude less compared to the total number of tasks) than my personal run did. I don't think these will impact the results significantly.
> 
> *Disclaimers: these measurements were run before adding packages and getting rid of a few leftover `main/othervm`, although these should not change the results significantly. Also, this is very ad-hoc "benchmarking," variance is not measured.*

Looks good to me but maybe someone from the runtime team should maybe also have a look.

Thanks for following up with this for the runtime tests and providing some numbers! Looks like there were not that many splitting opportunities as with the compiler tests but they still had quite an impact in tier2 and 4, nice!

test/hotspot/jtreg/runtime/valhalla/inlinetypes/ValueTearing.java line 47:

> 45: /*
> 46:  * @test
> 47:  * @ignore

Just checking: Is there a tracking issue to re-enable this test?

test/hotspot/jtreg/runtime/valhalla/inlinetypes/WrappersOffsetTest.java line 26:

> 24: 
> 25: /*
> 26:  * @test

Optional: You could also add ids here.

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1682#pullrequestreview-3355511841
PR Review Comment: https://git.openjdk.org/valhalla/pull/1682#discussion_r2444209669
PR Review Comment: https://git.openjdk.org/valhalla/pull/1682#discussion_r2444211779

From phubner at openjdk.org  Mon Oct 20 08:59:42 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 20 Oct 2025 08:59:42 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks
In-Reply-To: <60B4MRWDJhS-wMpIAhz_8msdcM6FqzMTYU5ZVJIFHZ0=.f85a1a9f-d4ef-4070-a812-8a24e918b35b@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
 <60B4MRWDJhS-wMpIAhz_8msdcM6FqzMTYU5ZVJIFHZ0=.f85a1a9f-d4ef-4070-a812-8a24e918b35b@github.com>
Message-ID: <DTfWkjsUFnzarKBpAEQplY_tEvzm24Gmm9ojt4LF7E8=.ed455825-69a4-427c-ac0b-16e9f30ef6fc@github.com>

On Mon, 20 Oct 2025 08:42:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR mirrors the changes made to [the compiler](https://github.com/openjdk/valhalla/pull/1681) `jtreg` testing setup ([issue](https://bugs.openjdk.org/browse/JDK-8369437)).
>> 
>> **Concretely:**
>> * Split multiple (independent) `@run`s into separate `@test` blocks, specifying new IDs where appropriate.
>> * Added packages where we missed them for consistency. This excludes places where the test setup does not allow for packages or for tests that are disabled (some of which don't compile, as our model is evolving). 
>> * Changed `@run main/othervm` into `@run main` when there was no flag passed.
>> 
>> **Impact:**
>> 
>> I compared machine execution time in tiers 1-4 to `jdk-26-valhalla+1-89` (which my changes are based on). 
>> 
>> | | lworld | lworld + patch | improvement
>> -- | -- | -- | -- 
>> tier1 | 1d 00h 26m 16s |  1d 00h 13m 20s | ~ - 3 mins
>> tier2 | 1d 03h 16m 04s | 1d 01h 24m 05s | ~ -2 hours
>> tier3 | 2d 17h 29m 13s | 2d 17h 16m 15s | ~ -13 mins
>> tier4 | 2d 11h 32m 26s | 2d 01h 05m 40s | ~ -10 hours
>> 
>> Overall, the trend shows shorter execution times. (And by extension, probably less electricity usage too :))
>> 
>> Note that the CI ran a few extra tasks at tiers 2,  (two orders of magnitude less compared to the total number of tasks) than my personal run did. I don't think these will impact the results significantly.
>> 
>> *Disclaimers: these measurements were run before adding packages and getting rid of a few leftover `main/othervm`, although these should not change the results significantly. Also, this is very ad-hoc "benchmarking," variance is not measured.*
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/ValueTearing.java line 47:
> 
>> 45: /*
>> 46:  * @test
>> 47:  * @ignore
> 
> Just checking: Is there a tracking issue to re-enable this test?

I assume it's related to [JDK-8293983](https://bugs.openjdk.org/browse/JDK-8293983).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1682#discussion_r2444252071

From qamai at openjdk.org  Mon Oct 20 09:00:02 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 20 Oct 2025 09:00:02 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v6]
In-Reply-To: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
Message-ID: <L1N0KOYynxFN9yojQHauMSS40HKo-nDXXeIKFOpRnqk=.ba627a40-4aaa-440d-b11e-7beaeef1759f@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:

  Remove flat accesses from sfn_worklist

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1518/files
  - new: https://git.openjdk.org/valhalla/pull/1518/files/7c51d242..81654d3b

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

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 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  Mon Oct 20 09:00:08 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 20 Oct 2025 09:00:08 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v4]
In-Reply-To: <V7g9KvqosbfPagU1mLHzMzAkORkpgQCsMC9KfTvD1fw=.716d6252-5f2f-4c6a-9a50-6e792ad55743@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
 <mWbWFN-vE3sCqTYwt64RuH6tob5BfSANZDH5SDCpObU=.3f0a1e52-dc6f-4e2c-b242-7359ec640149@github.com>
 <V7g9KvqosbfPagU1mLHzMzAkORkpgQCsMC9KfTvD1fw=.716d6252-5f2f-4c6a-9a50-6e792ad55743@github.com>
Message-ID: <yjaBc13C4doBsn389EV94LFjGzhVm2k6NCvbeLM5c7k=.430785ef-ea69-40f9-bff1-fca7d3c36630@github.com>

On Mon, 20 Oct 2025 08:04:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Several fixes
>>  - fix gc barrier
>>  - Merge branch 'lworld' into flatfield
>>  - fix merge, assert GC barriers
>>  - Merge branch 'lworld' into flatfield
>>  - fix release build
>>  - small fix StoreFlatNode::size_of
>>  - add LoadFlatNode and StoreFlatNode
>
> I did some quick testing and I'm seeing this failure:
> 
> 
> runtime/valhalla/inlinetypes/verifier/RedefineStrictFieldsTest.java
> -Xcomp -XX:-TieredCompilation
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f195cbd8da5, pid=1416875, tid=1416894
> #
> # JRE version: Java(TM) SE Runtime Environment (26.0) (fastdebug build 26-jep401ea2-2025-10-20-0458161.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-jep401ea2-2025-10-20-0458161.tobias.hartmann.valhalla2, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0xdcada5]  ConnectionGraph::has_ea_local_in_scope(SafePointNode*)+0x115
> 
> Current CompileTask:
> C2:7013 1605    b        java.lang.VersionProps::parseVersionNumbers (154 bytes)
> 
> Stack: [0x00007f1948721000,0x00007f1948821000],  sp=0x00007f194881ba70,  free space=1002k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xdcada5]  ConnectionGraph::has_ea_local_in_scope(SafePointNode*)+0x115  (callnode.hpp:383)
> V  [libjvm.so+0xde6e68]  ConnectionGraph::compute_escape()+0x2e88  (escape.cpp:469)
> V  [libjvm.so+0xde734a]  ConnectionGraph::do_analysis(Compile*, PhaseIterGVN*)+0x15a  (escape.cpp:120)
> V  [libjvm.so+0xbcbe4d]  Compile::Optimize()+0x65d  (compile.cpp:2942)
> V  [libjvm.so+0xbcf86f]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x207f  (compile.cpp:878)
> V  [libjvm.so+0x9dc0b3]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x483  (c2compiler.cpp:149)
> V  [libjvm.so+0xbdee38]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb48  (compileBroker.cpp:2345)
> V  [libjvm.so+0xbdffc0]  CompileBroker::compiler_thread_loop()+0x530  (compileBroker.cpp:1989)
> V  [libjvm.so+0x11701db]  JavaThread::thread_main_inner()+0x13b  (javaThread.cpp:776)
> V  [libjvm.so+0x1c23c56]  Thread::call_run()+0xb6  (thread.cpp:243)
> V  [libjvm.so+0x185eb58]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:898)
> 
> 
> The `serviceability/jvmti/valhalla/` tests also fail with the same SIGSEGV when executed with `-Xcomp -XX:-TieredCompilation`.

@TobiHartmann Thanks, the issue seems to be due to `ConnectionGraph::has_ea_local_in_scope` trying to process a dead node, it should be fixed now.

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

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

From qamai at openjdk.org  Mon Oct 20 09:05:11 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 20 Oct 2025 09:05:11 GMT
Subject: [lworld] RFR: 8370195: [lworld] Constant-fold _layout_kind loads
 from constant FlatArrayKlass [v2]
In-Reply-To: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
References: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
Message-ID: <637M3vTRPlcF0KDvc88XV9U5gUaghzh9iHY_Mut2N5I=.e11fd0ef-ab94-4d8c-8a84-45e591e520a1@github.com>

> Hi,
> 
> The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.
> 
> Please leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - grammar
 - add comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1687/files
  - new: https://git.openjdk.org/valhalla/pull/1687/files/1c670353..d3fb5867

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

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

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

From qamai at openjdk.org  Mon Oct 20 09:05:12 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 20 Oct 2025 09:05:12 GMT
Subject: [lworld] RFR: 8370195: [lworld] Constant-fold _layout_kind loads
 from constant FlatArrayKlass
In-Reply-To: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
References: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
Message-ID: <4_WtPij7u5FOGgNxHAA92577z6T2oU2QANZRSXV2oSc=.cf2df9f6-663c-4428-887b-3813117551f5@github.com>

On Sun, 19 Oct 2025 17:13:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.
> 
> Please leave your reviews, thanks a lot.

Thanks a lot for the reviews, I will integrate this PR.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1687#issuecomment-3421140347

From phubner at openjdk.org  Mon Oct 20 09:07:23 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 20 Oct 2025 09:07:23 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks [v2]
In-Reply-To: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
Message-ID: <hFHG0JWMnMba0sgFFwV3c2VpiDTwMLB35n2OmaALOzc=.1a6777b3-0594-45da-b67e-70a404e7115d@github.com>

> Hi all,
> 
> This PR mirrors the changes made to [the compiler](https://github.com/openjdk/valhalla/pull/1681) `jtreg` testing setup ([issue](https://bugs.openjdk.org/browse/JDK-8369437)).
> 
> **Concretely:**
> * Split multiple (independent) `@run`s into separate `@test` blocks, specifying new IDs where appropriate.
> * Added packages where we missed them for consistency. This excludes places where the test setup does not allow for packages or for tests that are disabled (some of which don't compile, as our model is evolving). 
> * Changed `@run main/othervm` into `@run main` when there was no flag passed.
> 
> **Impact:**
> 
> I compared machine execution time in tiers 1-4 to `jdk-26-valhalla+1-89` (which my changes are based on). 
> 
> | | lworld | lworld + patch | improvement
> -- | -- | -- | -- 
> tier1 | 1d 00h 26m 16s |  1d 00h 13m 20s | ~ - 3 mins
> tier2 | 1d 03h 16m 04s | 1d 01h 24m 05s | ~ -2 hours
> tier3 | 2d 17h 29m 13s | 2d 17h 16m 15s | ~ -13 mins
> tier4 | 2d 11h 32m 26s | 2d 01h 05m 40s | ~ -10 hours
> 
> Overall, the trend shows shorter execution times. (And by extension, probably less electricity usage too :))
> 
> Note that the CI ran a few extra tasks at tiers 2,  (two orders of magnitude less compared to the total number of tasks) than my personal run did. I don't think these will impact the results significantly.
> 
> *Disclaimers: these measurements were run before adding packages and getting rid of a few leftover `main/othervm`, although these should not change the results significantly. Also, this is very ad-hoc "benchmarking," variance is not measured.*

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

  Add names to WrappersOffsetTest.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1682/files
  - new: https://git.openjdk.org/valhalla/pull/1682/files/4d34f4ee..a3cc5844

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

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

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

From phubner at openjdk.org  Mon Oct 20 09:07:25 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 20 Oct 2025 09:07:25 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks [v2]
In-Reply-To: <60B4MRWDJhS-wMpIAhz_8msdcM6FqzMTYU5ZVJIFHZ0=.f85a1a9f-d4ef-4070-a812-8a24e918b35b@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
 <60B4MRWDJhS-wMpIAhz_8msdcM6FqzMTYU5ZVJIFHZ0=.f85a1a9f-d4ef-4070-a812-8a24e918b35b@github.com>
Message-ID: <xKfIIXSy1HfSICEQdQ7nlmD0O4F3iWo75EE0EhsItvE=.e1a016aa-1381-48b4-9f71-631f81d73fa4@github.com>

On Mon, 20 Oct 2025 08:43:02 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add names to WrappersOffsetTest.
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/WrappersOffsetTest.java line 26:
> 
>> 24: 
>> 25: /*
>> 26:  * @test
> 
> Optional: You could also add ids here.

I added some IDs, they're not pretty but they'll get the job done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1682#discussion_r2444274845

From thartmann at openjdk.org  Mon Oct 20 09:09:40 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 20 Oct 2025 09:09:40 GMT
Subject: [lworld] RFR: 8370195: [lworld] Constant-fold _layout_kind loads
 from constant FlatArrayKlass [v2]
In-Reply-To: <637M3vTRPlcF0KDvc88XV9U5gUaghzh9iHY_Mut2N5I=.e11fd0ef-ab94-4d8c-8a84-45e591e520a1@github.com>
References: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
 <637M3vTRPlcF0KDvc88XV9U5gUaghzh9iHY_Mut2N5I=.e11fd0ef-ab94-4d8c-8a84-45e591e520a1@github.com>
Message-ID: <i0ibZYrSxMYuYdr7hWxUDdlq5Bgw2_7JO0Cwm9byh7I=.16b14ec6-2e81-421b-a5f0-020c37572357@github.com>

On Mon, 20 Oct 2025 09:05:11 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.
>> 
>> Please leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - grammar
>  - add comments

Marked as reviewed by thartmann (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1687#pullrequestreview-3355603625

From phubner at openjdk.org  Mon Oct 20 09:53:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 20 Oct 2025 09:53:50 GMT
Subject: [lworld] RFR: 8369134: [lworld] We should preserve the markWord
 for all GCs [v2]
In-Reply-To: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
References: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
Message-ID: <lEBdTDG6FtzQIMN0CPmiJOk7p03oxhWwHteTYDj3QfA=.6a17dfe2-62ca-4751-9146-27ad612524ae@github.com>

> Hi all,
> 
> This PR follows up on changes made in [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875). I updated the documentation to reflect the new information gained.
> 
> Furthermore, the investigation described in the issue yielded that we _must_ preserve the larval bit explicitly. I introduce a regression test. If we change the mark word preservation condition to `return (!is_unlocked() || !has_no_hash())` (i.e. what we had before), I have confirmed that we will crash a debug VM via failed assertion. Note that ZGC does not require mark word preservation. I've nonetheless decided to include it in case this behaviour is introduced later.
> 
> Testing: tiers 1-3.

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

  WhiteBox API.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1666/files
  - new: https://git.openjdk.org/valhalla/pull/1666/files/cd2c092c..a75ca117

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

  Stats: 55 lines in 1 file changed: 30 ins; 17 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1666.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1666/head:pull/1666

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

From phubner at openjdk.org  Mon Oct 20 09:53:52 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 20 Oct 2025 09:53:52 GMT
Subject: [lworld] RFR: 8369134: [lworld] We should preserve the markWord
 for all GCs [v2]
In-Reply-To: <s26oRQc9xl_goVHO0I_YbNa9x_ruQwXO8WOXd15fZwQ=.5a243930-8ec7-4248-a2ef-323aa94d011c@github.com>
References: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
 <s26oRQc9xl_goVHO0I_YbNa9x_ruQwXO8WOXd15fZwQ=.5a243930-8ec7-4248-a2ef-323aa94d011c@github.com>
Message-ID: <CN_-eLhC2t2eLC6pKiZMtcp36FFw8v1cYfMp1HXsnK4=.2daa1a33-139b-4f32-b58b-2bc357fabf4e@github.com>

On Fri, 17 Oct 2025 20:14:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   WhiteBox API.
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/LarvalMarkWordTest.java line 91:
> 
>> 89:   }
>> 90: 
>> 91:   private static void stressTheGC() {
> 
> There's a WhiteBox FullGC that you can call that might be a reliable way of calling System.gc().

Thanks for letting me know, I've pushed an update.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1666#discussion_r2444460017

From qamai at openjdk.org  Mon Oct 20 11:22:08 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 20 Oct 2025 11:22:08 GMT
Subject: [lworld] Integrated: 8370195: [lworld] Constant-fold _layout_kind
 loads from constant FlatArrayKlass
In-Reply-To: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
References: <Q980H5amBi1jB8swZqBeJAhDFzQrQcWSnpHkdLcta58=.3bd9f4d4-86b7-447f-83e2-557cf6ff6083@github.com>
Message-ID: <g8MEtMDb6O4DsqchiKVWzBtI11OYN9aC5T8Dr4zZ6Qc=.660803fc-80c0-4f5e-8636-3b38c1fcedf3@github.com>

On Sun, 19 Oct 2025 17:13:18 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The load to FlatArrayKlass::_layout_kind can be constant-folded if the receiver is a constant. This eliminates all checks when the array type is known statically or speculated correctly.
> 
> Please leave your reviews, thanks a lot.

This pull request has now been integrated.

Changeset: be252e23
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/be252e2371ced4034ccbcb5c588a465e58c4cc43
Stats:     140 lines in 4 files changed: 138 ins; 0 del; 2 mod

8370195: [lworld] Constant-fold _layout_kind loads from constant FlatArrayKlass

Reviewed-by: thartmann

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

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

From chagedorn at openjdk.org  Mon Oct 20 11:40:39 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 20 Oct 2025 11:40:39 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks [v2]
In-Reply-To: <hFHG0JWMnMba0sgFFwV3c2VpiDTwMLB35n2OmaALOzc=.1a6777b3-0594-45da-b67e-70a404e7115d@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
 <hFHG0JWMnMba0sgFFwV3c2VpiDTwMLB35n2OmaALOzc=.1a6777b3-0594-45da-b67e-70a404e7115d@github.com>
Message-ID: <xrpNIkkCJtskj-AeeLvSabqpFSIIsQzaMV-FJlw_j7Q=.65debacc-06f1-45a9-9acb-58b01615b3f8@github.com>

On Mon, 20 Oct 2025 09:07:23 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR mirrors the changes made to [the compiler](https://github.com/openjdk/valhalla/pull/1681) `jtreg` testing setup ([issue](https://bugs.openjdk.org/browse/JDK-8369437)).
>> 
>> **Concretely:**
>> * Split multiple (independent) `@run`s into separate `@test` blocks, specifying new IDs where appropriate.
>> * Added packages where we missed them for consistency. This excludes places where the test setup does not allow for packages or for tests that are disabled (some of which don't compile, as our model is evolving). 
>> * Changed `@run main/othervm` into `@run main` when there was no flag passed.
>> 
>> **Impact:**
>> 
>> I compared machine execution time in tiers 1-4 to `jdk-26-valhalla+1-89` (which my changes are based on). 
>> 
>> | | lworld | lworld + patch | improvement
>> -- | -- | -- | -- 
>> tier1 | 1d 00h 26m 16s |  1d 00h 13m 20s | ~ - 3 mins
>> tier2 | 1d 03h 16m 04s | 1d 01h 24m 05s | ~ -2 hours
>> tier3 | 2d 17h 29m 13s | 2d 17h 16m 15s | ~ -13 mins
>> tier4 | 2d 11h 32m 26s | 2d 01h 05m 40s | ~ -10 hours
>> 
>> Overall, the trend shows shorter execution times. (And by extension, probably less electricity usage too :))
>> 
>> Note that the CI ran a few extra tasks at tiers 2,  (two orders of magnitude less compared to the total number of tasks) than my personal run did. I don't think these will impact the results significantly.
>> 
>> *Disclaimers: these measurements were run before adding packages and getting rid of a few leftover `main/othervm`, although these should not change the results significantly. Also, this is very ad-hoc "benchmarking," variance is not measured.*
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add names to WrappersOffsetTest.

Marked as reviewed by chagedorn (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1682#pullrequestreview-3356155081

From rriggs at openjdk.org  Mon Oct 20 13:39:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 20 Oct 2025 13:39:05 GMT
Subject: [lworld] RFR: 8369921: [lworld] Remove caches of primitive wrapper
 classes
In-Reply-To: <3ne8NFGmjaQtQ4OLWkpWevIGWVoWrogmhvpzni2uEQA=.0c62e343-6689-4d1d-91b7-a9010c8b88a5@github.com>
References: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
 <3ne8NFGmjaQtQ4OLWkpWevIGWVoWrogmhvpzni2uEQA=.0c62e343-6689-4d1d-91b7-a9010c8b88a5@github.com>
Message-ID: <uKp8BDip036LVIqkH8Ma3ipnTMSFan8mG3DwsAYAmdA=.e29ab403-08cb-4563-9acf-60fea3377aaa@github.com>

On Fri, 17 Oct 2025 21:59:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> No tests need to be updated; `java/lang/Integer/ValueOf.java` passes with this change?

The tests use `==` (acmp) to compare. In Valhalla `acmp` for value classes does a field by field (recursive) comparison.
It is not possible to detect a difference between any two value class instances (assuming their fields have the same values) regardless of their source.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1685#issuecomment-3422098868

From liach at openjdk.org  Mon Oct 20 15:16:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 Oct 2025 15:16:35 GMT
Subject: [lworld] RFR: 8369921: [lworld] Remove caches of primitive wrapper
 classes
In-Reply-To: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
References: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
Message-ID: <2hgmo4bo68x3p_vYZE1NxIfF9b5GNTH-cGdxCplDkP0=.caaa59e9-3aab-4370-819d-10bc1c72a937@github.com>

On Fri, 17 Oct 2025 19:28:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Disable use of wrapper cached values when --enable-preview and add javadoc descriptions for enable-preview.
> The wrapper classes are Byte, Short, Character, Integer, and Long.

Double and Float already do new, so they are fine. Should we update Boolean.valueOf to return `new Boolean` instead of TRUE or FALSE?

src/java.base/share/classes/java/lang/Long.java line 1020:

> 1018:     @DeserializeConstructor
> 1019:     public static Long valueOf(long l) {
> 1020:         final int offset = 128;

I recommend moving this into the preview feature block too.

src/java.base/share/classes/java/lang/Short.java line 301:

> 299:     public static Short valueOf(short s) {
> 300:         final int offset = 128;
> 301:         int sAsInt = s;

Same remark, I recommend moving this into the preview feature check block.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1685#issuecomment-3422526752
PR Review Comment: https://git.openjdk.org/valhalla/pull/1685#discussion_r2445312384
PR Review Comment: https://git.openjdk.org/valhalla/pull/1685#discussion_r2445313050

From coleenp at openjdk.org  Mon Oct 20 17:45:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 20 Oct 2025 17:45:33 GMT
Subject: [lworld] RFR: 8369134: [lworld] We should preserve the markWord
 for all GCs [v2]
In-Reply-To: <lEBdTDG6FtzQIMN0CPmiJOk7p03oxhWwHteTYDj3QfA=.6a17dfe2-62ca-4751-9146-27ad612524ae@github.com>
References: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
 <lEBdTDG6FtzQIMN0CPmiJOk7p03oxhWwHteTYDj3QfA=.6a17dfe2-62ca-4751-9146-27ad612524ae@github.com>
Message-ID: <kWJsFZZZfiDPlPSHUIqk1eOOS49H-N68hz6CuAphHjo=.0f6a6909-5d8c-4dd3-98d9-206de782c130@github.com>

On Mon, 20 Oct 2025 09:53:50 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR follows up on changes made in [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875). I updated the documentation to reflect the new information gained.
>> 
>> Furthermore, the investigation described in the issue yielded that we _must_ preserve the larval bit explicitly. I introduce a regression test. If we change the mark word preservation condition to `return (!is_unlocked() || !has_no_hash())` (i.e. what we had before), I have confirmed that we will crash a debug VM via failed assertion. Note that ZGC does not require mark word preservation. I've nonetheless decided to include it in case this behaviour is introduced later.
>> 
>> Testing: tiers 1-3.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   WhiteBox API.

Looks good!

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1666#pullrequestreview-3357380394

From vromero at openjdk.org  Mon Oct 20 17:34:41 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 20 Oct 2025 17:34:41 GMT
Subject: [lworld] Integrated: 8369860: [lworld] Javac generates duplicate
 initializer code
In-Reply-To: <GXEjKtDU-Ogny4Zdu0CJ7o3udh7rwD7hhNerHvpX6pE=.c3c6a8c1-130d-42f3-9cd8-6c92ab132ad8@github.com>
References: <GXEjKtDU-Ogny4Zdu0CJ7o3udh7rwD7hhNerHvpX6pE=.c3c6a8c1-130d-42f3-9cd8-6c92ab132ad8@github.com>
Message-ID: <2YQqzLH29XHwubhwS050QAY7_Dt0xqZe6dKDvZNng_8=.ef142d5f-9dc5-4dc2-94f5-b887af29c3ec@github.com>

On Fri, 17 Oct 2025 22:26:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> For code like:
> 
> 
> value class Test {
>     static class Foo {
>         int x;
>         int getX() { return x; }
>     }
>     private final Foo data = new Foo();
>     Test() {
>         data.getX();
>         super();
>     }
> }
> 
> 
> javac generates code corresponding to the initialization of field `data` twice, which is incorrect

This pull request has now been integrated.

Changeset: 204f8036
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/204f8036cc1f96a636e0071af89701e439d23056
Stats:     149 lines in 3 files changed: 66 ins; 60 del; 23 mod

8369860: [lworld] Javac generates duplicate initializer code

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

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

From liach at openjdk.org  Mon Oct 20 18:20:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 20 Oct 2025 18:20:38 GMT
Subject: [lworld] RFR: 8369860: [lworld] Javac generates duplicate
 initializer code
In-Reply-To: <GXEjKtDU-Ogny4Zdu0CJ7o3udh7rwD7hhNerHvpX6pE=.c3c6a8c1-130d-42f3-9cd8-6c92ab132ad8@github.com>
References: <GXEjKtDU-Ogny4Zdu0CJ7o3udh7rwD7hhNerHvpX6pE=.c3c6a8c1-130d-42f3-9cd8-6c92ab132ad8@github.com>
Message-ID: <kl5pQVr3sad61-s4K83ApwgbqZM5wOohmGL2nSnlyH0=.ef55b642-a8b8-4da2-a8d2-808322f2a771@github.com>

On Fri, 17 Oct 2025 22:26:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> For code like:
> 
> 
> value class Test {
>     static class Foo {
>         int x;
>         int getX() { return x; }
>     }
>     private final Foo data = new Foo();
>     Test() {
>         data.getX();
>         super();
>     }
> }
> 
> 
> javac generates code corresponding to the initialization of field `data` twice, which is incorrect

Can we just append the variable initializers to the initBlocks in the `(sym.flags() & STATIC) == 0` branch in normalizeDefs?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1686#issuecomment-3423238688

From chagedorn at openjdk.org  Tue Oct 21 06:57:04 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 06:57:04 GMT
Subject: [lworld] RFR: 8370263: [lworld] Fix compile commands after JDK-8369437
Message-ID: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>

When adding packages in [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437), some compile commands were not updated accordingly as well. This is fixes with this patch.

Thanks,
Christian

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

Commit messages:
 - 8370263: [lworld] Fix compile commands after JDK-8369437

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

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

From chagedorn at openjdk.org  Tue Oct 21 06:57:07 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 06:57:07 GMT
Subject: [lworld] RFR: 8370263: [lworld] Fix compile commands after
 JDK-8369437
In-Reply-To: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
References: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
Message-ID: <Z7s7LB8h_Ge-tP056t2lLUYJ_OI8ChqsNwGZQH9ErH4=.7ec12325-ca9f-4d6e-8fff-fc19e5667766@github.com>

On Tue, 21 Oct 2025 06:49:52 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When adding packages in [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437), some compile commands were not updated accordingly as well. This is fixes with this patch.
> 
> Thanks,
> Christian

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java line 33:

> 31:  * @run main/othervm/timeout=300 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
> 32:  *                               -Xbatch -XX:-TieredCompilation
> 33:  *                               -XX:CompileCommand=dontinline,*TestOopsInReturnConvention*::callee

I think the `*` after `TestOopsInReturnConvention` was missing before: `callee()` is only defined in the inner class `LargeValueWithOops`.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java line 48:

> 46:  * @run main/othervm -Xcomp -XX:-UseArrayFlattening
> 47:  *                   -XX:CompileCommand=compileonly,*TestUnloadedInlineTypeArray::test*
> 48:  *                   compiler.valhalla.inlinetypes.TestUnloadedInlineTypeArray

Added missing package - forgot to do in JDK-8369437.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1689#discussion_r2446897190
PR Review Comment: https://git.openjdk.org/valhalla/pull/1689#discussion_r2446898093

From phubner at openjdk.org  Tue Oct 21 07:15:29 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 21 Oct 2025 07:15:29 GMT
Subject: [lworld] RFR: 8369134: [lworld] We should preserve the markWord
 for all GCs [v2]
In-Reply-To: <kWJsFZZZfiDPlPSHUIqk1eOOS49H-N68hz6CuAphHjo=.0f6a6909-5d8c-4dd3-98d9-206de782c130@github.com>
References: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
 <lEBdTDG6FtzQIMN0CPmiJOk7p03oxhWwHteTYDj3QfA=.6a17dfe2-62ca-4751-9146-27ad612524ae@github.com>
 <kWJsFZZZfiDPlPSHUIqk1eOOS49H-N68hz6CuAphHjo=.0f6a6909-5d8c-4dd3-98d9-206de782c130@github.com>
Message-ID: <sPKgk8R8LnIRxtQ5PWSEIFuGUOlg49RsLRAUbeFP6-I=.06d61d6d-d24e-4c3a-9206-b049d40f17da@github.com>

On Mon, 20 Oct 2025 17:42:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   WhiteBox API.
>
> Looks good!

Thanks for the review @coleenp.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1666#issuecomment-3425085955

From duke at openjdk.org  Tue Oct 21 07:15:31 2025
From: duke at openjdk.org (duke)
Date: Tue, 21 Oct 2025 07:15:31 GMT
Subject: [lworld] RFR: 8369134: [lworld] We should preserve the markWord
 for all GCs [v2]
In-Reply-To: <lEBdTDG6FtzQIMN0CPmiJOk7p03oxhWwHteTYDj3QfA=.6a17dfe2-62ca-4751-9146-27ad612524ae@github.com>
References: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
 <lEBdTDG6FtzQIMN0CPmiJOk7p03oxhWwHteTYDj3QfA=.6a17dfe2-62ca-4751-9146-27ad612524ae@github.com>
Message-ID: <nZd3owxvMhdqafU131W0RSmr36Avrys7xNHxQ8lkOEo=.9f7dfa4c-4761-436e-af15-2be64cef68ce@github.com>

On Mon, 20 Oct 2025 09:53:50 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR follows up on changes made in [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875). I updated the documentation to reflect the new information gained.
>> 
>> Furthermore, the investigation described in the issue yielded that we _must_ preserve the larval bit explicitly. I introduce a regression test. If we change the mark word preservation condition to `return (!is_unlocked() || !has_no_hash())` (i.e. what we had before), I have confirmed that we will crash a debug VM via failed assertion. Note that ZGC does not require mark word preservation. I've nonetheless decided to include it in case this behaviour is introduced later.
>> 
>> Testing: tiers 1-3.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   WhiteBox API.

@Arraying 
Your change (at version a75ca117bc4e686d863b468158bd58eba424fcb6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1666#issuecomment-3425092016

From phubner at openjdk.org  Tue Oct 21 07:19:42 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 21 Oct 2025 07:19:42 GMT
Subject: [lworld] Integrated: 8369134: [lworld] We should preserve the markWord
 for all GCs
In-Reply-To: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
References: <FjQAIWhx5OKsFcjmyhW0HNaZxq7FlA58fnxlmG0WN3A=.a1094ad9-a800-465a-a1bb-17acd9e4283c@github.com>
Message-ID: <t6FSxMAcMAQ-DTWmSlthV1OctFbYECaIwxlTdiHowYA=.7a290554-4f71-46cc-8847-f6f5ad6eed0b@github.com>

On Tue, 7 Oct 2025 13:02:10 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This PR follows up on changes made in [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875). I updated the documentation to reflect the new information gained.
> 
> Furthermore, the investigation described in the issue yielded that we _must_ preserve the larval bit explicitly. I introduce a regression test. If we change the mark word preservation condition to `return (!is_unlocked() || !has_no_hash())` (i.e. what we had before), I have confirmed that we will crash a debug VM via failed assertion. Note that ZGC does not require mark word preservation. I've nonetheless decided to include it in case this behaviour is introduced later.
> 
> Testing: tiers 1-3.

This pull request has now been integrated.

Changeset: b5e30d53
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b5e30d53fbe964c48c89ce8fcd30e8abe0b3fac5
Stats:     130 lines in 2 files changed: 127 ins; 0 del; 3 mod

8369134: [lworld] We should preserve the markWord for all GCs

Reviewed-by: coleenp

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

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

From thartmann at openjdk.org  Tue Oct 21 07:20:24 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 07:20:24 GMT
Subject: [lworld] RFR: 8370263: [lworld] Fix compile commands after
 JDK-8369437
In-Reply-To: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
References: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
Message-ID: <HLCJZhFCHtiKgiZ0suwF3_gNEuQnz3oEsA4YtOvfTEI=.6a8bc927-bbc5-4769-9e70-5b453b57f121@github.com>

On Tue, 21 Oct 2025 06:49:52 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When adding packages in [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437), some compile commands were not updated accordingly as well. This is fixes with this patch.
> 
> Thanks,
> Christian

Looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1689#pullrequestreview-3359083787

From thartmann at openjdk.org  Tue Oct 21 07:20:25 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 07:20:25 GMT
Subject: [lworld] RFR: 8370263: [lworld] Fix compile commands after
 JDK-8369437
In-Reply-To: <Z7s7LB8h_Ge-tP056t2lLUYJ_OI8ChqsNwGZQH9ErH4=.7ec12325-ca9f-4d6e-8fff-fc19e5667766@github.com>
References: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
 <Z7s7LB8h_Ge-tP056t2lLUYJ_OI8ChqsNwGZQH9ErH4=.7ec12325-ca9f-4d6e-8fff-fc19e5667766@github.com>
Message-ID: <MDxaw4IwBi0GNmxGR-HqOB4vMuq9eVaOp_qZlRhbQU4=.b8cf7599-b064-4585-b243-6c1689445172@github.com>

On Tue, 21 Oct 2025 06:50:40 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> When adding packages in [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437), some compile commands were not updated accordingly as well. This is fixes with this patch.
>> 
>> Thanks,
>> Christian
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestOopsInReturnConvention.java line 33:
> 
>> 31:  * @run main/othervm/timeout=300 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
>> 32:  *                               -Xbatch -XX:-TieredCompilation
>> 33:  *                               -XX:CompileCommand=dontinline,*TestOopsInReturnConvention*::callee
> 
> I think the `*` after `TestOopsInReturnConvention` was missing before: `callee()` is only defined in the inner class `LargeValueWithOops`.

Good catch!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1689#discussion_r2446986887

From chagedorn at openjdk.org  Tue Oct 21 07:26:35 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 07:26:35 GMT
Subject: [lworld] RFR: 8370263: [lworld] Fix compile commands after
 JDK-8369437
In-Reply-To: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
References: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
Message-ID: <pMxx-Dh0jlctBEUoDlLjjJRONneFxT5eLOUYP8xb3A0=.58e7b45f-29c5-453e-bb64-294371b4afb5@github.com>

On Tue, 21 Oct 2025 06:49:52 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When adding packages in [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437), some compile commands were not updated accordingly as well. This is fixes with this patch.
> 
> Thanks,
> Christian

Thanks Tobias!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1689#issuecomment-3425129550

From chagedorn at openjdk.org  Tue Oct 21 07:26:35 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 07:26:35 GMT
Subject: [lworld] Integrated: 8370263: [lworld] Fix compile commands after
 JDK-8369437
In-Reply-To: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
References: <JH5CL7v0FWReYcjjx5Kt-GYlsOo6oC6YmgAuDjZBUF0=.95de51a7-1998-4c9e-9794-e721988e1c6a@github.com>
Message-ID: <tIsvBZcZUfkEpts2FOjSJvngSBBMaqqln0azcJQxtYc=.9cb02b63-3590-4eb6-9abd-c8dccb85c99e@github.com>

On Tue, 21 Oct 2025 06:49:52 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When adding packages in [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437), some compile commands were not updated accordingly as well. This is fixes with this patch.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 19003178
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/19003178277ef557d8a2811f7224ed2c0c7544a4
Stats:     52 lines in 4 files changed: 2 ins; 0 del; 50 mod

8370263: [lworld] Fix compile commands after JDK-8369437

Reviewed-by: thartmann

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

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

From mchevalier at openjdk.org  Tue Oct 21 07:46:17 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 21 Oct 2025 07:46:17 GMT
Subject: [lworld] RFR: 8368988: [lworld] Rename classes in
 valhalla/inlinetypes to be distinct [v2]
In-Reply-To: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>
References: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>
Message-ID: <Nfi2XimXay_QvZsPT7Uu1GYoO_9-Xlpxjl1iy4UHEUg=.90d68025-8145-4029-aa56-0837394f9a90@github.com>

> Various cleanup in test package `compiler.valhalla.inlinetypes`:
> - rename duplicated classes so that IDEs are nice, resolve correctly. New names are a bit... arbitrary. I'm happy to rename name if anyone has opinions. When writing new tests, let's prefer nested classes if we can.
> - add `package compiler.valhalla.inlinetypes;` where it was missing. IDEs like that, and I vaguely remember we should.
> - fix flags to take the new path into account, new package, or class renaming. Please, try to pay attention to that: I've did multiple passes to catch'em all, but this is easy to miss.
> - remove some useless `import`.
> - some few typos in comments.
> - maybe more?
> 
> Thanks,
> Marc

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

  More consistent naming convention

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1683/files
  - new: https://git.openjdk.org/valhalla/pull/1683/files/140916f2..306d2f9a

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

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

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

From mchevalier at openjdk.org  Tue Oct 21 08:22:10 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 21 Oct 2025 08:22:10 GMT
Subject: [lworld] RFR: 8368988: [lworld] Rename classes in
 valhalla/inlinetypes to be distinct [v3]
In-Reply-To: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>
References: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>
Message-ID: <ETvAzi2pk-BQXh_45Tch0SKmx9JaGA3zHSEO3HdbCyI=.fdeb3b36-478d-4c8f-8d58-2040fbc5e792@github.com>

> Various cleanup in test package `compiler.valhalla.inlinetypes`:
> - rename duplicated classes so that IDEs are nice, resolve correctly. New names are a bit... arbitrary. I'm happy to rename name if anyone has opinions. When writing new tests, let's prefer nested classes if we can.
> - add `package compiler.valhalla.inlinetypes;` where it was missing. IDEs like that, and I vaguely remember we should.
> - fix flags to take the new path into account, new package, or class renaming. Please, try to pay attention to that: I've did multiple passes to catch'em all, but this is easy to miss.
> - remove some useless `import`.
> - some few typos in comments.
> - maybe more?
> 
> Thanks,
> Marc

Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge remote-tracking branch 'upstream/lworld' into JDK-8368988
 - More consistent naming convention
 - Merge remote-tracking branch 'origin/lworld' into JDK-8368988
 - post rebase fixes
 - Fixes
 - Some cleanup

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

Changes: https://git.openjdk.org/valhalla/pull/1683/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1683&range=02
  Stats: 1587 lines in 54 files changed: 40 ins; 53 del; 1494 mod
  Patch: https://git.openjdk.org/valhalla/pull/1683.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1683/head:pull/1683

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

From thartmann at openjdk.org  Tue Oct 21 08:37:55 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 08:37:55 GMT
Subject: [lworld] RFR: 8368988: [lworld] Rename classes in
 valhalla/inlinetypes to be distinct [v3]
In-Reply-To: <ETvAzi2pk-BQXh_45Tch0SKmx9JaGA3zHSEO3HdbCyI=.fdeb3b36-478d-4c8f-8d58-2040fbc5e792@github.com>
References: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>
 <ETvAzi2pk-BQXh_45Tch0SKmx9JaGA3zHSEO3HdbCyI=.fdeb3b36-478d-4c8f-8d58-2040fbc5e792@github.com>
Message-ID: <HqHFGcI-QBCmdACtpi7HCygKV0DL-D_ALvWF2lsSKlo=.0c2b1a99-b159-490f-b446-b004439ddb88@github.com>

On Tue, 21 Oct 2025 08:22:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Various cleanup in test package `compiler.valhalla.inlinetypes`:
>> - rename duplicated classes so that IDEs are nice, resolve correctly. New names are a bit... arbitrary. I'm happy to rename name if anyone has opinions. When writing new tests, let's prefer nested classes if we can.
>> - add `package compiler.valhalla.inlinetypes;` where it was missing. IDEs like that, and I vaguely remember we should.
>> - fix flags to take the new path into account, new package, or class renaming. Please, try to pay attention to that: I've did multiple passes to catch'em all, but this is easy to miss.
>> - remove some useless `import`.
>> - some few typos in comments.
>> - maybe more?
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'upstream/lworld' into JDK-8368988
>  - More consistent naming convention
>  - Merge remote-tracking branch 'origin/lworld' into JDK-8368988
>  - post rebase fixes
>  - Fixes
>  - Some cleanup

Nice cleanup, thanks Marc!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1683#pullrequestreview-3359424906

From chagedorn at openjdk.org  Tue Oct 21 09:02:15 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 09:02:15 GMT
Subject: [lworld] Integrated: [lworld] Problemlist
 compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java
Message-ID: <WM9ubk8PA6zNcHiETQpqlvXABKM9daKvNc8_Z1p1rKs=.a5f72bcc-25ac-4b15-829c-d36241a7e20e@github.com>

The test is failing a lot, let's problemlist for now.

Thanks,
Christian

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

Commit messages:
 - [lworld] Problemlist compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java

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

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

From thartmann at openjdk.org  Tue Oct 21 09:02:16 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 09:02:16 GMT
Subject: [lworld] Integrated: [lworld] Problemlist
 compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java
In-Reply-To: <WM9ubk8PA6zNcHiETQpqlvXABKM9daKvNc8_Z1p1rKs=.a5f72bcc-25ac-4b15-829c-d36241a7e20e@github.com>
References: <WM9ubk8PA6zNcHiETQpqlvXABKM9daKvNc8_Z1p1rKs=.a5f72bcc-25ac-4b15-829c-d36241a7e20e@github.com>
Message-ID: <nItiCLaaN3uiKkv1MfU6nqjqjiavvNrVUeHnHkU70ng=.436da57e-78f3-4ddf-b47a-4605d452bbab@github.com>

On Tue, 21 Oct 2025 08:53:53 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The test is failing a lot, let's problemlist for now.
> 
> Thanks,
> Christian

Marked as reviewed by thartmann (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1690#pullrequestreview-3359520012

From chagedorn at openjdk.org  Tue Oct 21 09:02:16 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 09:02:16 GMT
Subject: [lworld] Integrated: [lworld] Problemlist
 compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java
In-Reply-To: <WM9ubk8PA6zNcHiETQpqlvXABKM9daKvNc8_Z1p1rKs=.a5f72bcc-25ac-4b15-829c-d36241a7e20e@github.com>
References: <WM9ubk8PA6zNcHiETQpqlvXABKM9daKvNc8_Z1p1rKs=.a5f72bcc-25ac-4b15-829c-d36241a7e20e@github.com>
Message-ID: <wZkysu_-fYAk91NCfORzM8L910WlN6QT-uk-KRbtltI=.8e42a90b-f394-4b22-b630-b8993c5e825e@github.com>

On Tue, 21 Oct 2025 08:53:53 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The test is failing a lot, let's problemlist for now.
> 
> Thanks,
> Christian

Thanks Tobias for your quick review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1690#issuecomment-3425505349

From chagedorn at openjdk.org  Tue Oct 21 09:02:17 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 09:02:17 GMT
Subject: [lworld] Integrated: [lworld] Problemlist
 compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java
In-Reply-To: <WM9ubk8PA6zNcHiETQpqlvXABKM9daKvNc8_Z1p1rKs=.a5f72bcc-25ac-4b15-829c-d36241a7e20e@github.com>
References: <WM9ubk8PA6zNcHiETQpqlvXABKM9daKvNc8_Z1p1rKs=.a5f72bcc-25ac-4b15-829c-d36241a7e20e@github.com>
Message-ID: <-lZmt5WDW289sA1feTutTvWxGKrVr6SqZFzZtIvQjbM=.99732f43-07fa-45fb-8aa9-b8bbe1d6e006@github.com>

On Tue, 21 Oct 2025 08:53:53 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The test is failing a lot, let's problemlist for now.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 1db3cbe5
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1db3cbe555a66327cfa4befb2a406ae2ac3b68e4
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

[lworld] Problemlist compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java

Reviewed-by: thartmann

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

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

From chagedorn at openjdk.org  Tue Oct 21 10:12:10 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 10:12:10 GMT
Subject: [lworld] RFR: 8370313: [lworld]
 compiler/valhalla/inlinetyes/TestUnloadedInlineTypeArray.java fails
Message-ID: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>

After adding a package, it was missed to also add the package name in the string comparison in `verifyTest6()`. Also added a previously missed package name.

Thanks,
Christian

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

Commit messages:
 - fix

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

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

From thartmann at openjdk.org  Tue Oct 21 10:12:11 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 10:12:11 GMT
Subject: [lworld] RFR: 8370313: [lworld]
 compiler/valhalla/inlinetyes/TestUnloadedInlineTypeArray.java fails
In-Reply-To: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
References: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
Message-ID: <0VuGy51YbOgo-CxPwdIv2POqnkAOZuPVWuD8el4Sr0s=.459d1cad-4b88-40fb-9fc6-90971b078d71@github.com>

On Tue, 21 Oct 2025 10:06:20 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> After adding a package, it was missed to also add the package name in the string comparison in `verifyTest6()`. Also added a previously missed package name.
> 
> Thanks,
> Christian

Looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1691#pullrequestreview-3359817065

From mchevalier at openjdk.org  Tue Oct 21 10:23:53 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 21 Oct 2025 10:23:53 GMT
Subject: [lworld] RFR: 8368988: [lworld] Rename classes in
 valhalla/inlinetypes to be distinct [v3]
In-Reply-To: <ETvAzi2pk-BQXh_45Tch0SKmx9JaGA3zHSEO3HdbCyI=.fdeb3b36-478d-4c8f-8d58-2040fbc5e792@github.com>
References: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>
 <ETvAzi2pk-BQXh_45Tch0SKmx9JaGA3zHSEO3HdbCyI=.fdeb3b36-478d-4c8f-8d58-2040fbc5e792@github.com>
Message-ID: <Sm9Xq-kO0DCHzy2ytPQJCAWFx-mS-0FDO2HfeKqUZXM=.cd71fd26-9557-417c-b351-4cbec45e4ef9@github.com>

On Tue, 21 Oct 2025 08:22:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Various cleanup in test package `compiler.valhalla.inlinetypes`:
>> - rename duplicated classes so that IDEs are nice, resolve correctly. New names are a bit... arbitrary. I'm happy to rename name if anyone has opinions. When writing new tests, let's prefer nested classes if we can.
>> - add `package compiler.valhalla.inlinetypes;` where it was missing. IDEs like that, and I vaguely remember we should.
>> - fix flags to take the new path into account, new package, or class renaming. Please, try to pay attention to that: I've did multiple passes to catch'em all, but this is easy to miss.
>> - remove some useless `import`.
>> - some few typos in comments.
>> - maybe more?
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'upstream/lworld' into JDK-8368988
>  - More consistent naming convention
>  - Merge remote-tracking branch 'origin/lworld' into JDK-8368988
>  - post rebase fixes
>  - Fixes
>  - Some cleanup

Thanks @TobiHartmann for the review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1683#issuecomment-3425825494

From mchevalier at openjdk.org  Tue Oct 21 10:23:55 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 21 Oct 2025 10:23:55 GMT
Subject: [lworld] Integrated: 8368988: [lworld] Rename classes in
 valhalla/inlinetypes to be distinct
In-Reply-To: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>
References: <7UYQvURGTwQNXclKAijNqBze4DYbnHrlPj4li1krM8c=.3e55854a-57bf-420b-870a-01682484f958@github.com>
Message-ID: <lwkv-uPU2vxcKuhQnXahkU16wfmPmx50ryd45VLCT1o=.be6b60ca-abcb-4d46-be92-0390849e7bde@github.com>

On Fri, 17 Oct 2025 11:27:47 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Various cleanup in test package `compiler.valhalla.inlinetypes`:
> - rename duplicated classes so that IDEs are nice, resolve correctly. New names are a bit... arbitrary. I'm happy to rename name if anyone has opinions. When writing new tests, let's prefer nested classes if we can.
> - add `package compiler.valhalla.inlinetypes;` where it was missing. IDEs like that, and I vaguely remember we should.
> - fix flags to take the new path into account, new package, or class renaming. Please, try to pay attention to that: I've did multiple passes to catch'em all, but this is easy to miss.
> - remove some useless `import`.
> - some few typos in comments.
> - maybe more?
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: e0aaf290
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e0aaf29064ed67c240f5275e9b3d324ce5550382
Stats:     1587 lines in 54 files changed: 40 ins; 53 del; 1494 mod

8368988: [lworld] Rename classes in valhalla/inlinetypes to be distinct

Reviewed-by: thartmann

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

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

From chagedorn at openjdk.org  Tue Oct 21 10:45:30 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 10:45:30 GMT
Subject: [lworld] RFR: 8370313: [lworld]
 compiler/valhalla/inlinetyes/TestUnloadedInlineTypeArray.java fails
In-Reply-To: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
References: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
Message-ID: <NARxZZ-pEg2WPtm5Y09JJq9_o5FmbzcgfjDlP7bWt1w=.b05c4a9f-fe4c-4444-bf08-216a9bbfea48@github.com>

On Tue, 21 Oct 2025 10:06:20 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> After adding a package, it was missed to also add the package name in the string comparison in `verifyTest6()`. Also added a previously missed package name.
> 
> Thanks,
> Christian

Thanks for your review Tobias!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1691#issuecomment-3425910022

From chagedorn at openjdk.org  Tue Oct 21 11:19:57 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 11:19:57 GMT
Subject: [lworld] RFR: 8370313: [lworld]
 compiler/valhalla/inlinetyes/TestUnloadedInlineTypeArray.java fails [v2]
In-Reply-To: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
References: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
Message-ID: <TLw3XpsX3EdtjzyaCVhY8oPMOzrkQUTfdg8u-fe25AA=.bfda7511-1d34-49f9-b709-7df84f9389d0@github.com>

> After adding a package, it was missed to also add the package name in the string comparison in `verifyTest6()`. Also added a previously missed package name.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - fix merge conflict
 - Merge branch 'lworld' into JDK-8370313
   
   # Conflicts:
   #	test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java
 - fix

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

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

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

From thartmann at openjdk.org  Tue Oct 21 11:19:57 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 11:19:57 GMT
Subject: [lworld] RFR: 8370313: [lworld]
 compiler/valhalla/inlinetyes/TestUnloadedInlineTypeArray.java fails [v2]
In-Reply-To: <TLw3XpsX3EdtjzyaCVhY8oPMOzrkQUTfdg8u-fe25AA=.bfda7511-1d34-49f9-b709-7df84f9389d0@github.com>
References: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
 <TLw3XpsX3EdtjzyaCVhY8oPMOzrkQUTfdg8u-fe25AA=.bfda7511-1d34-49f9-b709-7df84f9389d0@github.com>
Message-ID: <rlfy-jGC2ngzPRn9rhPuYVNy5D93S1yHY3SSPbLhMxg=.f7fe88dc-385d-40b3-a265-15990f71cd30@github.com>

On Tue, 21 Oct 2025 11:17:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> After adding a package, it was missed to also add the package name in the string comparison in `verifyTest6()`. Also added a previously missed package name.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - fix merge conflict
>  - Merge branch 'lworld' into JDK-8370313
>    
>    # Conflicts:
>    #	test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnloadedInlineTypeArray.java
>  - fix

Marked as reviewed by thartmann (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1691#pullrequestreview-3360053761

From chagedorn at openjdk.org  Tue Oct 21 11:19:58 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 11:19:58 GMT
Subject: [lworld] RFR: 8370313: [lworld]
 compiler/valhalla/inlinetyes/TestUnloadedInlineTypeArray.java fails
In-Reply-To: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
References: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
Message-ID: <l4TbXjPQBQkOeMTAwjhUhUJgYFfdROgOMH1IVg5xtwM=.90a14e2a-8ee1-41a4-85bd-c4387a06dab9@github.com>

On Tue, 21 Oct 2025 10:06:20 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> After adding a package, it was missed to also add the package name in the string comparison in `verifyTest6()`. Also added a previously missed package name.
> 
> Thanks,
> Christian

Seems like JDK-8368988 fixed it in the meantime, so this comes down to unproblemlisting.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1691#issuecomment-3426057065

From chagedorn at openjdk.org  Tue Oct 21 11:22:45 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 21 Oct 2025 11:22:45 GMT
Subject: [lworld] Integrated: 8370313: [lworld]
 compiler/valhalla/inlinetyes/TestUnloadedInlineTypeArray.java fails
In-Reply-To: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
References: <O7C-P5phjFHvIFEtaBMqE9jpg-nArxQHtBwq_iQggRE=.6f5376ee-04b3-4550-8514-e2baae5fdf93@github.com>
Message-ID: <RsmajLNpSG-4DXK82vgGAlhv8gFNLk29DuKn_0tDUpY=.148abf70-3e4e-41bb-80ce-fda9343a039a@github.com>

On Tue, 21 Oct 2025 10:06:20 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> After adding a package, it was missed to also add the package name in the string comparison in `verifyTest6()`. Also added a previously missed package name.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 3af03b2e
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3af03b2e774910869986b69e4b2f953a32b1aebe
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8370313: [lworld] compiler/valhalla/inlinetyes/TestUnloadedInlineTypeArray.java fails

Reviewed-by: thartmann

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

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

From thartmann at openjdk.org  Tue Oct 21 14:06:33 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 14:06:33 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v6]
In-Reply-To: <L1N0KOYynxFN9yojQHauMSS40HKo-nDXXeIKFOpRnqk=.ba627a40-4aaa-440d-b11e-7beaeef1759f@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
 <L1N0KOYynxFN9yojQHauMSS40HKo-nDXXeIKFOpRnqk=.ba627a40-4aaa-440d-b11e-7beaeef1759f@github.com>
Message-ID: <3D8fUfNRHmdkQYEuMsp1F1r7Lrc85Rtaq4A3S9pTSTM=.42c7a42a-283a-46ec-b6c7-a204555ef1bc@github.com>

On Mon, 20 Oct 2025 09:00:02 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:
> 
>   Remove flat accesses from sfn_worklist

Great work, Quan-Anh! This looks good to me. Testing is still running but looks good so far (we had some breakage in our CI). I'll get back to you once it passed.

src/hotspot/share/opto/escape.cpp line 3392:

> 3390: }
> 3391: 
> 3392: // Atomic flat accesses on non-escape objects can be optimized to non-atomic accesses

Suggestion:

// Atomic flat accesses on non-escaping objects can be optimized to non-atomic accesses

src/hotspot/share/opto/inlinetypenode.hpp line 176:

> 174: // marker if existing will be the last Proj output. This node acts as if the load happens
> 175: // atomically and will be expanded to loading the whole payload and extracting the flattened fields
> 176: // from the loaded payload. In special cases, such as when the object from which this load read

Suggestion:

// from the loaded payload. In special cases, such as when the object from which this load reads

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

> 177: // does not escape, this node can be expanded to multiple loads from each flattened field.
> 178: // This node allows us to replace its results with the value from a matching store because the
> 179: // payload value cannot be directly propagated if it contains oops. This effect, in turns, allows

Suggestion:

// payload value cannot be directly propagated if it contains oops. This effect, in turn, allows

src/hotspot/share/opto/inlinetypenode.hpp line 216:

> 214: 
> 215: // Store an InlineTypeNode to a flat element, the store acts as if it is atomic. Similar to
> 216: // LoadFlatNode, this node is expanded to storing a payload creating from the field values of the

Suggestion:

// LoadFlatNode, this node is expanded to storing a payload created from the field values of the

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1518#pullrequestreview-3360961039
PR Review Comment: https://git.openjdk.org/valhalla/pull/1518#discussion_r2448463925
PR Review Comment: https://git.openjdk.org/valhalla/pull/1518#discussion_r2448453931
PR Review Comment: https://git.openjdk.org/valhalla/pull/1518#discussion_r2448455420
PR Review Comment: https://git.openjdk.org/valhalla/pull/1518#discussion_r2448457425

From fparain at openjdk.org  Tue Oct 21 15:05:33 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 21 Oct 2025 15:05:33 GMT
Subject: [lworld] RFR: 8366668: [lworld] Follow-up work from the array
 metadata re-work
In-Reply-To: <i0p2vjA7P1ykeeI5a1l6CM8edPJuRxDyDK5jYC36m94=.94c73383-38f5-4322-aa48-4e8e5441a42f@github.com>
References: <i0p2vjA7P1ykeeI5a1l6CM8edPJuRxDyDK5jYC36m94=.94c73383-38f5-4322-aa48-4e8e5441a42f@github.com>
Message-ID: <9FSNGGVG8FuhRhaUtCF251jOaTpwzSTUh6pF9b7Ip-A=.d226ef89-3636-4b20-94e9-3a88af8830f7@github.com>

On Fri, 10 Oct 2025 09:22:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This is a follow-up from [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) resolving a large number of ToDos in the implementation and tests.
> 
> There are a few remaining ToDos that I'll address with [JDK-8370341](https://bugs.openjdk.org/browse/JDK-8370341) because this change is getting too large and is blocking other work.
> 
> Best regards,
> Tobias

Runtime changes look good to me.

src/hotspot/share/oops/objArrayKlass.cpp line 391:

> 389:     // C2 relies on this for a fast lookup (see LibraryCallKit::load_default_refined_array_klass).
> 390:     if (ak == nullptr) {
> 391:       klass_with_properties(ArrayKlass::ArrayProperties::DEFAULT, THREAD);

This call modifies the next_refined_array_klass pointer, which makes test on line 395 operating on an obsolete value. Not a semantic issue considering the case being handled, but not a good coding practice.
Could you move this code inside the block where the MultiArray_lock is already owned?

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1672#pullrequestreview-3340253370
PR Review Comment: https://git.openjdk.org/valhalla/pull/1672#discussion_r2426391506

From thartmann at openjdk.org  Tue Oct 21 15:05:34 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 15:05:34 GMT
Subject: [lworld] RFR: 8366668: [lworld] Follow-up work from the array
 metadata re-work
In-Reply-To: <i0p2vjA7P1ykeeI5a1l6CM8edPJuRxDyDK5jYC36m94=.94c73383-38f5-4322-aa48-4e8e5441a42f@github.com>
References: <i0p2vjA7P1ykeeI5a1l6CM8edPJuRxDyDK5jYC36m94=.94c73383-38f5-4322-aa48-4e8e5441a42f@github.com>
Message-ID: <2zNcqYMmQpSnkrAll37jiURUBTx00AGcWjv2IyYW-Y0=.79a79763-d4b6-47eb-bda7-4950a82c10e2@github.com>

On Fri, 10 Oct 2025 09:22:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This is a follow-up from [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) resolving a large number of ToDos in the implementation and tests.
> 
> There are a few remaining ToDos that I'll address with [JDK-8370341](https://bugs.openjdk.org/browse/JDK-8370341) because this change is getting too large and is blocking other work.
> 
> Best regards,
> Tobias

Thanks again for the review Fred!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1672#issuecomment-3407609109

From thartmann at openjdk.org  Tue Oct 21 15:05:35 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 15:05:35 GMT
Subject: [lworld] RFR: 8366668: [lworld] Follow-up work from the array
 metadata re-work
In-Reply-To: <9FSNGGVG8FuhRhaUtCF251jOaTpwzSTUh6pF9b7Ip-A=.d226ef89-3636-4b20-94e9-3a88af8830f7@github.com>
References: <i0p2vjA7P1ykeeI5a1l6CM8edPJuRxDyDK5jYC36m94=.94c73383-38f5-4322-aa48-4e8e5441a42f@github.com>
 <9FSNGGVG8FuhRhaUtCF251jOaTpwzSTUh6pF9b7Ip-A=.d226ef89-3636-4b20-94e9-3a88af8830f7@github.com>
Message-ID: <98MhU3Q8evtHVHkdzk4KxceSuQ39vCE0-d3KJx2c0_M=.1305e930-18c4-4450-88d8-f8d66f1f30d3@github.com>

On Mon, 13 Oct 2025 13:40:02 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is a follow-up from [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) resolving a large number of ToDos in the implementation and tests.
>> 
>> There are a few remaining ToDos that I'll address with [JDK-8370341](https://bugs.openjdk.org/browse/JDK-8370341) because this change is getting too large and is blocking other work.
>> 
>> Best regards,
>> Tobias
>
> src/hotspot/share/oops/objArrayKlass.cpp line 391:
> 
>> 389:     // C2 relies on this for a fast lookup (see LibraryCallKit::load_default_refined_array_klass).
>> 390:     if (ak == nullptr) {
>> 391:       klass_with_properties(ArrayKlass::ArrayProperties::DEFAULT, THREAD);
> 
> This call modifies the next_refined_array_klass pointer, which makes test on line 395 operating on an obsolete value. Not a semantic issue considering the case being handled, but not a good coding practice.
> Could you move this code inside the block where the MultiArray_lock is already owned?

Thanks for the review Fred! I pushed an updated version, please let me know what you think.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1672#discussion_r2428253662

From qamai at openjdk.org  Tue Oct 21 15:16:34 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 21 Oct 2025 15:16:34 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v7]
In-Reply-To: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
Message-ID: <ph3PkeJ5y40hjI7TOe_P9v5T8XKwUleexXhLvnA0QTU=.c24f7a33-bd67-40b4-a1b3-44ef99a03623@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:

  grammar errors

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1518/files
  - new: https://git.openjdk.org/valhalla/pull/1518/files/81654d3b..9caeca28

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

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 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 thartmann at openjdk.org  Tue Oct 21 15:05:31 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Oct 2025 15:05:31 GMT
Subject: [lworld] RFR: 8366668: [lworld] Follow-up work from the array metadata
 re-work
Message-ID: <i0p2vjA7P1ykeeI5a1l6CM8edPJuRxDyDK5jYC36m94=.94c73383-38f5-4322-aa48-4e8e5441a42f@github.com>

This is a follow-up from [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) resolving a large number of ToDos in the implementation and tests.

There are a few remaining ToDos that I'll address with [JDK-8370341](https://bugs.openjdk.org/browse/JDK-8370341) because this change is getting too large and is blocking other work.

Best regards,
Tobias

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

Commit messages:
 - Remaining ToDos
 - v14
 - Merge
 - v13
 - v12
 - Merge branch 'lworld' into JDK-8366668
 - v11
 - v10
 - Fred's review comments
 - v9
 - ... and 9 more: https://git.openjdk.org/valhalla/compare/3af03b2e...a62f3890

Changes: https://git.openjdk.org/valhalla/pull/1672/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1672&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366668
  Stats: 915 lines in 45 files changed: 637 ins; 135 del; 143 mod
  Patch: https://git.openjdk.org/valhalla/pull/1672.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1672/head:pull/1672

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

From qamai at openjdk.org  Tue Oct 21 17:13:52 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 21 Oct 2025 17:13:52 GMT
Subject: [lworld] RFR: 8370349: [lworld] Generalize some memory optimizations
 for strict final fields
Message-ID: <a8Q6KBoCluUqdRZ6IW5vGefPbTnuneRL-YMBSxCLGdw=.c0d5d0fe-2054-4a4d-92d4-8c7db68a65fa@github.com>

Hi,

Some optimizations in `memnode.cpp` look at some properties of the pointer such as if it is a field of a value class, or if it is a field of a box class while the required assumption is that the pointer is to a strict final field. This PR cleans that up.

Please leave your reviews, thanks very much.

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

Commit messages:
 - is_ptr_to_strict_final_field

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

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

From rriggs at openjdk.org  Tue Oct 21 20:04:20 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 21 Oct 2025 20:04:20 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v7]
In-Reply-To: <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
Message-ID: <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>

On Tue, 14 Oct 2025 18:28:48 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
>> 
>> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Rolled up changes after rebase.
>    
>    * Removing package root flag based on feedback.
>    * Changing existing package flags during writing to match altered flag values.
>    * Feedback changes, and fixing some comments.
>    * Renaming slightly confusing "testEncoder" method.
>    * Fixing unit tests to use new constructor.
>    * Word smithing flags definitions.
>    * Add workaround until new image writing code is in
>    * Clarifying flag docs for /packages/xxx case
>    * Java ImageReader changes for preview mode
>  - Merge branch 'jdk_8366093_cpp/squashed' into jdk_8368333_java/squashed
>  - [[RESET BRANCH FOR MERGE]]
>  - Removing package root flag based on feedback.
>  - Changing existing package flags during writing to match altered flag values.
>  - Feedback changes, and fixing some comments.
>  - Test fixes and feedback changes.
>    
>    * Renaming slightly confusing "testEncoder" method.
>    * Fixing unit tests to use new constructor.
>  - Manually deleting ImageReaderFactory (it returned somehow)
>  - Word smithing flags definitions.
>  - Add workaround until new image writing code is in
>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/60b6ed62...9bbc26c1

src/java.base/share/classes/jdk/internal/jimage/ImageHeader.java line 60:

> 58:     public static final int MAJOR_VERSION = 1;
> 59:     public static final int MINOR_VERSION = 1;
> 60:     private static final int HEADER_SLOTS = 7;

Please add a comment before these constants connecting them to imageFile.hpp.

src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 48:

> 46:     public static final int ATTRIBUTE_COMPRESSED = 6;
> 47:     public static final int ATTRIBUTE_UNCOMPRESSED = 7;
> 48:     public static final int ATTRIBUTE_PREVIEW_FLAGS = 8;

Please add a comment above these constants that the values are defined in ImageFile.hpp.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 282:

> 280:         // preview-only nodes. This is used to add preview-only content to
> 281:         // directories as they are completed.
> 282:         private final HashMap<String, Directory> previewDirectoriesToMerge;

Can this be cleared or freed after the ImageReader is open. Its no longer needed.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 525:

> 523:             }
> 524:             ImageLocation loc = findLocation(moduleName, resourcePath);
> 525:             return loc != null && loc.getType() == RESOURCE;

Would there be any benefit to caching the resource here, since it has been found and will likely be opened again.

src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java line 38:

> 36:     // String offset constants are useful for efficient classification
> 37:     // of location entries without string comparison. These may change
> 38:     // between jimage versions (they are checked during initialization).

The checking seem only to be done when ImageStringsWriter is loaded/initialized.
There may be a small risk that a mismatch of the image with the ImageStringsReader could occur.
Can they be checked also by the reader?

src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 57:

> 55:     /** If set, the associated module has resources (in normal or preview mode). */
> 56:     // TODO: Make this private again when image writer code is updated.
> 57:     public static final int FLAGS_HAS_CONTENT = 0x4;

Please change the prefix of these to distinguish them from the ImageLocation flags.
For example, "PKG_" or "MR_".

src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 120:

> 118:      * under many modules, it only has content in one.
> 119:      */
> 120:     public boolean hasContent() {

As suggested, `hasResoruces` would be consistent with the lookups for resources.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2449397419
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2449382931
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2449520220
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2449546445
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2449424904
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2449391627
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2449493953

From rriggs at openjdk.org  Tue Oct 21 20:04:21 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 21 Oct 2025 20:04:21 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v3]
In-Reply-To: <RoyjcAXObvd-fPSmprRP6F-qy3PM3aZKpcX7MQ_PYVY=.e74597ed-35c7-4e06-93d7-55454a67e69d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
 <RoyjcAXObvd-fPSmprRP6F-qy3PM3aZKpcX7MQ_PYVY=.e74597ed-35c7-4e06-93d7-55454a67e69d@github.com>
Message-ID: <e0vjbwlp-tGiN6eltKG-s7_pbFxYgdzN-2MQWnDyqz0=.04147cac-7091-4942-a498-a79c83ff8389@github.com>

On Wed, 8 Oct 2025 19:55:07 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 122:
>> 
>>> 120:     public boolean hasContent() {
>>> 121:         return ((flags & FLAGS_HAS_CONTENT) != 0);
>>> 122:     }
>> 
>> isEmpty could avoid introducing "content" as a loosely defined term.
>> It would be more similar to directories being empty or lists being empty.
>
> I've bounced between this several times. The thing is that a non-empty package directory will not have content if it only contains other directories, and seeing logic talking about a package being "empty" when it has child directories is weird/confusing. I've actually thought about this naming quite hard and I think it's more misleading to use the term "empty". However, since it's obviously still not clear enough maybe a different name altogether?
> 
> How about "hasResources()" or "hasResourceContent()" ?

Where is the presumed hierarchy of package non-emptyness used?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2417230590

From rriggs at openjdk.org  Tue Oct 21 20:04:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 21 Oct 2025 20:04:25 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v6]
In-Reply-To: <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>
Message-ID: <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>

On Wed, 8 Oct 2025 23:26:55 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
>> 
>> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changing existing package flags during writing to match altered flag values.

src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 133:

> 131: 
> 132:     /** Returns whether this reference exists only in preview mode. */
> 133:     public boolean isPreviewOnly() {

Pick either PreviewOnly or hasNormal and use consistently. (Even if one is the opposite of the other).

src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 83:

> 81:         if (mode.isPreviewModeEnabled())
> 82:             throw new UnsupportedOperationException(
> 83:                     "Preview mode not yet supported for exploded images");

I'd remove "yet", it implies some planned work.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2417236879
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2417256303

From thartmann at openjdk.org  Wed Oct 22 05:03:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 22 Oct 2025 05:03:37 GMT
Subject: [lworld] Integrated: 8366668: [lworld] Follow-up work from the array
 metadata re-work
In-Reply-To: <i0p2vjA7P1ykeeI5a1l6CM8edPJuRxDyDK5jYC36m94=.94c73383-38f5-4322-aa48-4e8e5441a42f@github.com>
References: <i0p2vjA7P1ykeeI5a1l6CM8edPJuRxDyDK5jYC36m94=.94c73383-38f5-4322-aa48-4e8e5441a42f@github.com>
Message-ID: <mmMYBNhN0JBXbBivUXm99AFBsw18-XRjUaX4QYvufPg=.3f2a2e81-243f-45b6-9957-838b2dd1b7a9@github.com>

On Fri, 10 Oct 2025 09:22:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This is a follow-up from [JDK-8366705](https://bugs.openjdk.org/browse/JDK-8366705) resolving a large number of ToDos in the implementation and tests.
> 
> There are a few remaining ToDos that I'll address with [JDK-8370341](https://bugs.openjdk.org/browse/JDK-8370341) because this change is getting too large and is blocking other work.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 74fc77fd
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/74fc77fd0239c0e76cae1983635b11ac440ca831
Stats:     915 lines in 45 files changed: 637 ins; 135 del; 143 mod

8366668: [lworld] Follow-up work from the array metadata re-work

Reviewed-by: fparain

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

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

From tobias.hartmann at oracle.com  Wed Oct 22 05:10:58 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 22 Oct 2025 07:10:58 +0200
Subject: how passing value types will work?
In-Reply-To: <CADFQZ756qKTKG+P9A3C_Y4-DFgiFeYZgy+VpxYukqQ1Jc621dw@mail.gmail.com>
References: <CADFQZ756qKTKG+P9A3C_Y4-DFgiFeYZgy+VpxYukqQ1Jc621dw@mail.gmail.com>
Message-ID: <559dd2c5-31ef-4de4-9e1e-5b72dcc1dff4@oracle.com>

Hi David,

On 10/20/25 00:56, david Grajales wrote:
> When a value object (let's say a value record) is being passed to a method, does it pass a copy of the values or a reference to where the values are in memory?

The JVM's highly optimizing JIT compiler (C2) will optimize calls such that value objects are passed by value, i.e. it will pass the individual field values in registers / stack slots. The same applies to returns, but there we are limited by the number of available registers.

Best regards,
Tobias

From thartmann at openjdk.org  Wed Oct 22 05:21:34 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 22 Oct 2025 05:21:34 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v7]
In-Reply-To: <ph3PkeJ5y40hjI7TOe_P9v5T8XKwUleexXhLvnA0QTU=.c24f7a33-bd67-40b4-a1b3-44ef99a03623@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
 <ph3PkeJ5y40hjI7TOe_P9v5T8XKwUleexXhLvnA0QTU=.c24f7a33-bd67-40b4-a1b3-44ef99a03623@github.com>
Message-ID: <pdXapOzN7CPN5etIw1Cd1kqjy7FeUoOYQm7C4SmOs7I=.4814af8b-8848-4477-9c86-7ec83071425b@github.com>

On Tue, 21 Oct 2025 15:16:34 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:
> 
>   grammar errors

All testing passed! I just see a few timeouts with `TestTearing.java` with `-XX:+UnlockDiagnosticVMOptions -XX:+SafepointALot -XX:+DeoptimizeALot -XX:+DeoptimizeNMethodBarriersALot -XX:MaxNodeLimit=100000` but I think they also happen without your changes.

When working on https://github.com/openjdk/valhalla/pull/1672, I also hit and fixed the issue you fixed in `src/hotspot/share/runtime/deoptimization.cpp`. I tried to cherry-pick your fix but missed the changes to the `reassign_fields_by_klass` arguments, so there's a little merge conflict now.

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

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

From thartmann at openjdk.org  Wed Oct 22 06:28:30 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 22 Oct 2025 06:28:30 GMT
Subject: [lworld] RFR: 8370349: [lworld] Generalize some memory
 optimizations for strict final fields
In-Reply-To: <a8Q6KBoCluUqdRZ6IW5vGefPbTnuneRL-YMBSxCLGdw=.c0d5d0fe-2054-4a4d-92d4-8c7db68a65fa@github.com>
References: <a8Q6KBoCluUqdRZ6IW5vGefPbTnuneRL-YMBSxCLGdw=.c0d5d0fe-2054-4a4d-92d4-8c7db68a65fa@github.com>
Message-ID: <6d-K8dxspibpmiBfUmLGCgBqamuCufHkHbiQikAEkqY=.efdb3cb5-d1a6-4ba9-a2d6-77aba3befc2d@github.com>

On Tue, 21 Oct 2025 17:07:21 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Some optimizations in `memnode.cpp` look at some properties of the pointer such as if it is a field of a value class, or if it is a field of a box class while the required assumption is that the pointer is to a strict final field. This PR cleans that up.
> 
> Please leave your reviews, thanks very much.

Nice refactoring, looks good to me!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1692#pullrequestreview-3363873195

From qamai at openjdk.org  Wed Oct 22 08:50:06 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Oct 2025 08:50:06 GMT
Subject: [lworld] RFR: 8370349: [lworld] Generalize some memory
 optimizations for strict final fields
In-Reply-To: <a8Q6KBoCluUqdRZ6IW5vGefPbTnuneRL-YMBSxCLGdw=.c0d5d0fe-2054-4a4d-92d4-8c7db68a65fa@github.com>
References: <a8Q6KBoCluUqdRZ6IW5vGefPbTnuneRL-YMBSxCLGdw=.c0d5d0fe-2054-4a4d-92d4-8c7db68a65fa@github.com>
Message-ID: <rK6ynoh45hVoBZV2azWfpWoIrM5W7uSdJksJysRpaM8=.3188714e-a376-4984-9526-5d75f06aa6cb@github.com>

On Tue, 21 Oct 2025 17:07:21 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Some optimizations in `memnode.cpp` look at some properties of the pointer such as if it is a field of a value class, or if it is a field of a box class while the required assumption is that the pointer is to a strict final field. This PR cleans that up.
> 
> Please leave your reviews, thanks very much.

Thanks a lot for the review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1692#issuecomment-3431153847

From qamai at openjdk.org  Wed Oct 22 08:53:10 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Oct 2025 08:53:10 GMT
Subject: [lworld] Integrated: 8370349: [lworld] Generalize some memory
 optimizations for strict final fields
In-Reply-To: <a8Q6KBoCluUqdRZ6IW5vGefPbTnuneRL-YMBSxCLGdw=.c0d5d0fe-2054-4a4d-92d4-8c7db68a65fa@github.com>
References: <a8Q6KBoCluUqdRZ6IW5vGefPbTnuneRL-YMBSxCLGdw=.c0d5d0fe-2054-4a4d-92d4-8c7db68a65fa@github.com>
Message-ID: <Q4UUxpa371BGvI1jvF52VdcUZ_yxqMVEy0VT1KmkPAY=.b4c31202-b66a-4a6b-a39f-90a89ef66ced@github.com>

On Tue, 21 Oct 2025 17:07:21 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Some optimizations in `memnode.cpp` look at some properties of the pointer such as if it is a field of a value class, or if it is a field of a box class while the required assumption is that the pointer is to a strict final field. This PR cleans that up.
> 
> Please leave your reviews, thanks very much.

This pull request has now been integrated.

Changeset: abc1d5b2
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378
Stats:     41 lines in 3 files changed: 18 ins; 11 del; 12 mod

8370349: [lworld] Generalize some memory optimizations for strict final fields

Reviewed-by: thartmann

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

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

From qamai at openjdk.org  Wed Oct 22 08:54:48 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Oct 2025 08:54:48 GMT
Subject: git: openjdk/valhalla: lworld: 8370349: [lworld] Generalize some
 memory optimizations for strict final fields
Message-ID: <fec24026-2866-4ccb-83c5-b272e64397cd@openjdk.org>

Changeset: abc1d5b2
Branch: lworld
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2025-10-22 08:50:22 +0000
URL:       https://git.openjdk.org/valhalla/commit/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378

8370349: [lworld] Generalize some memory optimizations for strict final fields

Reviewed-by: thartmann

! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp


From qamai at openjdk.org  Wed Oct 22 09:01:50 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Oct 2025 09:01:50 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v8]
In-Reply-To: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
Message-ID: <mholUVjYoCknO4jvpJXItO7A7-Di5CHeqZALzpu12xs=.dc3a4f01-e2d9-4c4b-be75-1570364b0c5f@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 with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'lworld' into flatfield
 - grammar errors
 - Remove flat accesses from sfn_worklist
 - revert redundant changes
 - revert redundant changes
 - Several fixes
 - fix gc barrier
 - Merge branch 'lworld' into flatfield
 - fix merge, assert GC barriers
 - Merge branch 'lworld' into flatfield
 - ... and 3 more: https://git.openjdk.org/valhalla/compare/abc1d5b2...9650fbba

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

Changes: https://git.openjdk.org/valhalla/pull/1518/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1518&range=07
  Stats: 975 lines in 16 files changed: 764 ins; 188 del; 23 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  Wed Oct 22 09:01:51 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Oct 2025 09:01:51 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v7]
In-Reply-To: <ph3PkeJ5y40hjI7TOe_P9v5T8XKwUleexXhLvnA0QTU=.c24f7a33-bd67-40b4-a1b3-44ef99a03623@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
 <ph3PkeJ5y40hjI7TOe_P9v5T8XKwUleexXhLvnA0QTU=.c24f7a33-bd67-40b4-a1b3-44ef99a03623@github.com>
Message-ID: <EEunM3CIY5P21D8FIQOtTAKdjwUt59auDIqBpVvoZ_E=.3c138bee-6159-40f3-b28a-01987d4edd42@github.com>

On Tue, 21 Oct 2025 15:16:34 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:
> 
>   grammar errors

Thanks very much, I have resolved the merge conflict.

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

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

From dsimms at openjdk.org  Wed Oct 22 14:07:53 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 22 Oct 2025 14:07:53 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <75k_-xbEyfFW6tCAHmL71AmvrLD6JBshZJXBYeADyc8=.d762e9cb-be66-48a7-96ac-dd4cf1627615@github.com>

Merge tag 'jdk-26+17' into lworld_merge_jdk_26_17
Added tag jdk-26+17 for changeset 2aafda19

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_26_17
 - Merge tag 'jdk-26+17' into lworld_merge_jdk_26_17
 - 8366948: AOT cache creation crashes when iterating training data
 - 8368015: Shenandoah: fix error in computation of average allocation rate
 - 8368174: Proactive initialization of @AOTSafeClassInitializer classes
 - 8368182: AOT cache creation fails with class defined by JNI
 - 8368335: Refactor the rest of Locale TestNG based tests to JUnit
 - 8368156: java/nio/file/Files/IsSameFile.java failing (win)
 - 8318662: Refactor some jdk/java/net/httpclient/http2 tests to JUnit
 - 8367702: PrintJob.getGraphics() should return null after PrintJob.end
 - ... and 128 more: https://git.openjdk.org/valhalla/compare/abc1d5b2...d002aee0

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

Changes: https://git.openjdk.org/valhalla/pull/1693/files
  Stats: 132290 lines in 1116 files changed: 116705 ins; 10523 del; 5062 mod
  Patch: https://git.openjdk.org/valhalla/pull/1693.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1693/head:pull/1693

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

From thartmann at openjdk.org  Wed Oct 22 14:11:34 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 22 Oct 2025 14:11:34 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement [v8]
In-Reply-To: <mholUVjYoCknO4jvpJXItO7A7-Di5CHeqZALzpu12xs=.dc3a4f01-e2d9-4c4b-be75-1570364b0c5f@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
 <mholUVjYoCknO4jvpJXItO7A7-Di5CHeqZALzpu12xs=.dc3a4f01-e2d9-4c4b-be75-1570364b0c5f@github.com>
Message-ID: <01Stv-ygm-2yoRA82pT5-IiEdUB0-Y7adwF9rFcqo7o=.d2dd3df9-3a7d-4872-b826-42ad561c1654@github.com>

On Wed, 22 Oct 2025 09:01:50 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 with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'lworld' into flatfield
>  - grammar errors
>  - Remove flat accesses from sfn_worklist
>  - revert redundant changes
>  - revert redundant changes
>  - Several fixes
>  - fix gc barrier
>  - Merge branch 'lworld' into flatfield
>  - fix merge, assert GC barriers
>  - Merge branch 'lworld' into flatfield
>  - ... and 3 more: https://git.openjdk.org/valhalla/compare/abc1d5b2...9650fbba

Thanks, still looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1518#pullrequestreview-3365981282

From qamai at openjdk.org  Wed Oct 22 15:08:24 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Oct 2025 15:08:24 GMT
Subject: [lworld] Integrated: 8364191: [lworld] Accesses to atomic flat fields
 prevent scalar replacement
In-Reply-To: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
References: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@github.com>
Message-ID: <U8_gX4o-N-qfnGBcAm3srw6dYNWRpc91VpB5SuiYuKY=.cde2f9fb-3e79-4914-a9ca-fe1dd9f3cd52@github.com>

On Mon, 28 Jul 2025 14:47:15 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.

This pull request has now been integrated.

Changeset: 2f89dea3
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2f89dea3d37b51901aea5fe6a94965b4cd5810c7
Stats:     975 lines in 16 files changed: 764 ins; 188 del; 23 mod

8364191: [lworld] Accesses to atomic flat fields prevent scalar replacement

Reviewed-by: thartmann

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

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

From dsimms at openjdk.org  Wed Oct 22 15:20:42 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 22 Oct 2025 15:20:42 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <75k_-xbEyfFW6tCAHmL71AmvrLD6JBshZJXBYeADyc8=.d762e9cb-be66-48a7-96ac-dd4cf1627615@github.com>
References: <75k_-xbEyfFW6tCAHmL71AmvrLD6JBshZJXBYeADyc8=.d762e9cb-be66-48a7-96ac-dd4cf1627615@github.com>
Message-ID: <qgyY7ETdrXnSdLvLcd7637rAnnZlkQ_ffeUFB2Lfocc=.d5dbb500-a9b7-4f4c-8fe2-6ded5a27f06d@github.com>

On Wed, 22 Oct 2025 13:54:11 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+17' into lworld_merge_jdk_26_17
> Added tag jdk-26+17 for changeset 2aafda19

This pull request has now been integrated.

Changeset: 66c0082c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/66c0082c54b039e52182b6fa760d426bee017496
Stats:     132290 lines in 1116 files changed: 116705 ins; 10523 del; 5062 mod

Merge jdk

Merge jdk-26+17

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

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

From coleenp at openjdk.org  Wed Oct 22 17:58:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Oct 2025 17:58:42 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks [v2]
In-Reply-To: <hFHG0JWMnMba0sgFFwV3c2VpiDTwMLB35n2OmaALOzc=.1a6777b3-0594-45da-b67e-70a404e7115d@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
 <hFHG0JWMnMba0sgFFwV3c2VpiDTwMLB35n2OmaALOzc=.1a6777b3-0594-45da-b67e-70a404e7115d@github.com>
Message-ID: <rbWCQiFp0iMSOsr-Ed3Sxchs1cEPcXbpj5a_Q1nCmus=.b51adb51-3aa7-4b68-be28-95f4ee62f57a@github.com>

On Mon, 20 Oct 2025 09:07:23 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR mirrors the changes made to [the compiler](https://github.com/openjdk/valhalla/pull/1681) `jtreg` testing setup ([issue](https://bugs.openjdk.org/browse/JDK-8369437)).
>> 
>> **Concretely:**
>> * Split multiple (independent) `@run`s into separate `@test` blocks, specifying new IDs where appropriate.
>> * Added packages where we missed them for consistency. This excludes places where the test setup does not allow for packages or for tests that are disabled (some of which don't compile, as our model is evolving). 
>> * Changed `@run main/othervm` into `@run main` when there was no flag passed.
>> 
>> **Impact:**
>> 
>> I compared machine execution time in tiers 1-4 to `jdk-26-valhalla+1-89` (which my changes are based on). 
>> 
>> | | lworld | lworld + patch | improvement
>> -- | -- | -- | -- 
>> tier1 | 1d 00h 26m 16s |  1d 00h 13m 20s | ~ - 3 mins
>> tier2 | 1d 03h 16m 04s | 1d 01h 24m 05s | ~ -2 hours
>> tier3 | 2d 17h 29m 13s | 2d 17h 16m 15s | ~ -13 mins
>> tier4 | 2d 11h 32m 26s | 2d 01h 05m 40s | ~ -10 hours
>> 
>> Overall, the trend shows shorter execution times. (And by extension, probably less electricity usage too :))
>> 
>> Note that the CI ran a few extra tasks at tiers 2,  (two orders of magnitude less compared to the total number of tasks) than my personal run did. I don't think these will impact the results significantly.
>> 
>> *Disclaimers: these measurements were run before adding packages and getting rid of a few leftover `main/othervm`, although these should not change the results significantly. Also, this is very ad-hoc "benchmarking," variance is not measured.*
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add names to WrappersOffsetTest.

Marked as reviewed by coleenp (Committer).

test/hotspot/jtreg/runtime/valhalla/inlinetypes/WrappersOffsetTest.java line 26:

> 24: 
> 25: /*
> 26:  * @test id=nf-na-nn

The ids make sense once you see the the options.  So they're okay.

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

PR Review: https://git.openjdk.org/valhalla/pull/1682#pullrequestreview-3366876347
PR Review Comment: https://git.openjdk.org/valhalla/pull/1682#discussion_r2451867907

From fparain at openjdk.org  Wed Oct 22 18:01:02 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 22 Oct 2025 18:01:02 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method
Message-ID: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>

This is an alternate version of the substitutability method.
To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

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

Commit messages:
 - Add alternate version of the substitutability method

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

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

From fparain at openjdk.org  Wed Oct 22 18:17:30 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 22 Oct 2025 18:17:30 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
Message-ID: <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>

> This is an alternate version of the substitutability method.
> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'upstream/lworld' into new_acmp
 - Add alternate version of the substitutability method

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

Changes: https://git.openjdk.org/valhalla/pull/1695/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1695&range=01
  Stats: 334 lines in 18 files changed: 329 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1695.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1695/head:pull/1695

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

From duke at openjdk.org  Wed Oct 22 18:31:25 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 22 Oct 2025 18:31:25 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v6]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <5b30yHa3UNwID1D5GI_vzy6ikUG_GJfqKXYRBCJGn9k=.7e656a5f-321e-4a24-baaf-171657c0ee42@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Resquashing after sync.
   
   * feedback and remove unused code
   * new tests for ImageLocation
   * Restoring lost changes and updating some comments.
   * add system property guard to preview mode
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Merge branch 'jdk_8368333_java/squashed' into jdk_8368467_reader/squashed
 - [[RESET BRANCH FOR MERGE]]
 - feedback and remove unused code
 - Resync after dependent PR change.
   
   * new tests for ImageLocation
   * Restoring lost changes and updating some comments.
   * add system property guard to preview mode
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Merge branch 'jdk_8368333_java/squashed' into temp_reader
 - [[RESET BRANCH FOR MERGE]]
 - Restoring lost changes and updating some comments.
 - add system property guard to preview mode
 - jimage writer changes to support preview mode.
   
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.

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

Changes: https://git.openjdk.org/valhalla/pull/1621/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=05
  Stats: 2048 lines in 14 files changed: 892 ins; 155 del; 1001 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

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

From duke at openjdk.org  Wed Oct 22 19:25:24 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 22 Oct 2025 19:25:24 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v6]
In-Reply-To: <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>
 <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>
Message-ID: <1KBM5bqQBv7aXkRPMv52aE0SOscHm5vzc9t50VJaBA8=.01baf601-61ca-4672-a99c-76c5f105d19d@github.com>

On Thu, 9 Oct 2025 16:03:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changing existing package flags during writing to match altered flag values.
>
> src/java.base/share/classes/jdk/internal/jrtfs/SystemImage.java line 83:
> 
>> 81:         if (mode.isPreviewModeEnabled())
>> 82:             throw new UnsupportedOperationException(
>> 83:                     "Preview mode not yet supported for exploded images");
> 
> I'd remove "yet", it implies some planned work.

Well I do plan to do it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2453132641

From duke at openjdk.org  Wed Oct 22 19:28:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 22 Oct 2025 19:28:33 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v6]
In-Reply-To: <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>
 <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>
Message-ID: <B3NeaC3cZlfBlcPmwx1_7iQf2m1t4TQSEDWXMuIBFMk=.eaa9c5f7-cc6b-4d31-b139-4dfa94bed517@github.com>

On Thu, 9 Oct 2025 15:56:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changing existing package flags during writing to match altered flag values.
>
> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 133:
> 
>> 131: 
>> 132:     /** Returns whether this reference exists only in preview mode. */
>> 133:     public boolean isPreviewOnly() {
> 
> Pick either PreviewOnly or hasNormal and use consistently. (Even if one is the opposite of the other).

They are NOT opposites. It is not possible to use only one or these flags and continue to be logically correct.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2453138935

From duke at openjdk.org  Wed Oct 22 19:41:23 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 22 Oct 2025 19:41:23 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v7]
In-Reply-To: <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
 <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
Message-ID: <RcV9JYxCYZSDkckXnora8V0yvXkQZ9OHep0hHt-pPJM=.3fd34f9d-9c4a-4efd-8b50-fbf67a450978@github.com>

On Tue, 21 Oct 2025 19:43:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Rolled up changes after rebase.
>>    
>>    * Removing package root flag based on feedback.
>>    * Changing existing package flags during writing to match altered flag values.
>>    * Feedback changes, and fixing some comments.
>>    * Renaming slightly confusing "testEncoder" method.
>>    * Fixing unit tests to use new constructor.
>>    * Word smithing flags definitions.
>>    * Add workaround until new image writing code is in
>>    * Clarifying flag docs for /packages/xxx case
>>    * Java ImageReader changes for preview mode
>>  - Merge branch 'jdk_8366093_cpp/squashed' into jdk_8368333_java/squashed
>>  - [[RESET BRANCH FOR MERGE]]
>>  - Removing package root flag based on feedback.
>>  - Changing existing package flags during writing to match altered flag values.
>>  - Feedback changes, and fixing some comments.
>>  - Test fixes and feedback changes.
>>    
>>    * Renaming slightly confusing "testEncoder" method.
>>    * Fixing unit tests to use new constructor.
>>  - Manually deleting ImageReaderFactory (it returned somehow)
>>  - Word smithing flags definitions.
>>  - Add workaround until new image writing code is in
>>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/802d18fe...9bbc26c1
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 282:
> 
>> 280:         // preview-only nodes. This is used to add preview-only content to
>> 281:         // directories as they are completed.
>> 282:         private final HashMap<String, Directory> previewDirectoriesToMerge;
> 
> Can this be cleared or freed after the ImageReader is open. Its no longer needed.

It's used when directories are completed (as stated in the comment):


    List<Node> previewOnlyNodes = getPreviewNodesToMerge(dir);
    ...
    children.addAll(previewOnlyNodes);

> src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java line 38:
> 
>> 36:     // String offset constants are useful for efficient classification
>> 37:     // of location entries without string comparison. These may change
>> 38:     // between jimage versions (they are checked during initialization).
> 
> The checking seem only to be done when ImageStringsWriter is loaded/initialized.
> There may be a small risk that a mismatch of the image with the ImageStringsReader could occur.
> Can they be checked also by the reader?

Hmm, I don't see a nice way to do this at runtime since you can't lookup string offsets by their value (as far as I can see).

It's no more fragile than the old code (which had hard-coded constants for "class" and "" (and wasn't self-checking their validity). At least now it's tested at build time.

If the version number matches it should be safe. I'll add a comment about how changing existing entries is problematic.

> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 120:
> 
>> 118:      * under many modules, it only has content in one.
>> 119:      */
>> 120:     public boolean hasContent() {
> 
> As suggested, `hasResoruces` would be consistent with the lookups for resources.

Will do.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2453165416
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2453158966
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2453160430

From rriggs at openjdk.org  Wed Oct 22 19:41:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Oct 2025 19:41:25 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v6]
In-Reply-To: <B3NeaC3cZlfBlcPmwx1_7iQf2m1t4TQSEDWXMuIBFMk=.eaa9c5f7-cc6b-4d31-b139-4dfa94bed517@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>
 <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>
 <B3NeaC3cZlfBlcPmwx1_7iQf2m1t4TQSEDWXMuIBFMk=.eaa9c5f7-cc6b-4d31-b139-4dfa94bed517@github.com>
Message-ID: <U6cMchyMzg6fQsecZ3MPVVYZrDh8oB0464rQ8dcXCDk=.9c3419b1-0593-402d-aa8f-07913d543304@github.com>

On Wed, 22 Oct 2025 19:25:59 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 133:
>> 
>>> 131: 
>>> 132:     /** Returns whether this reference exists only in preview mode. */
>>> 133:     public boolean isPreviewOnly() {
>> 
>> Pick either PreviewOnly or hasNormal and use consistently. (Even if one is the opposite of the other).
>
> They are NOT opposites. It is not possible to use only one or these flags and continue to be logically correct.

Hmm, the implementation of `isPreviewOnly()` is exactly `!hasNormalVersion(flags)`

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2453155191

From duke at openjdk.org  Wed Oct 22 19:45:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 22 Oct 2025 19:45:10 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v7]
In-Reply-To: <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
 <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
Message-ID: <TbXb9lpV_GRHnuGARjtVy_slaWyWVtYZTrxfwB3RdhI=.b69e6d3b-02f6-48dc-b883-4ee9ef7bccaa@github.com>

On Tue, 21 Oct 2025 19:53:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Rolled up changes after rebase.
>>    
>>    * Removing package root flag based on feedback.
>>    * Changing existing package flags during writing to match altered flag values.
>>    * Feedback changes, and fixing some comments.
>>    * Renaming slightly confusing "testEncoder" method.
>>    * Fixing unit tests to use new constructor.
>>    * Word smithing flags definitions.
>>    * Add workaround until new image writing code is in
>>    * Clarifying flag docs for /packages/xxx case
>>    * Java ImageReader changes for preview mode
>>  - Merge branch 'jdk_8366093_cpp/squashed' into jdk_8368333_java/squashed
>>  - [[RESET BRANCH FOR MERGE]]
>>  - Removing package root flag based on feedback.
>>  - Changing existing package flags during writing to match altered flag values.
>>  - Feedback changes, and fixing some comments.
>>  - Test fixes and feedback changes.
>>    
>>    * Renaming slightly confusing "testEncoder" method.
>>    * Fixing unit tests to use new constructor.
>>  - Manually deleting ImageReaderFactory (it returned somehow)
>>  - Word smithing flags definitions.
>>  - Add workaround until new image writing code is in
>>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/4a672f4e...9bbc26c1
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 525:
> 
>> 523:             }
>> 524:             ImageLocation loc = findLocation(moduleName, resourcePath);
>> 525:             return loc != null && loc.getType() == RESOURCE;
> 
> Would there be any benefit to caching the resource here, since it has been found and will likely be opened again.

Very unlikely to be worth it, and outside the scope of this work (since nothing I'm doing changes this behaviour).

ImageReader deals with small nodes and has a surprisingly low footprint. Caching content would require managing a size bounded cache, since it's well over 100MB of content.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2453173787

From fparain at openjdk.org  Wed Oct 22 19:59:07 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 22 Oct 2025 19:59:07 GMT
Subject: [lworld] RFR: 8368933: [lworld] Unsafe.arrayBaseOffset() ambiguous
In-Reply-To: <qAzU1e-auj7FcvkCj6vMw3aJs1MQ7cA5LSOeRSzzQSA=.5a69cf98-dcc8-4635-8dba-77f8f1b1bef1@github.com>
References: <qAzU1e-auj7FcvkCj6vMw3aJs1MQ7cA5LSOeRSzzQSA=.5a69cf98-dcc8-4635-8dba-77f8f1b1bef1@github.com>
Message-ID: <ryS4ImRN_iLm5kZ6YTtPP3Lr2FxwXSgTbSJ081Ifsxw=.ca8fdc69-83c3-4a43-ae16-b5d0b420209e@github.com>

On Fri, 17 Oct 2025 16:13:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Renaming of Unsafe methods to prevent ambiguity when null is passed in argument.
> 
> Tested with Mach5 tier1-3.

Thank you for the review Chen!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1684#issuecomment-3433993435

From fparain at openjdk.org  Wed Oct 22 19:59:07 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 22 Oct 2025 19:59:07 GMT
Subject: [lworld] Integrated: 8368933: [lworld] Unsafe.arrayBaseOffset()
 ambiguous
In-Reply-To: <qAzU1e-auj7FcvkCj6vMw3aJs1MQ7cA5LSOeRSzzQSA=.5a69cf98-dcc8-4635-8dba-77f8f1b1bef1@github.com>
References: <qAzU1e-auj7FcvkCj6vMw3aJs1MQ7cA5LSOeRSzzQSA=.5a69cf98-dcc8-4635-8dba-77f8f1b1bef1@github.com>
Message-ID: <KL1B6uedjxI_wMAw8iPMrR4oXCv4kFAuyBgVpbSdoMU=.e78e52f0-2f7b-4ec7-931d-4a68231f7769@github.com>

On Fri, 17 Oct 2025 16:13:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Renaming of Unsafe methods to prevent ambiguity when null is passed in argument.
> 
> Tested with Mach5 tier1-3.

This pull request has now been integrated.

Changeset: 8845b6ae
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8845b6aec5e69ff120803f234e662e0248ca01d0
Stats:     65 lines in 6 files changed: 10 ins; 1 del; 54 mod

8368933: [lworld] Unsafe.arrayBaseOffset() ambiguous

Reviewed-by: liach

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

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

From liach at openjdk.org  Wed Oct 22 21:55:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Oct 2025 21:55:16 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
Message-ID: <TIVyPa2k3BOcGb3fO9TL77jrfU8BscN6fLuEziyDFsM=.b25fcb46-76f4-4a89-a548-3508684f5c5c@github.com>

On Wed, 22 Oct 2025 18:17:30 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>  - Add alternate version of the substitutability method

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

> 1582:     FieldInfo::FieldFlags fflags2(0);
> 1583:     fflags2.update_injected(true);
> 1584:     fflags2.update_stable(true);

If c2 can model the field map read as a stable array read, this allows ValueObjectMethods to generate efficient code for specialized value types in the future. ?

src/hotspot/share/classfile/fieldLayoutBuilder.hpp line 289:

> 287:   FieldLayout* _layout;
> 288:   FieldLayout* _static_layout;
> 289:   GrowableArray<Pair<int,int>>* _nonoop_acmp_map ;

Suggestion:

  GrowableArray<Pair<int,int>>* _nonoop_acmp_map;

src/hotspot/share/oops/instanceKlass.hpp line 650:

> 648:   ReferenceType reference_type() const     { return (ReferenceType)_reference_type; }
> 649: 
> 650:   int acmp_maps_offset() const { return _acmp_maps_offset; }

Probably assert `_acmp_maps_offset != 0`

src/hotspot/share/runtime/globals.hpp line 2053:

> 2051:           "binary search over simple linear search." )                      \
> 2052:                                                                             \
> 2053:   product(bool, UseAltSubstitutabilityMethod, false,                        \

We might need this flag on/off for core-libs tests in addition to runtime tests.

src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java line 1417:

> 1415:         int size = map[i * 2 + 2];
> 1416:         int nlong = size / 8;
> 1417:         for (int j = 0; j < nlong; j++) {

Are we sure that for all value objects with `size >= 8`, they are always 8-byte aligned?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2453314756
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2453373333
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2453329386
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2453432714
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2453430849

From dsimms at openjdk.org  Thu Oct 23 07:00:30 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 23 Oct 2025 07:00:30 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <g8ZIzswOYG9SQONeo7swa6ZUClKSqUhh6cY-UiTR7Ac=.60554315-f406-44fc-b241-0a05ea12f65b@github.com>

Merge tag 'jdk-26+18' into lworld_merge_jdk_26_18

Added tag jdk-26+18 for changeset 5251405c

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

Commit messages:
 - Merge jdk
 - 8368848: JShell's code completion not always working for multi-snippet inputs
 - 8338197: [ubsan] ad_x86.hpp:6417:11: runtime error: shift exponent 100 is too large for 32-bit type 'unsigned int'
 - 8368698: runtime/cds/appcds/aotCache/OldClassSupport.java assert(can_add()) failed: Cannot add TrainingData objects
 - 8368968: FloatingDecimal: Clean up unused code
 - 8368985: Small Float16 refactorings
 - 6177299: [Fmt-Nu] NumberFormat.getPercentInstance() does not work correctly
 - 8367704: Fix minor documentation issues in java.time.**
 - 8368938: Remove ObjectWaiter::badObjectWaiterPtr
 - 8368675: IGV: nodes are wrongly marked as changed in the difference view
 - ... and 93 more: https://git.openjdk.org/valhalla/compare/8845b6ae...85298c19

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

Changes: https://git.openjdk.org/valhalla/pull/1696/files
  Stats: 11980 lines in 391 files changed: 6399 ins; 3203 del; 2378 mod
  Patch: https://git.openjdk.org/valhalla/pull/1696.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1696/head:pull/1696

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

From forax at univ-mlv.fr  Thu Oct 23 07:25:36 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 23 Oct 2025 09:25:36 +0200 (CEST)
Subject: oops crash
Message-ID: <2102757184.21885760.1761204336415.JavaMail.zimbra@univ-eiffel.fr>

It seems that the latest version crashes when trying to run maven surefire
(i'm using the build of aleksey shipilev, so more or less the latest version of the valhalla repo)

  https://github.com/forax/weather-alert/actions/runs/18740633928/job/53456041212

regards,
R?mi

From phubner at openjdk.org  Thu Oct 23 07:40:31 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 23 Oct 2025 07:40:31 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks [v2]
In-Reply-To: <xrpNIkkCJtskj-AeeLvSabqpFSIIsQzaMV-FJlw_j7Q=.65debacc-06f1-45a9-9acb-58b01615b3f8@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
 <hFHG0JWMnMba0sgFFwV3c2VpiDTwMLB35n2OmaALOzc=.1a6777b3-0594-45da-b67e-70a404e7115d@github.com>
 <xrpNIkkCJtskj-AeeLvSabqpFSIIsQzaMV-FJlw_j7Q=.65debacc-06f1-45a9-9acb-58b01615b3f8@github.com>
Message-ID: <2grDlA6qsdbYNXxqBzi6OdVzchK9CWuh2IMGC9kXZUU=.57e4090a-9b6a-4075-bf34-9f75e387718d@github.com>

On Mon, 20 Oct 2025 11:38:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add names to WrappersOffsetTest.
>
> Marked as reviewed by chagedorn (Committer).

Thanks for the reviews, @chhagedorn @coleenp

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

PR Comment: https://git.openjdk.org/valhalla/pull/1682#issuecomment-3435552604

From duke at openjdk.org  Thu Oct 23 07:40:33 2025
From: duke at openjdk.org (duke)
Date: Thu, 23 Oct 2025 07:40:33 GMT
Subject: [lworld] RFR: 8369893: [lworld] Split multiple @run statements in
 runtime tests into separate @test blocks [v2]
In-Reply-To: <hFHG0JWMnMba0sgFFwV3c2VpiDTwMLB35n2OmaALOzc=.1a6777b3-0594-45da-b67e-70a404e7115d@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
 <hFHG0JWMnMba0sgFFwV3c2VpiDTwMLB35n2OmaALOzc=.1a6777b3-0594-45da-b67e-70a404e7115d@github.com>
Message-ID: <6q6UD-gNJajiZH45vUvlJMoqGu9cRooUYnCysE2Z4RM=.f16c35ef-b9fd-4dc0-b582-0d664135dc35@github.com>

On Mon, 20 Oct 2025 09:07:23 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR mirrors the changes made to [the compiler](https://github.com/openjdk/valhalla/pull/1681) `jtreg` testing setup ([issue](https://bugs.openjdk.org/browse/JDK-8369437)).
>> 
>> **Concretely:**
>> * Split multiple (independent) `@run`s into separate `@test` blocks, specifying new IDs where appropriate.
>> * Added packages where we missed them for consistency. This excludes places where the test setup does not allow for packages or for tests that are disabled (some of which don't compile, as our model is evolving). 
>> * Changed `@run main/othervm` into `@run main` when there was no flag passed.
>> 
>> **Impact:**
>> 
>> I compared machine execution time in tiers 1-4 to `jdk-26-valhalla+1-89` (which my changes are based on). 
>> 
>> | | lworld | lworld + patch | improvement
>> -- | -- | -- | -- 
>> tier1 | 1d 00h 26m 16s |  1d 00h 13m 20s | ~ - 3 mins
>> tier2 | 1d 03h 16m 04s | 1d 01h 24m 05s | ~ -2 hours
>> tier3 | 2d 17h 29m 13s | 2d 17h 16m 15s | ~ -13 mins
>> tier4 | 2d 11h 32m 26s | 2d 01h 05m 40s | ~ -10 hours
>> 
>> Overall, the trend shows shorter execution times. (And by extension, probably less electricity usage too :))
>> 
>> Note that the CI ran a few extra tasks at tiers 2,  (two orders of magnitude less compared to the total number of tasks) than my personal run did. I don't think these will impact the results significantly.
>> 
>> *Disclaimers: these measurements were run before adding packages and getting rid of a few leftover `main/othervm`, although these should not change the results significantly. Also, this is very ad-hoc "benchmarking," variance is not measured.*
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add names to WrappersOffsetTest.

@Arraying 
Your change (at version a3cc584460dd874ce6b4fa05d9835eda3a47815b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1682#issuecomment-3435555610

From chagedorn at openjdk.org  Thu Oct 23 07:41:20 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 23 Oct 2025 07:41:20 GMT
Subject: [lworld] RFR: 8369805: [lworld] C2: assert(is_InlineType()) failed:
 invalid node class: Con
Message-ID: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>

`TestLWorld.java` was failing intermittently with `-XX:+StressIGVN` and `-XX:+StressLoopPeeling` due to not handling `top` correctly in `InlineTypeNode::merge_with()` during IGVN.

We have the following graph during IGVN:
<img width="558" height="304" alt="image" src="https://github.com/user-attachments/assets/6c146038-208f-4f5a-bcfa-5be0d5b67537" />

The following steps happen:
1. `6837 Phi` was created in Loop Peeling to merge data nodes from the peeled iteration and the remaining loop (this is the reason we are only seeing this failure with `StressLoopPeeling` - there are simply more chances with more phis to get unlucky and hit the assert).
2. When processing `6837 Phi` in IGVN, we apply `PhiNode::try_push_inline_types_down()` in order to push the `InlineType` nodes down recursively. 
3. Doing it recursively, we will then call `PhiNode::try_push_inline_types_down()` on `6535 Phi`.
4. We create a new initial `InlineType` node based on the same klass as `6259 InlineType` (i.e. the same fields) but use `Phis` for the inputs or `InlineType` nodes if the fields are value objects themselves:
https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L87-L89
This new `InlineType` node represents the resulting "pushed down" `InlineType`. Let's call it `inline-type-result`.
5.  We now populate the phi inputs of `inline-type-result` by visiting the `InlineType` inputs of `6535 Phi`.
6. We visit the first input `6259 InlineType`: We update the first input of the phis of `inline-type-result` by calling `merge_with()` on `inline-type-result`.
7. We visit all inputs of `inline-type-result`: These are either phis or `InlineType` nodes (see step 4). When we see an `InlineType` input, we must also see an `InlineType` input for `6259 InlineType` because we used the same klass in step 4. However, we miss here that we could also have a top input because the node is actually being removed in IGVN because we only take the other path of `6535 Phi`. Therefore this assumption is wrong:
https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L157-L161
and we crash because `val2` is top.

The fix is straight forward to stop the merge since the node is dead. Since this is highly intermittent and occurring with `TestLWorld.java` only, I have not added a separate test case. Additionally to standard testing, I also ran `TestLWorld.java` 100 times in the CI with the triggering flags without any failure anymore.

Thanks,
Christian

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

Commit messages:
 - typo
 - update
 - 8369805: [lworld] C2: assert(is_InlineType()) failed: invalid node class: Con

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

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

From phubner at openjdk.org  Thu Oct 23 07:48:36 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 23 Oct 2025 07:48:36 GMT
Subject: [lworld] Integrated: 8369893: [lworld] Split multiple @run statements
 in runtime tests into separate @test blocks
In-Reply-To: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
References: <CX_6719bWsBJ6p4VmHiExr1MmvJEj5nfKFXgqXR04j0=.4f162f0f-f32d-4e43-bf0f-80b04ae62a67@github.com>
Message-ID: <uQVD5ghdv2rFebzIq8HkhOGJr3zMECq2SrJpsyRbCqA=.48bb4b63-2c4a-4498-9cfa-679eb87f77d9@github.com>

On Fri, 17 Oct 2025 07:59:24 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This PR mirrors the changes made to [the compiler](https://github.com/openjdk/valhalla/pull/1681) `jtreg` testing setup ([issue](https://bugs.openjdk.org/browse/JDK-8369437)).
> 
> **Concretely:**
> * Split multiple (independent) `@run`s into separate `@test` blocks, specifying new IDs where appropriate.
> * Added packages where we missed them for consistency. This excludes places where the test setup does not allow for packages or for tests that are disabled (some of which don't compile, as our model is evolving). 
> * Changed `@run main/othervm` into `@run main` when there was no flag passed.
> 
> **Impact:**
> 
> I compared machine execution time in tiers 1-4 to `jdk-26-valhalla+1-89` (which my changes are based on). 
> 
> | | lworld | lworld + patch | improvement
> -- | -- | -- | -- 
> tier1 | 1d 00h 26m 16s |  1d 00h 13m 20s | ~ - 3 mins
> tier2 | 1d 03h 16m 04s | 1d 01h 24m 05s | ~ -2 hours
> tier3 | 2d 17h 29m 13s | 2d 17h 16m 15s | ~ -13 mins
> tier4 | 2d 11h 32m 26s | 2d 01h 05m 40s | ~ -10 hours
> 
> Overall, the trend shows shorter execution times. (And by extension, probably less electricity usage too :))
> 
> Note that the CI ran a few extra tasks at tiers 2,  (two orders of magnitude less compared to the total number of tasks) than my personal run did. I don't think these will impact the results significantly.
> 
> *Disclaimers: these measurements were run before adding packages and getting rid of a few leftover `main/othervm`, although these should not change the results significantly. Also, this is very ad-hoc "benchmarking," variance is not measured.*

This pull request has now been integrated.

Changeset: f2299db1
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f2299db186da9519d47a7089da5c98bb94ed19a2
Stats:     426 lines in 52 files changed: 279 ins; 1 del; 146 mod

8369893: [lworld] Split multiple @run statements in runtime tests into separate @test blocks

Reviewed-by: chagedorn, coleenp

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

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

From dsimms at openjdk.org  Thu Oct 23 08:17:43 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 23 Oct 2025 08:17:43 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <g8ZIzswOYG9SQONeo7swa6ZUClKSqUhh6cY-UiTR7Ac=.60554315-f406-44fc-b241-0a05ea12f65b@github.com>
References: <g8ZIzswOYG9SQONeo7swa6ZUClKSqUhh6cY-UiTR7Ac=.60554315-f406-44fc-b241-0a05ea12f65b@github.com>
Message-ID: <P5BF794c8hoDXqFrhjqFyh1cMQ-hcPE0Q1dKvpiwg8o=.30a0bc8f-335d-4f7b-8948-85e229466fb3@github.com>

On Thu, 23 Oct 2025 06:51:54 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+18' into lworld_merge_jdk_26_18
> 
> Added tag jdk-26+18 for changeset 5251405c

This pull request has now been integrated.

Changeset: 412ec882
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/412ec882767d3ee1792d1e0f98da54ff800c60ce
Stats:     11980 lines in 391 files changed: 6399 ins; 3203 del; 2378 mod

Merge jdk

Merge jdk-26+18

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

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

From dsimms at openjdk.org  Thu Oct 23 08:25:26 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 23 Oct 2025 08:25:26 GMT
Subject: git: openjdk/valhalla: lworld: 103 new changesets
Message-ID: <e52af91c-227a-488d-b1be-4d3253245a09@openjdk.org>

Changeset: 17244c69
Branch: lworld
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2025-09-25 05:41:32 +0000
URL:       https://git.openjdk.org/valhalla/commit/17244c699ad20fafe7448678a53266ce6bf017e5

8368159: Significant performance overhead when started with jdwp agent and unattached debugger

Reviewed-by: lmesnik, cjplummer

! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp

Changeset: e6ddb396
Branch: lworld
Author:    Hamlin Li <mli at openjdk.org>
Date:      2025-09-25 08:11:15 +0000
URL:       https://git.openjdk.org/valhalla/commit/e6ddb39635cb8b5a21445a50b28aeeebc9e1d9d3

8368525: nmethod ic cleanup

Reviewed-by: chagedorn, mhaessig

! src/hotspot/share/code/nmethod.cpp

Changeset: 847b107d
Branch: lworld
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
Date:      2025-09-25 08:15:45 +0000
URL:       https://git.openjdk.org/valhalla/commit/847b107df821e0c1d347383f1858d505137eb724

8365191: Cleanup after removing LockingMode related code

Reviewed-by: coleenp, dholmes, yzheng, mdoerr, ayang, fyang, amitkumar

! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.hpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp
! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.hpp
! src/hotspot/share/c1/c1_CodeStubs.hpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/runtime/basicLock.cpp
! src/hotspot/share/runtime/basicLock.hpp
! src/hotspot/share/runtime/basicLock.inline.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/synchronizer.inline.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Mark.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicLock.java

Changeset: ba44656b
Branch: lworld
Author:    Alice Pellegrini <dev at alicepellegrini.me>
Committer: Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2025-09-25 08:44:14 +0000
URL:       https://git.openjdk.org/valhalla/commit/ba44656b97b7103d96718452e300df8a6bd59c87

8366454: TLS1.3 server fails with bad_record_mac when receiving encrypted records with empty body

Co-authored-by: Daniel Jeli?ski <djelinski at openjdk.org>
Reviewed-by: djelinski

! src/java.base/share/classes/sun/security/ssl/Alert.java
! src/java.base/share/classes/sun/security/ssl/SSLCipher.java
! test/jdk/sun/security/ssl/SSLEngineImpl/SSLEngineEmptyFragments.java
! test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketEmptyFragments.java

Changeset: d407ef65
Branch: lworld
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
Date:      2025-09-25 09:38:43 +0000
URL:       https://git.openjdk.org/valhalla/commit/d407ef651032de687e3d4a2a2db211cab1016676

8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace

Reviewed-by: lkorinth, ayang, tschatzl

! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.inline.hpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/os_windows.inline.hpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp
! src/hotspot/share/gc/parallel/psYoungGen.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: d85e410c
Branch: lworld
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2025-09-25 09:42:53 +0000
URL:       https://git.openjdk.org/valhalla/commit/d85e410c191bdcc8c20498f1c3c4516193bc79dd

8368546: java/net/httpclient/RedirectTimeoutTest.java fails intermittently for HTTP/3 in tier7

Reviewed-by: jpai, syan, djelinski, vyazici

! test/jdk/java/net/httpclient/RedirectTimeoutTest.java

Changeset: 4f4030a4
Branch: lworld
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: Mark Sheppard <msheppar at openjdk.org>
Date:      2025-09-25 09:51:51 +0000
URL:       https://git.openjdk.org/valhalla/commit/4f4030a423d04c8f488d143f0eda4a8de9dbd469

8333526: Restructure java/nio/channels/DatagramChannel/StressNativeSignal.java to a fail fast exception handling policy

Reviewed-by: dfuchs

! test/jdk/java/nio/channels/DatagramChannel/StressNativeSignal.java

Changeset: 44cb9cad
Branch: lworld
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2025-09-25 09:59:37 +0000
URL:       https://git.openjdk.org/valhalla/commit/44cb9cad263b4fe2749fd6c223b657d77dca5119

8368518: [s390x] test failure with failed: wrong size of mach node

Reviewed-by: dlong, mdoerr, lucy

! src/hotspot/cpu/s390/c2_globals_s390.hpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp

Changeset: 67cb53d0
Branch: lworld
Author:    Dingli Zhang <dzhang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2025-09-25 10:06:57 +0000
URL:       https://git.openjdk.org/valhalla/commit/67cb53d0888adfeb2909296e21d0532bc3643326

8368206: RISC-V: compiler/vectorapi/VectorMaskCompareNotTest.java fails when running without RVV

Reviewed-by: fyang, mhaessig, mli

! test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java

Changeset: 2407eb05
Branch: lworld
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2025-09-25 10:08:56 +0000
URL:       https://git.openjdk.org/valhalla/commit/2407eb0522d192135a6bed52e88be5a59cba8f6c

8367867: [macosx] Ignorable whitespace in text not removed when printing

Reviewed-by: prr, serb

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterGraphics.java
! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java
! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java
! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java

Changeset: 52e55046
Branch: lworld
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Ivan Walulya <iwalulya at openjdk.org>
Date:      2025-09-25 11:55:18 +0000
URL:       https://git.openjdk.org/valhalla/commit/52e550462798c568a8a5457af2f9554fd784cd8a

8368089: G1: G1PeriodicGCTask::should_start_periodic_gc may use uninitialised value if os::loadavg is unsupported

Reviewed-by: ayang, tschatzl, iwalulya

! src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp

Changeset: 77a71c5b
Branch: lworld
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2025-09-25 12:08:39 +0000
URL:       https://git.openjdk.org/valhalla/commit/77a71c5b097500ea2cab0c84f87553e833692fd2

8366896: JFR: Use GarbageCollection.name in gc view

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini
! test/jdk/jdk/jfr/jcmd/TestJcmdView.java
! test/jdk/jdk/jfr/tool/TestView.java

Changeset: 26b5708c
Branch: lworld
Author:    Matthew Donovan <mdonovan at openjdk.org>
Date:      2025-09-25 12:15:09 +0000
URL:       https://git.openjdk.org/valhalla/commit/26b5708c47150023798a1546ba095c1b0b7807e1

8360882: Tests throw SkippedException when they should fail

Reviewed-by: mullan

! test/jdk/sun/security/pkcs11/PKCS11Test.java
! test/lib/jdk/test/lib/artifacts/ArtifactResolver.java
! test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java

Changeset: d1ea6ea2
Branch: lworld
Author:    Hamlin Li <mli at openjdk.org>
Date:      2025-09-25 12:42:18 +0000
URL:       https://git.openjdk.org/valhalla/commit/d1ea6ea22d49884bec53f89fad7029400fb1d7f2

8367103: RISC-V: store cpu features in a bitmap

Reviewed-by: fyang, luhenry

! src/hotspot/cpu/riscv/vm_version_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.hpp

Changeset: 2b451131
Branch: lworld
Author:    Boris Ulasevich <bulasevich at openjdk.org>
Date:      2025-09-25 13:35:36 +0000
URL:       https://git.openjdk.org/valhalla/commit/2b451131a57dc7080c4ccb77d6cb5a96ee24d891

8359378: aarch64: crash when using -XX:+UseFPUForSpilling

Reviewed-by: aph, rcastanedalo

! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp

Changeset: 043aeaf0
Branch: lworld
Author:    SendaoYan <syan at openjdk.org>
Date:      2025-09-25 14:30:47 +0000
URL:       https://git.openjdk.org/valhalla/commit/043aeaf02a50a7413e1956a99341d04ea3f9ac92

8368552: H3ErrorHandlingTest.testCloseControlStream intermittent timed out

Reviewed-by: dfuchs

! test/jdk/java/net/httpclient/http3/H3ErrorHandlingTest.java

Changeset: 569e7808
Branch: lworld
Author:    Artur Barashev <abarashev at openjdk.org>
Date:      2025-09-25 14:44:06 +0000
URL:       https://git.openjdk.org/valhalla/commit/569e78080b3c25c95d85e9e194626f95f86b9b10

8365820: Apply certificate scope constraints to algorithms in "signature_algorithms" extension when "signature_algorithms_cert" extension is not being sent

Reviewed-by: hchao

! src/java.base/share/classes/sun/security/ssl/CertSignAlgsExtension.java
! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
+ test/jdk/sun/security/ssl/SignatureScheme/DisableCertSignAlgsExtForClientTLS12.java
+ test/jdk/sun/security/ssl/SignatureScheme/DisableCertSignAlgsExtForClientTLS13.java
+ test/jdk/sun/security/ssl/SignatureScheme/DisableCertSignAlgsExtForServerTLS13.java
! test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS12.java
! test/jdk/sun/security/ssl/SignatureScheme/DisableSignatureSchemePerScopeTLS13.java

Changeset: 8ca1feaf
Branch: lworld
Author:    William Kemper <wkemper at openjdk.org>
Date:      2025-09-25 15:37:02 +0000
URL:       https://git.openjdk.org/valhalla/commit/8ca1feaf7e29c1370853b9b95c2ee7a62c6b84b7

8368499: GenShen: Do not collect age census during evac when adaptive tenuring is disabled

Reviewed-by: kdnilsen, ysr

! src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp
! src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.hpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp

Changeset: 74122198
Branch: lworld
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2025-09-25 16:47:22 +0000
URL:       https://git.openjdk.org/valhalla/commit/741221988e03d1710d3a73ab9c7764991f216fae

8368261: Serial: Use more precise nmethod scope during Full GC marking

Reviewed-by: stefank, fandreuzzi

! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/gc/serial/serialFullGC.cpp

Changeset: de1f5a3c
Branch: lworld
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2025-09-25 17:42:46 +0000
URL:       https://git.openjdk.org/valhalla/commit/de1f5a3c437ab4c6009f8be6f9f109ed36fb0b53

8368468: Split out everything but configure results from spec.gmk

Reviewed-by: erikj

! make/RunTestsPrebuilt.gmk
! make/RunTestsPrebuiltSpec.gmk
! make/autoconf/boot-jdk.m4
! make/autoconf/bootcycle-spec.gmk.template
! make/autoconf/build-performance.m4
! make/autoconf/buildjdk-spec.gmk.template
! make/autoconf/help.m4
! make/autoconf/hotspot.m4
! make/autoconf/jdk-options.m4
! make/autoconf/spec.gmk.template
+ make/common/CommonVars.gmk
! make/common/MakeBase.gmk

Changeset: 32ab0dbc
Branch: lworld
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2025-09-25 17:44:55 +0000
URL:       https://git.openjdk.org/valhalla/commit/32ab0dbc0b8170ecd168dbb7c3f1be69dfa5299b

8368674: Incremental builds keep rebuilding interim jmod

Reviewed-by: cstein, erikj

! make/common/Execute.gmk

Changeset: 5c596e2a
Branch: lworld
Author:    Valerie Peng <valeriep at openjdk.org>
Date:      2025-09-25 18:10:58 +0000
URL:       https://git.openjdk.org/valhalla/commit/5c596e2a9599e1e0eb9ec845f1b6e0e7b59f186a

8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException

Reviewed-by: mullan

! src/java.base/share/classes/javax/crypto/Cipher.java
! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java

Changeset: 80cb0ead
Branch: lworld
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2025-09-25 18:17:19 +0000
URL:       https://git.openjdk.org/valhalla/commit/80cb0ead502ae439660f2a3bbab42df4da39d9d6

8367133: DTLS: fragmentation of Finished message results in handshake failure

Reviewed-by: jnimeh

! src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
+ test/jdk/javax/net/ssl/DTLS/FragmentedFinished.java

Changeset: a48538dd
Branch: lworld
Author:    Johannes Graham <j3graham at gmail.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
Date:      2025-09-25 18:23:13 +0000
URL:       https://git.openjdk.org/valhalla/commit/a48538dd6379d606b75b849dd899413af76a068c

8367324: Avoid redundant parsing when formatting with DigitList

Reviewed-by: jlu, rgiulietti

! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/text/DigitList.java
! src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java
! test/jdk/java/text/Format/DecimalFormat/CloneTest.java
! test/micro/org/openjdk/bench/java/text/DefFormatterBench.java

Changeset: 3c9fd768
Branch: lworld
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2025-09-25 18:47:32 +0000
URL:       https://git.openjdk.org/valhalla/commit/3c9fd7688f4d73067db9b128c329ca7603a60578

8368514: TLS stateless session ticket decryption fails on some providers

Reviewed-by: valeriep, abarashev

! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java
= test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java
= test/jdk/sun/security/pkcs11/tls/fips/cert8.db
= test/jdk/sun/security/pkcs11/tls/fips/cert9.db
= test/jdk/sun/security/pkcs11/tls/fips/key3.db
= test/jdk/sun/security/pkcs11/tls/fips/key4.db
= test/jdk/sun/security/pkcs11/tls/fips/keystore
= test/jdk/sun/security/pkcs11/tls/fips/nss.cfg
= test/jdk/sun/security/pkcs11/tls/fips/pkcs11.txt
= test/jdk/sun/security/pkcs11/tls/fips/secmod.db

Changeset: 52e77784
Branch: lworld
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2025-09-25 19:59:52 +0000
URL:       https://git.openjdk.org/valhalla/commit/52e777845f0a09b4c285131f1eff02dfbffa0d1f

8367910: Reduce warnings about unsupported classes in AOT cache creation

Reviewed-by: dholmes, kvn, shade

! src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/classfile/verifier.cpp
! src/hotspot/share/oops/trainingData.cpp
! test/hotspot/jtreg/runtime/cds/appcds/aotCache/OldClassSupport.java
! test/hotspot/jtreg/runtime/cds/appcds/aotCache/VerifierFailOver.java
! test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java

Changeset: 648582ab
Branch: lworld
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2025-09-25 20:55:05 +0000
URL:       https://git.openjdk.org/valhalla/commit/648582ab781d98556906c274067f26f856fc0449

8368714: [BACKOUT] JDK-8368468 Split out everything but configure results from spec.gmk

Reviewed-by: ihse

! make/RunTestsPrebuilt.gmk
! make/RunTestsPrebuiltSpec.gmk
! make/autoconf/boot-jdk.m4
! make/autoconf/bootcycle-spec.gmk.template
! make/autoconf/build-performance.m4
! make/autoconf/buildjdk-spec.gmk.template
! make/autoconf/help.m4
! make/autoconf/hotspot.m4
! make/autoconf/jdk-options.m4
! make/autoconf/spec.gmk.template
- make/common/CommonVars.gmk
! make/common/MakeBase.gmk

Changeset: ca03080c
Branch: lworld
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2025-09-26 00:10:21 +0000
URL:       https://git.openjdk.org/valhalla/commit/ca03080c9f3857e88f71a5803f55877edbc7da18

8368030: Make package bundlers stateless

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java
+ src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebPackager.java
+ src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebSystemEnvironment.java
+ src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebSystemEnvironmentMixin.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxFromParams.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxLaunchersAsServices.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java
+ src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackager.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java
+ src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmPackager.java
+ src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmSystemEnvironment.java
+ src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmSystemEnvironmentMixin.java
+ src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxSystemEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgBundler.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
+ src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgSystemEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgPackager.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/Packager.java
- src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackagerBuilder.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/SystemEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ToolValidator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/Result.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExeBundler.java
+ src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExePackager.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromParams.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java
+ src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiPackager.java
+ src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinSystemEnvironment.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/ToolValidatorTest.java

Changeset: a6638121
Branch: lworld
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2025-09-26 06:14:28 +0000
URL:       https://git.openjdk.org/valhalla/commit/a6638121211afd688a9e25b5cbadf2f1441b1e65

8368124: Show useful thread names in ASAN reports

Reviewed-by: dholmes, mbaesken

! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/linux/os_linux.hpp
! src/hotspot/share/utilities/stringUtils.cpp
! src/hotspot/share/utilities/stringUtils.hpp
! test/hotspot/gtest/runtime/test_os_linux.cpp

Changeset: 87307802
Branch: lworld
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2025-09-26 07:27:51 +0000
URL:       https://git.openjdk.org/valhalla/commit/873078028b7cac1df94cd5a09e403c8537f14ba9

8368006: Parallel: Skip full regions in dense prefix during Full GC

Reviewed-by: gli, fandreuzzi

! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp

Changeset: b90799c0
Branch: lworld
Author:    Arno Zeller <azeller at openjdk.org>
Committer: Matthias Baesken <mbaesken at openjdk.org>
Date:      2025-09-26 07:47:26 +0000
URL:       https://git.openjdk.org/valhalla/commit/b90799c0e92468b341235989f731bb93e2741a77

8368616: runtime/cds/appcds/aotCache/JavaAgent.java#dynamic fails on non CDS platforms/builds after JDK-8362561

Reviewed-by: mbaesken, shade, iklam

! test/hotspot/jtreg/runtime/cds/appcds/aotCache/JavaAgent.java

Changeset: a80ba626
Branch: lworld
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2025-09-26 07:56:40 +0000
URL:       https://git.openjdk.org/valhalla/commit/a80ba6260effdca7a7703c6903f273401b861793

8357691: File blocked.certs contains bad content when boot jdk 25 is used, sun/security/lib/CheckBlockedCerts.java failing

Reviewed-by: erikj, iklam

! make/ToolsJdk.gmk

Changeset: 7bfdb012
Branch: lworld
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2025-09-26 09:00:59 +0000
URL:       https://git.openjdk.org/valhalla/commit/7bfdb0120752d01da96c19e8037a6e909847d63c

8368565: Adjust comment regarding dependency of libjvm.so to librt

Reviewed-by: dholmes

! make/autoconf/libraries.m4

Changeset: f0e1078c
Branch: lworld
Author:    Joachim Kern <jkern at openjdk.org>
Date:      2025-09-26 12:14:58 +0000
URL:       https://git.openjdk.org/valhalla/commit/f0e1078c7175b3f930502a6079feff86aa53b669

8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686)

Reviewed-by: erikj, stuefe, mbaesken

! make/autoconf/flags-ldflags.m4
! make/autoconf/jdk-options.m4
! src/hotspot/share/oops/compressedKlass.cpp

Changeset: bdb7d25a
Branch: lworld
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2025-09-26 13:59:39 +0000
URL:       https://git.openjdk.org/valhalla/commit/bdb7d25ac11ca60a357b371c75544b346e523940

8358723: jpackage signing issues: the main launcher doesn't have entitlements

Reviewed-by: almatvee

! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/PListReader.java
! test/jdk/tools/jpackage/TEST.properties
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSignVerify.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/PListReaderTest.java
! test/jdk/tools/jpackage/macosx/MacFileAssociationsTest.java

Changeset: 2360542e
Branch: lworld
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2025-09-26 14:19:12 +0000
URL:       https://git.openjdk.org/valhalla/commit/2360542e89067e5c5d5a7bf403c18c9f371efd9a

8368683: [process] Increase jtreg debug output maxOutputSize for TreeTest

Reviewed-by: msheppar

+ test/jdk/java/lang/ProcessHandle/TEST.properties

Changeset: 501b2b3e
Branch: lworld
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Date:      2025-09-26 14:28:35 +0000
URL:       https://git.openjdk.org/valhalla/commit/501b2b3ebc50d9bb1c32267ef8e56561ea1e71eb

8368615: VSCode IDE: Oracle Java extension routinely runs out of memory

Reviewed-by: erikj

! make/ide/vscode/hotspot/template-workspace.jsonc

Changeset: 25abdd85
Branch: lworld
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2025-09-26 14:48:26 +0000
URL:       https://git.openjdk.org/valhalla/commit/25abdd85c41f7aef41915cabd8596c0ce573acd6

8368752: Serial: Remove unused arg of DefNewGeneration::gc_epilogue

Reviewed-by: tschatzl, fandreuzzi

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/serialHeap.cpp

Changeset: aa6ff450
Branch: lworld
Author:    Ashutosh Mehra <asmehra at openjdk.org>
Date:      2025-09-26 14:56:03 +0000
URL:       https://git.openjdk.org/valhalla/commit/aa6ff45052516f5383fb7e62cfb469cbade0c42e

8368693: Duplicate methods in vmClasses

Reviewed-by: liach, coleenp, dholmes

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/vmClasses.cpp
! src/hotspot/share/classfile/vmClasses.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/objArrayKlass.cpp

Changeset: bdf6853c
Branch: lworld
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2025-09-26 16:50:05 +0000
URL:       https://git.openjdk.org/valhalla/commit/bdf6853cfdd24176bdddb59b6d7bb85036b94c57

8368328: CompactNumberFormat.clone does not produce independent instances

Reviewed-by: rgiulietti, jlu

! src/java.base/share/classes/java/text/CompactNumberFormat.java
+ test/jdk/java/text/Format/CompactNumberFormat/TestClone.java

Changeset: 556dfdda
Branch: lworld
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2025-09-26 19:34:04 +0000
URL:       https://git.openjdk.org/valhalla/commit/556dfddac82f69b8a3d3730d05fcd00e49b84f2e

8308027: GetThreadListStackTraces/OneGetThreadListStackTraces.java should be skipped when thread factory is used

Reviewed-by: dholmes, sspitsyn

! test/hotspot/jtreg/ProblemList-Virtual.txt
! test/hotspot/jtreg/serviceability/jvmti/GetThreadListStackTraces/OneGetThreadListStackTraces.java

Changeset: 62cc3472
Branch: lworld
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2025-09-26 19:36:00 +0000
URL:       https://git.openjdk.org/valhalla/commit/62cc347242ddbc8b51f023c288d78785b128e421

8368699: nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp destroys jvmti monitor when VM is dead

Reviewed-by: sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp

Changeset: c6cecc58
Branch: lworld
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Alex Menkov <amenkov at openjdk.org>
Date:      2025-09-26 19:51:04 +0000
URL:       https://git.openjdk.org/valhalla/commit/c6cecc581f331dc61af0df2dfd5d7e0d523f6b61

8283198: Remove src/jdk.hotspot.agent/test

Reviewed-by: amenkov, ayang, sspitsyn

- src/jdk.hotspot.agent/test/libproc/LibprocClient.java
- src/jdk.hotspot.agent/test/libproc/LibprocTest.java
- src/jdk.hotspot.agent/test/libproc/Makefile
- src/jdk.hotspot.agent/test/libproc/README
- src/jdk.hotspot.agent/test/libproc/libproctest.sh
- src/jdk.hotspot.agent/test/libproc/libproctest64.sh

Changeset: 12c0f29b
Branch: lworld
Author:    Justin Lu <jlu at openjdk.org>
Date:      2025-09-26 20:12:48 +0000
URL:       https://git.openjdk.org/valhalla/commit/12c0f29b97f0ccd03dee6850a3a9a7117124016e

8368498: Use JUnit instead of TestNG for jdk_text tests

Reviewed-by: naoto

! test/jdk/java/text/Collator/RuleBasedCollatorTest.java
! test/jdk/java/text/Format/CompactNumberFormat/CompactFormatAndParseHelper.java
! test/jdk/java/text/Format/CompactNumberFormat/TestCNFRounding.java
! test/jdk/java/text/Format/CompactNumberFormat/TestCompactNumber.java
! test/jdk/java/text/Format/CompactNumberFormat/TestCompactPatternsValidity.java
! test/jdk/java/text/Format/CompactNumberFormat/TestEquality.java
! test/jdk/java/text/Format/CompactNumberFormat/TestFormatToCharacterIterator.java
! test/jdk/java/text/Format/CompactNumberFormat/TestMutatingInstance.java
! test/jdk/java/text/Format/CompactNumberFormat/TestParseBigDecimal.java
! test/jdk/java/text/Format/CompactNumberFormat/TestPlurals.java
! test/jdk/java/text/Format/CompactNumberFormat/TestSpecialValues.java
! test/jdk/java/text/Format/CompactNumberFormat/TestUExtensionOverride.java
! test/jdk/java/text/Format/CompactNumberFormat/serialization/TestDeserializeCNF.java
! test/jdk/java/text/Format/CompactNumberFormat/serialization/TestSerialization.java
! test/jdk/java/text/Format/DateFormat/Bug8193444.java
! test/jdk/java/text/Format/DateFormat/CaseInsensitiveParseTest.java
! test/jdk/java/text/Format/DateFormat/LocaleDateFormats.java
! test/jdk/java/text/Format/DateFormat/SimpleDateFormatPatternTest.java
! test/jdk/java/text/Format/DecimalFormat/SetGroupingSizeTest.java
! test/jdk/java/text/Format/NumberFormat/DFSMinusPerCentMill.java
! test/jdk/java/text/Normalizer/SquareEraCharacterTest.java

Changeset: cedc0117
Branch: lworld
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2025-09-26 20:49:36 +0000
URL:       https://git.openjdk.org/valhalla/commit/cedc0117ac36243cc240e8ab6adb3c78af4055fc

8365057: Add support for java.util.concurrent lock information to Thread.dump_to_file

Co-authored-by: Alex Menkov <amenkov at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: sspitsyn, alanb

! src/hotspot/share/services/threadService.cpp
! src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java
! src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java
! src/jdk.management/share/classes/com/sun/management/doc-files/threadDump.schema.json
! test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java
! test/lib/jdk/test/lib/threaddump/ThreadDump.java

Changeset: 37f0e74d
Branch: lworld
Author:    Mohamed Issa <missa at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2025-09-26 21:10:30 +0000
URL:       https://git.openjdk.org/valhalla/commit/37f0e74d328d909810b54f7889cca991426d7488

8364305: Support AVX10 saturating floating point conversion instructions

Reviewed-by: sviswanathan, sparasa, jbhateja

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_64.ad
+ test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
! test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java
! test/hotspot/jtreg/compiler/vectorapi/VectorFPtoIntCastTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/ArrayTypeConvertTest.java

Changeset: 5b1ebbb2
Branch: lworld
Author:    Archie Cobbs <acobbs at openjdk.org>
Date:      2025-09-27 02:34:27 +0000
URL:       https://git.openjdk.org/valhalla/commit/5b1ebbb2713e54511cb695d1d6f7f6b7f827b2a7

8366561: Improve documentation for how the -Xlint flag works

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
! src/jdk.compiler/share/classes/module-info.java
! src/jdk.compiler/share/man/javac.md

Changeset: 9093d3a0
Branch: lworld
Author:    SendaoYan <syan at openjdk.org>
Date:      2025-09-27 02:37:39 +0000
URL:       https://git.openjdk.org/valhalla/commit/9093d3a04cd2b66425cefb44de2990cb5362a29f

8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine

Reviewed-by: lmesnik

! test/hotspot/jtreg/vmTestbase/gc/gctests/AllocateWithoutOomTest/AllocateWithoutOomTest.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_NonbranchyTree/TestDescription.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_NonbranchyTree_ArrayOf/TestDescription.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_NonbranchyTree_TwoFields/TestDescription.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_Strings/TestDescription.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_Strings_InternedStrings/TestDescription.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_Strings_TwoFields/TestDescription.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Humongous_NonbranchyTree/TestDescription.java
! test/hotspot/jtreg/vmTestbase/vm/gc/compact/Humongous_Strings/TestDescription.java

Changeset: af8fb20a
Branch: lworld
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2025-09-27 04:07:29 +0000
URL:       https://git.openjdk.org/valhalla/commit/af8fb20ac0325a231ee14bd72e9764e02ca07681

8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits

Reviewed-by: wkemper

! src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp

Changeset: 320230db
Branch: lworld
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-09-28 04:49:58 +0000
URL:       https://git.openjdk.org/valhalla/commit/320230db5f9ca95f23218704cb2e69521e03852f

8367795: HeadlessMalfunctionTest may fail due to timeout

Reviewed-by: prr

! test/jdk/java/awt/Headless/HeadlessMalfunctionTest.java

Changeset: e19ec6f7
Branch: lworld
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2025-09-29 05:19:56 +0000
URL:       https://git.openjdk.org/valhalla/commit/e19ec6f785e889d254b15c5ef2e801152c59c948

8368754: runtime/cds/appcds/SignedJar.java log regex is too strict

Reviewed-by: iklam, dholmes

! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java

Changeset: d53190ac
Branch: lworld
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2025-09-29 05:36:18 +0000
URL:       https://git.openjdk.org/valhalla/commit/d53190ac4485e535f0a603036ecf47d4ff6e4178

8366582: Test jdk/jshell/ToolSimpleTest.java failed: provider not found

Reviewed-by: asotona

! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
! test/langtools/ProblemList.txt

Changeset: 75269fdb
Branch: lworld
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2025-09-29 07:26:43 +0000
URL:       https://git.openjdk.org/valhalla/commit/75269fdb49aeb9d37acbbc1502c446a822fd30e3

8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking

Reviewed-by: fandreuzzi, tschatzl, iwalulya

! src/hotspot/share/gc/serial/serialFullGC.cpp

Changeset: 08b677bb
Branch: lworld
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2025-09-29 10:05:45 +0000
URL:       https://git.openjdk.org/valhalla/commit/08b677bba4b1e23feb55b104d86fe0eef543d59c

8071277: G1: Merge commits and uncommits of contiguous memory

Reviewed-by: iwalulya, ayang

! src/hotspot/share/gc/g1/g1NUMA.cpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.hpp

Changeset: 61659214
Branch: lworld
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2025-09-29 10:28:45 +0000
URL:       https://git.openjdk.org/valhalla/commit/616592144939d80cae661bd4db26c976a035d543

7156751: [macosx] Problem with printing

Reviewed-by: prr, serb

! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m
! test/jdk/java/awt/print/PrinterJob/PrintTextTest.java

Changeset: fdbba049
Branch: lworld
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2025-09-29 10:39:25 +0000
URL:       https://git.openjdk.org/valhalla/commit/fdbba049a2491c591fc1a866e4707bf9aac50f17

8368775: Remove outdated comment in OutlineTextRenderer

Reviewed-by: prr, dnguyen, serb

! src/java.desktop/share/classes/sun/java2d/pipe/OutlineTextRenderer.java

Changeset: 9d9c0e06
Branch: lworld
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2025-09-29 13:55:49 +0000
URL:       https://git.openjdk.org/valhalla/commit/9d9c0e06700116288233e3435051a1496cb64b72

8368793: java/lang/StringBuilder/RacingSBThreads.java timed out in Xcomp subtest

Reviewed-by: iris, alanb, syan

! test/jdk/java/lang/StringBuilder/RacingSBThreads.java

Changeset: 63688d89
Branch: lworld
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2025-09-29 14:48:04 +0000
URL:       https://git.openjdk.org/valhalla/commit/63688d894e2157bb091be3aa62946f7e5830f384

8368822: Refactor Float16.valueOf(double)

Reviewed-by: rgiulietti

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java

Changeset: 9d71af10
Branch: lworld
Author:    Hamlin Li <mli at openjdk.org>
Date:      2025-09-29 16:04:54 +0000
URL:       https://git.openjdk.org/valhalla/commit/9d71af108ea2cc3682607527246d60a19fd820ba

8367253: RISC-V: refactor dependent cpu extensions

Reviewed-by: fyang, luhenry

! src/hotspot/cpu/riscv/vm_version_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.hpp

Changeset: aabf699d
Branch: lworld
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2025-09-29 17:43:35 +0000
URL:       https://git.openjdk.org/valhalla/commit/aabf699dd0f066efe6654db24b520068b256d855

8355339: Test java/io/File/GetCanonicalPath.java failed: The specified network name is no longer available

Reviewed-by: alanb

! src/java.base/windows/native/libjava/canonicalize_md.c

Changeset: 3d97e17a
Branch: lworld
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2025-09-29 17:46:17 +0000
URL:       https://git.openjdk.org/valhalla/commit/3d97e17a31c267161c2be87b551cdb118062ff57

8367318: Test vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java timed out after passing

Reviewed-by: amenkov, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/EventHandler.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType1.java

Changeset: 6c8e384c
Branch: lworld
Author:    Chen Liang <liach at openjdk.org>
Date:      2025-09-29 18:22:24 +0000
URL:       https://git.openjdk.org/valhalla/commit/6c8e384c63ac199a5f226b017ef5cd133130d1ac

8356022: Migrate descriptor parsing from generics to BytecodeDescriptor

Reviewed-by: rriggs

! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java
! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java
+ test/jdk/sun/invoke/util/BytecodeDescriptorTest.java

Changeset: 59e76af4
Branch: lworld
Author:    Hannes Greule <hgreule at openjdk.org>
Date:      2025-09-29 18:40:43 +0000
URL:       https://git.openjdk.org/valhalla/commit/59e76af47b23f582bbc21465a1871205d2499f28

8367967: C2: "fatal error: Not monotonic" with Mod nodes

Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
Reviewed-by: bmaillard, vlivanov, chagedorn, shade

! src/hotspot/share/opto/divnode.cpp
+ test/hotspot/jtreg/compiler/ccp/TestModValueMonotonic.java

Changeset: 2f29b3f2
Branch: lworld
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2025-09-29 19:24:28 +0000
URL:       https://git.openjdk.org/valhalla/commit/2f29b3f24a31bbe58d9c3433d46b69c16002694b

8366884: NMT fails with MallocLimit: reached category "mtCompiler" limit

Reviewed-by: phubner, jsjolen

! test/hotspot/jtreg/runtime/NMT/MallocLimitTest.java

Changeset: c57003c9
Branch: lworld
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2025-09-29 21:39:42 +0000
URL:       https://git.openjdk.org/valhalla/commit/c57003c9b837adb8671a0db636d9c576bd6a89b0

8368890: open/test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java fails randomly

Reviewed-by: almatvee

! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java

Changeset: 538a722c
Branch: lworld
Author:    Fei Yang <fyang at openjdk.org>
Date:      2025-09-30 01:40:35 +0000
URL:       https://git.openjdk.org/valhalla/commit/538a722c2e9123cc575355879ff230444cf2dadc

8368732: RISC-V: Detect support for misaligned vector access via hwprobe

Reviewed-by: mli, dzhang

! src/hotspot/cpu/riscv/vm_version_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.hpp
! src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp
! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp

Changeset: 89af6e13
Branch: lworld
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-09-30 03:10:41 +0000
URL:       https://git.openjdk.org/valhalla/commit/89af6e13f2354d6e32872791d157144cd478a88f

8362204: test/jdk/sun/awt/font/TestDevTransform.java fails on Ubuntu 24.04

Reviewed-by: avu, prr

! test/jdk/sun/awt/font/TestDevTransform.java

Changeset: 2746c1a5
Branch: lworld
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2025-09-30 05:09:33 +0000
URL:       https://git.openjdk.org/valhalla/commit/2746c1a555891564963299182b3b0293eaefc901

8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes

Reviewed-by: jsikstro, sgehwolf, stefank, stuefe, aph

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/aix/os_aix.hpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/bsd/os_bsd.hpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/linux/os_linux.hpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/os_windows.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/shared/gcInitLogger.cpp
! src/hotspot/share/gc/z/zLargePages.cpp
! src/hotspot/share/jfr/jni/jfrJniMethod.cpp
! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/services/heapDumper.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp

Changeset: c0a4c0ba
Branch: lworld
Author:    Hamlin Li <mli at openjdk.org>
Date:      2025-09-30 08:11:02 +0000
URL:       https://git.openjdk.org/valhalla/commit/c0a4c0ba97284d55cfdf857eb5d41fd6189e6c2d

8367981: Update CompactHashtable for readability

Reviewed-by: iklam, matsaave

! src/hotspot/share/classfile/compactHashtable.cpp
! src/hotspot/share/classfile/compactHashtable.hpp

Changeset: 586167cf
Branch: lworld
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2025-09-30 08:49:08 +0000
URL:       https://git.openjdk.org/valhalla/commit/586167cff5aaead0949c509f48bc5080834cc362

8363932: G1: Better distribute KlassCleaningTask

Reviewed-by: ayang, coleenp

! src/hotspot/share/classfile/classLoaderData.hpp
! src/hotspot/share/classfile/classLoaderDataGraph.cpp
! src/hotspot/share/classfile/classLoaderDataGraph.hpp
! src/hotspot/share/gc/shared/parallelCleaning.cpp
! src/hotspot/share/gc/shared/parallelCleaning.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp

Changeset: aea71cca
Branch: lworld
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2025-09-30 08:54:53 +0000
URL:       https://git.openjdk.org/valhalla/commit/aea71ccab7d21ae72564a07f74199eac14c7a958

8342730: Get rid of SummaryDiff in VMATree

Reviewed-by: jsjolen, phubner

! src/hotspot/share/nmt/memoryFileTracker.cpp
! src/hotspot/share/nmt/regionsTree.cpp
! src/hotspot/share/nmt/regionsTree.hpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/nmt/vmatree.cpp
! src/hotspot/share/nmt/vmatree.hpp
! test/hotspot/gtest/nmt/test_regions_tree.cpp
! test/hotspot/gtest/nmt/test_vmatree.cpp
! test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp

Changeset: b19e8721
Branch: lworld
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2025-09-30 10:35:23 +0000
URL:       https://git.openjdk.org/valhalla/commit/b19e872192106f47c5d9b425230cc2bfe3e4786c

8362573: Incorrect weight of the first ObjectAllocationSample JFR event (regression)

Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.hpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
! src/hotspot/share/jfr/support/jfrAllocationTracer.cpp
! src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp
! src/hotspot/share/jfr/support/jfrObjectAllocationSample.hpp
+ test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventInitialWeight.java

Changeset: ba0a6eed
Branch: lworld
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
Date:      2025-09-30 10:41:13 +0000
URL:       https://git.openjdk.org/valhalla/commit/ba0a6eed1a6a22bd4c1d159592b62e054afa401a

8368357: Some source files have initial blank lines

Reviewed-by: stefank, ayang, serb, jwaters, jpai

! src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/services/threadIdTable.cpp
! src/hotspot/share/services/threadIdTable.hpp
! src/java.base/share/classes/sun/util/locale/UnicodeLocaleExtension.java
! src/java.desktop/share/classes/java/awt/image/LookupOp.java
! src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java

Changeset: 64c46d8e
Branch: lworld
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2025-09-30 11:32:44 +0000
URL:       https://git.openjdk.org/valhalla/commit/64c46d8efc27911b8667c3974275c075cf79a311

8367953: JFR sampler threads does not appear in thread dump

Reviewed-by: mgronlun

! src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp

Changeset: 8606d3f8
Branch: lworld
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2025-09-30 11:54:37 +0000
URL:       https://git.openjdk.org/valhalla/commit/8606d3f8405b73878a1319ba3574ef69349aa2a1

8365060: Historical data for JDK 8 should include the jdk.net package

Reviewed-by: shade, liach

! src/jdk.compiler/share/data/symbols/include.list
! src/jdk.compiler/share/data/symbols/java.base-8.sym.txt
! src/jdk.compiler/share/data/symbols/java.base-9.sym.txt
! src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt
! src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt
! src/jdk.compiler/share/data/symbols/java.xml.bind-9.sym.txt
! src/jdk.compiler/share/data/symbols/jdk.management-8.sym.txt
! src/jdk.compiler/share/data/symbols/jdk.management-9.sym.txt
+ src/jdk.compiler/share/data/symbols/jdk.net-8.sym.txt
! src/jdk.compiler/share/data/symbols/jdk.net-9.sym.txt
! src/jdk.compiler/share/data/symbols/symbols
+ test/langtools/tools/javac/platform/CompilationTest.java
! test/langtools/tools/javac/sym/ElementStructureTest.java

Changeset: 444007fc
Branch: lworld
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2025-09-30 12:27:22 +0000
URL:       https://git.openjdk.org/valhalla/commit/444007fc234aeff75025831c2d1b5538c87fa8f1

8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure

Reviewed-by: fandreuzzi, tschatzl

! src/hotspot/share/gc/parallel/psParallelCompact.cpp

Changeset: 07ea907e
Branch: lworld
Author:    Anass Baya <abaya at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2025-09-30 13:57:07 +0000
URL:       https://git.openjdk.org/valhalla/commit/07ea907e4fc8aa8fda01d8fe64c599f9d944eef9

8361606: ConsumeNextMnemonicKeyTypedTest.java fails on Windows: character typed with VK_A: a
8321303: Intermittent open/test/jdk/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java failure on Linux

Reviewed-by: dnguyen, honkar, aivanov

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java
! test/jdk/ProblemList.txt
! test/jdk/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java

Changeset: 8cc54ec6
Branch: lworld
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2025-09-30 14:14:53 +0000
URL:       https://git.openjdk.org/valhalla/commit/8cc54ec6b86fc5b80af02939363eccd8e3e899e7

8368563: JFR: Improve jfr query help text

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryPrinter.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Query.java

Changeset: 6b4b1020
Branch: lworld
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2025-09-30 14:24:05 +0000
URL:       https://git.openjdk.org/valhalla/commit/6b4b10200ed10365e1ae1ca02ade773ce5a108c3

8368809: JFR: Remove events from testSettingConfiguration in TestActiveSettingEvent

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java

Changeset: 07ecc93d
Branch: lworld
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2025-09-30 15:10:30 +0000
URL:       https://git.openjdk.org/valhalla/commit/07ecc93dbd0b74e2362d369e22b5141289eb1f76

8367692: RISC-V: Align post call nop

Reviewed-by: fyang, fjiang, mli

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/nativeInst_riscv.cpp
! src/hotspot/cpu/riscv/nativeInst_riscv.hpp
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp

Changeset: fe9dbcc4
Branch: lworld
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2025-09-30 16:15:21 +0000
URL:       https://git.openjdk.org/valhalla/commit/fe9dbcc496671a256c61ac52df5580569dbafb0a

8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope

Reviewed-by: ayang, shade, wkemper

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp

Changeset: 9b02896b
Branch: lworld
Author:    Mohamed Issa <missa at openjdk.org>
Committer: Srinivas Vamsi Parasa <sparasa at openjdk.org>
Date:      2025-09-30 21:08:06 +0000
URL:       https://git.openjdk.org/valhalla/commit/9b02896b4725ef932a23be11ff76ce04bda0d652

8360558: Use hex literals instead of decimal literals in math intrinsic constants

Reviewed-by: mhaessig, sparasa, jbhateja

! src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp

Changeset: 0366d882
Branch: lworld
Author:    SendaoYan <syan at openjdk.org>
Date:      2025-10-01 00:52:30 +0000
URL:       https://git.openjdk.org/valhalla/commit/0366d8823bc844225ca24964e352ce0a57d01683

8354894: java/lang/Thread/virtual/Starvation.java timeout on server with high CPUs

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: jpai

! test/jdk/java/lang/Thread/virtual/Starvation.java

Changeset: 17d8fa8e
Branch: lworld
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2025-10-01 01:40:06 +0000
URL:       https://git.openjdk.org/valhalla/commit/17d8fa8e421db67027c9e7d2ddd634ff0b897cb6

8367026: Reorder the timeout failure handler commands to have jstack run before the rest

Reviewed-by: erikj, lmesnik

! test/failure_handler/src/share/conf/common.properties

Changeset: 8c3ca024
Branch: lworld
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2025-10-01 03:58:49 +0000
URL:       https://git.openjdk.org/valhalla/commit/8c3ca024c770d3cf3b35234e967e5f0f0d610388

8368817: Convert JDK_Version::to_string to use stringStream instead of jio_snprintf-chain

Reviewed-by: fandreuzzi, jsjolen

! src/hotspot/share/runtime/java.cpp

Changeset: 394eb80a
Branch: lworld
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2025-10-01 06:12:05 +0000
URL:       https://git.openjdk.org/valhalla/commit/394eb80a48fa73238cf897087b99c3da5a616566

8368957: Remove metaprogramming/logical.hpp in favor of C++17 facilities

Reviewed-by: mchevalier, iwalulya

! src/hotspot/share/gc/shared/workerUtils.hpp
- src/hotspot/share/metaprogramming/logical.hpp
- test/hotspot/gtest/metaprogramming/test_logical.cpp

Changeset: 1188ca55
Branch: lworld
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2025-10-01 08:07:59 +0000
URL:       https://git.openjdk.org/valhalla/commit/1188ca55f525554d2bb10691b368c818d98e5ea7

8368954: G1: Document why G1 uses TLS storage for the current card table reference

Reviewed-by: ayang, rcastanedalo, iwalulya

! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp

Changeset: 6c2d3834
Branch: lworld
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2025-10-01 08:08:19 +0000
URL:       https://git.openjdk.org/valhalla/commit/6c2d383492d194eb8a604a58a0336c371cbb1ea5

8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value

Co-authored-by: Albert Mingkun Yang <ayang at openjdk.org>
Reviewed-by: ayang, iwalulya

! src/hotspot/share/gc/shared/cardTable.hpp

Changeset: f49849a5
Branch: lworld
Author:    Hamlin Li <mli at openjdk.org>
Date:      2025-10-01 08:22:02 +0000
URL:       https://git.openjdk.org/valhalla/commit/f49849a5ed4e9383e39e69ce76bb8ea74fb443f9

8368893: RISC-V: crash after JDK-8352673 on fastdebug version

Reviewed-by: fyang, dzhang

! src/hotspot/cpu/riscv/vm_version_riscv.cpp
! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp

Changeset: 84e5d63b
Branch: lworld
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2025-10-01 09:01:19 +0000
URL:       https://git.openjdk.org/valhalla/commit/84e5d63b9fa8af0b35e1d682a81900cb157697fe

8368885: NMT CommandLine tests can check for error better

Reviewed-by: phubner, azafari, shade

! test/hotspot/jtreg/runtime/NMT/CommandLineDetail.java
! test/hotspot/jtreg/runtime/NMT/CommandLineSummary.java

Changeset: 5a2700f2
Branch: lworld
Author:    Richard Reingruber <rrich at openjdk.org>
Date:      2025-10-01 09:26:43 +0000
URL:       https://git.openjdk.org/valhalla/commit/5a2700f231d72e2241703c1d17b308f031e8566c

8368861: [TEST] compiler/floatingpoint/ScalarFPtoIntCastTest.java expects x86 IR on non-x86 platforms

Reviewed-by: sviswanathan, mdoerr

! test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java

Changeset: 3607e998
Branch: lworld
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2025-10-01 11:16:44 +0000
URL:       https://git.openjdk.org/valhalla/commit/3607e9986f1582ebdae1b6ad2a13c1a9c239e0d6

8367279: Test tools/javac/tree/TreePosTest.java timed out

Reviewed-by: asotona

! test/langtools/tools/javac/tree/TreePosTest.java

Changeset: c69456e8
Branch: lworld
Author:    Justin King <jcking at openjdk.org>
Date:      2025-10-01 13:23:13 +0000
URL:       https://git.openjdk.org/valhalla/commit/c69456e87aeb8653ce23bc7f579c254511bbf2d1

8368962: hotspot/cpu/aarch64/bytecodes_aarch64.{hpp,cpp} is unused

Reviewed-by: aph, mhaessig

- src/hotspot/cpu/aarch64/bytecodes_aarch64.cpp
- src/hotspot/cpu/aarch64/bytecodes_aarch64.hpp

Changeset: 182fbc2b
Branch: lworld
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Date:      2025-10-01 13:55:18 +0000
URL:       https://git.openjdk.org/valhalla/commit/182fbc2b836d27410ccd0da512acb17bac9363c1

8368675: IGV: nodes are wrongly marked as changed in the difference view

Reviewed-by: mchevalier, mhaessig, dfenacci, tholenstein

! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputNode.java
! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/Parser.java
! src/utils/IdealGraphVisualizer/Difference/src/main/java/com/sun/hotspot/igv/difference/Difference.java
! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Figure.java
! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/NodeQuickSearch.java

Changeset: c54dcefb
Branch: lworld
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2025-10-01 14:59:14 +0000
URL:       https://git.openjdk.org/valhalla/commit/c54dcefbfd2eb44a569767740dc053813c4f6fe1

8368938: Remove ObjectWaiter::badObjectWaiterPtr

Reviewed-by: shade, ayang

! src/hotspot/share/runtime/objectMonitor.hpp

Changeset: e44ef0c3
Branch: lworld
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2025-10-01 16:05:31 +0000
URL:       https://git.openjdk.org/valhalla/commit/e44ef0c32b3c2fcd0a6293838d9185b6d0719219

8367704: Fix minor documentation issues in java.time.**

Reviewed-by: naoto, rriggs

! src/java.base/share/classes/java/time/Duration.java
! src/java.base/share/classes/java/time/Instant.java
! src/java.base/share/classes/java/time/Period.java
! src/java.base/share/classes/java/time/ZoneOffset.java
! src/java.base/share/classes/java/time/ZonedDateTime.java
! src/java.base/share/classes/java/time/package-info.java
! src/java.base/share/classes/java/time/temporal/ChronoField.java
! src/java.base/share/classes/java/time/temporal/ValueRange.java

Changeset: 6b72b778
Branch: lworld
Author:    Justin Lu <jlu at openjdk.org>
Date:      2025-10-01 17:57:43 +0000
URL:       https://git.openjdk.org/valhalla/commit/6b72b778039afce0e25986114d15dd29a6786529

6177299: [Fmt-Nu] NumberFormat.getPercentInstance() does not work correctly

Reviewed-by: naoto

! src/java.base/share/classes/java/text/DecimalFormat.java
! test/jdk/java/text/Format/NumberFormat/NumberRegression.java

Changeset: ef724f40
Branch: lworld
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2025-10-01 19:56:05 +0000
URL:       https://git.openjdk.org/valhalla/commit/ef724f40c1f3cdddd215d50edf512bb06825085d

8368985: Small Float16 refactorings

Reviewed-by: rgiulietti, jbhateja

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java
! test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java

Changeset: db6320df
Branch: lworld
Author:    Johannes Graham <jgraham at openjdk.org>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
Date:      2025-10-01 20:00:43 +0000
URL:       https://git.openjdk.org/valhalla/commit/db6320df980ebe7cf2a1c727970cc937ab549b97

8368968: FloatingDecimal: Clean up unused code

Reviewed-by: rgiulietti

! src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java

Changeset: 4df41d2a
Branch: lworld
Author:    Igor Veresov <iveresov at openjdk.org>
Date:      2025-10-01 23:15:13 +0000
URL:       https://git.openjdk.org/valhalla/commit/4df41d2a751e2942c2188ed01313d78e681835bc

8368698: runtime/cds/appcds/aotCache/OldClassSupport.java assert(can_add()) failed: Cannot add TrainingData objects

Reviewed-by: heidinga, iklam

! src/hotspot/share/oops/trainingData.cpp

Changeset: fa3af820
Branch: lworld
Author:    Boris Ulasevich <bulasevich at openjdk.org>
Date:      2025-10-01 23:49:03 +0000
URL:       https://git.openjdk.org/valhalla/commit/fa3af820ad310704e8d25cf496f676e09d60797d

8338197: [ubsan] ad_x86.hpp:6417:11: runtime error: shift exponent 100 is too large for 32-bit type 'unsigned int'

Reviewed-by: kvn, dlong

! src/hotspot/share/adlc/output_h.cpp

Changeset: 5251405c
Branch: lworld
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2025-10-02 06:52:59 +0000
URL:       https://git.openjdk.org/valhalla/commit/5251405ce9ab1cbd84b798a538cb3865ea4675e9

8368848: JShell's code completion not always working for multi-snippet inputs

Reviewed-by: asotona

! src/jdk.jshell/share/classes/jdk/jshell/OuterWrapMap.java
! src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java
! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
! test/langtools/jdk/jshell/CompletionSuggestionTest.java

Changeset: 412ec882
Branch: lworld
Author:    David Simms <dsimms at openjdk.org>
Date:      2025-10-23 08:14:35 +0000
URL:       https://git.openjdk.org/valhalla/commit/412ec882767d3ee1792d1e0f98da54ff800c60ce

Merge jdk

Merge jdk-26+18

! make/autoconf/jdk-options.m4
! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/c1/c1_CodeStubs.hpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classLoaderData.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/verifier.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/serial/serialFullGC.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/flatArrayKlass.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/objArrayKlass.cpp
! src/hotspot/share/oops/refArrayKlass.cpp
! src/hotspot/share/opto/divnode.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/services/heapDumper.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/stringUtils.cpp
! src/hotspot/share/utilities/stringUtils.hpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/time/Duration.java
! src/java.base/share/classes/java/time/Instant.java
! src/java.base/share/classes/java/time/Period.java
! src/java.base/share/classes/java/time/ZonedDateTime.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
! src/jdk.compiler/share/classes/module-info.java
! src/jdk.compiler/share/man/javac.md
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
! test/jdk/ProblemList.txt
! test/langtools/ProblemList.txt
! make/autoconf/jdk-options.m4
! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/c1/c1_CodeStubs.hpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classLoaderData.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/verifier.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/serial/serialFullGC.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/constantPool.cpp
+ src/hotspot/share/oops/flatArrayKlass.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/objArrayKlass.cpp
+ src/hotspot/share/oops/refArrayKlass.cpp
! src/hotspot/share/opto/divnode.cpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/services/heapDumper.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/stringUtils.cpp
! src/hotspot/share/utilities/stringUtils.hpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/time/Duration.java
! src/java.base/share/classes/java/time/Instant.java
! src/java.base/share/classes/java/time/Period.java
! src/java.base/share/classes/java/time/ZonedDateTime.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
! src/jdk.compiler/share/classes/module-info.java
! src/jdk.compiler/share/man/javac.md
! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java
! test/jdk/ProblemList.txt
! test/langtools/ProblemList.txt


From dsimms at openjdk.org  Thu Oct 23 09:15:28 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 23 Oct 2025 09:15:28 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <BieWCKj9ygKJrwRatYZR3STxTVDMQPbQiLLmZSeKYDI=.ba5d8fcc-bfc1-49e1-8d8c-2078ff7f7dd6@github.com>

Merge jdk-26+19

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

Commit messages:
 - Logical merge issue
 - Merge jdk
 - 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds
 - 8367413: Fix potential truncation error in Arguments::set_heap_size()
 - 8360031: C2 compilation asserts in MemBarNode::remove
 - 8286865: vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/Test.java fails with Out of space in CodeCache
 - 8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped
 - 8364346: Typo in IR framework README
 - 8369039: JDK-8348611 caused regression in Javac-Hot-Generate
 - 8367657: C2 SuperWord: NormalMapping demo from JVMLS 2025
 - ... and 84 more: https://git.openjdk.org/valhalla/compare/412ec882...7aaadf6b

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

Changes: https://git.openjdk.org/valhalla/pull/1697/files
  Stats: 13106 lines in 507 files changed: 8331 ins; 2510 del; 2265 mod
  Patch: https://git.openjdk.org/valhalla/pull/1697.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1697/head:pull/1697

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

From paul.hubner at oracle.com  Thu Oct 23 10:10:06 2025
From: paul.hubner at oracle.com (Paul Hubner)
Date: Thu, 23 Oct 2025 10:10:06 +0000
Subject: oops crash
In-Reply-To: <2102757184.21885760.1761204336415.JavaMail.zimbra@univ-eiffel.fr>
References: <2102757184.21885760.1761204336415.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <DS0PR10MB60784FDD1B2547FBF0AF35BD83F0A@DS0PR10MB6078.namprd10.prod.outlook.com>

Hi R?mi,

Thanks for the report. I've been able to reproduce it and filed an issue here:

https://bugs.openjdk.org/browse/JDK-8370479

Best,
Paul
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Thursday, October 23, 2025 9:25 AM
To: valhalla-dev <valhalla-dev at openjdk.java.net>
Subject: oops crash

It seems that the latest version crashes when trying to run maven surefire
(i'm using the build of aleksey shipilev, so more or less the latest version of the valhalla repo)

  https://github.com/forax/weather-alert/actions/runs/18740633928/job/53456041212

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

From thartmann at openjdk.org  Thu Oct 23 11:40:33 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 23 Oct 2025 11:40:33 GMT
Subject: [lworld] RFR: 8369805: [lworld] C2: assert(is_InlineType())
 failed: invalid node class: Con
In-Reply-To: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>
References: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>
Message-ID: <0NmW3rRvKsn4uoLfyMnbk5sJai8orYyiZSKHbJ7B2lQ=.8a8f3477-0b37-4c27-a4f9-e0f7c61827c9@github.com>

On Wed, 22 Oct 2025 13:55:03 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `TestLWorld.java` was failing intermittently with `-XX:+StressIGVN` and `-XX:+StressLoopPeeling` due to not handling `top` correctly in `InlineTypeNode::merge_with()` during IGVN.
> 
> We have the following graph during IGVN:
> <img width="558" height="304" alt="image" src="https://github.com/user-attachments/assets/6c146038-208f-4f5a-bcfa-5be0d5b67537" />
> 
> The following steps happen:
> 1. `6837 Phi` was created in Loop Peeling to merge data nodes from the peeled iteration and the remaining loop (this is the reason we are only seeing this failure with `StressLoopPeeling` - there are simply more chances with more phis to get unlucky and hit the assert).
> 2. When processing `6837 Phi` in IGVN, we apply `PhiNode::try_push_inline_types_down()` in order to push the `InlineType` nodes down recursively. 
> 3. Doing it recursively, we will then call `PhiNode::try_push_inline_types_down()` on `6535 Phi`.
> 4. We create a new initial `InlineType` node based on the same klass as `6259 InlineType` (i.e. the same fields) but use `Phis` for the inputs or `InlineType` nodes if the fields are value objects themselves:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L87-L89
> This new `InlineType` node represents the resulting "pushed down" `InlineType`. Let's call it `inline-type-result`.
> 5.  We now populate the phi inputs of `inline-type-result` by visiting the `InlineType` inputs of `6535 Phi`.
> 6. We visit the first input `6259 InlineType`: We update the first input of the phis of `inline-type-result` by calling `merge_with()` on `inline-type-result`.
> 7. We visit all inputs of `inline-type-result`: These are either phis or `InlineType` nodes (see step 4). When we see an `InlineType` input, we must also see an `InlineType` input for `6259 InlineType` because we used the same klass in step 4. However, we miss here that we could also have a top input because the node is actually being removed in IGVN because we only take the other path of `6535 Phi`. Therefore this assumption is wrong:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L157-L161
> and we crash because `val2` is top.
> 
> The fix is straight forward to stop the merge since the node is dead. Since this is highly intermittent and occurring with `TestLWorld.java` only, I have not added a separate test case. Additionally to standard testing, I also ran `TestLWorld.java` 100 times in th...

Thanks for the thorough analysis Christian! Looks good to me.

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

> 160:       }
> 161:       if (val2->is_top()) {
> 162:         // The path where 'other' is used is dying. Therefore, we do not need process the merge with 'other' further.

Suggestion:

        // The path where 'other' is used is dying. Therefore, we do not need to process the merge with 'other' further.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1694#pullrequestreview-3369503073
PR Review Comment: https://git.openjdk.org/valhalla/pull/1694#discussion_r2454826830

From fparain at openjdk.org  Thu Oct 23 12:14:40 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 Oct 2025 12:14:40 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <TIVyPa2k3BOcGb3fO9TL77jrfU8BscN6fLuEziyDFsM=.b25fcb46-76f4-4a89-a548-3508684f5c5c@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <TIVyPa2k3BOcGb3fO9TL77jrfU8BscN6fLuEziyDFsM=.b25fcb46-76f4-4a89-a548-3508684f5c5c@github.com>
Message-ID: <u-Ol4AJxge_ezHUOn80vVd8RjL9dm_aFVDTc-ard-DQ=.850770cb-6aa5-4615-8c2b-2dc02bb39591@github.com>

On Wed, 22 Oct 2025 21:50:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>>  - Add alternate version of the substitutability method
>
> src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java line 1417:
> 
>> 1415:         int size = map[i * 2 + 2];
>> 1416:         int nlong = size / 8;
>> 1417:         for (int j = 0; j < nlong; j++) {
> 
> Are we sure that for all value objects with `size >= 8`, they are always 8-byte aligned?

There's a processing during the map generation that ensures this property (see last loop in FieldLayoutBuilder::generate_acmp_maps().

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2454916414

From duke at openjdk.org  Thu Oct 23 12:32:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 23 Oct 2025 12:32:12 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v3]
In-Reply-To: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
Message-ID: <YJ-4FsQnVad375fRPt7O0rtVsqNq_19yrWS2fTb2I5g=.dc6cc9f7-419f-4841-ad5d-9363bf1d6b87@github.com>

> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

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

  feedback tweaks

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1618/files
  - new: https://git.openjdk.org/valhalla/pull/1618/files/2b805fb0..7c28f220

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

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

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

From chagedorn at openjdk.org  Thu Oct 23 13:01:59 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 23 Oct 2025 13:01:59 GMT
Subject: [lworld] RFR: 8369805: [lworld] C2: assert(is_InlineType())
 failed: invalid node class: Con [v2]
In-Reply-To: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>
References: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>
Message-ID: <r1DKe8c6L_UwOe_8rPxQZ4P8EP8WI7X8tC2b2IHUqEI=.62feaaae-e032-4743-a4d4-df39d6dde1cf@github.com>

> `TestLWorld.java` was failing intermittently with `-XX:+StressIGVN` and `-XX:+StressLoopPeeling` due to not handling `top` correctly in `InlineTypeNode::merge_with()` during IGVN.
> 
> We have the following graph during IGVN:
> <img width="558" height="304" alt="image" src="https://github.com/user-attachments/assets/6c146038-208f-4f5a-bcfa-5be0d5b67537" />
> 
> The following steps happen:
> 1. `6837 Phi` was created in Loop Peeling to merge data nodes from the peeled iteration and the remaining loop (this is the reason we are only seeing this failure with `StressLoopPeeling` - there are simply more chances with more phis to get unlucky and hit the assert).
> 2. When processing `6837 Phi` in IGVN, we apply `PhiNode::try_push_inline_types_down()` in order to push the `InlineType` nodes down recursively. 
> 3. Doing it recursively, we will then call `PhiNode::try_push_inline_types_down()` on `6535 Phi`.
> 4. We create a new initial `InlineType` node based on the same klass as `6259 InlineType` (i.e. the same fields) but use `Phis` for the inputs or `InlineType` nodes if the fields are value objects themselves:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L87-L89
> This new `InlineType` node represents the resulting "pushed down" `InlineType`. Let's call it `inline-type-result`.
> 5.  We now populate the phi inputs of `inline-type-result` by visiting the `InlineType` inputs of `6535 Phi`.
> 6. We visit the first input `6259 InlineType`: We update the first input of the phis of `inline-type-result` by calling `merge_with()` on `inline-type-result`.
> 7. We visit all inputs of `inline-type-result`: These are either phis or `InlineType` nodes (see step 4). When we see an `InlineType` input, we must also see an `InlineType` input for `6259 InlineType` because we used the same klass in step 4. However, we miss here that we could also have a top input because the node is actually being removed in IGVN because we only take the other path of `6535 Phi`. Therefore this assumption is wrong:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L157-L161
> and we crash because `val2` is top.
> 
> The fix is straight forward to stop the merge since the node is dead. Since this is highly intermittent and occurring with `TestLWorld.java` only, I have not added a separate test case. Additionally to standard testing, I also ran `TestLWorld.java` 100 times in th...

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

  Update src/hotspot/share/opto/inlinetypenode.cpp
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1694/files
  - new: https://git.openjdk.org/valhalla/pull/1694/files/232e24f5..f03b789b

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

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

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

From chagedorn at openjdk.org  Thu Oct 23 13:02:02 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 23 Oct 2025 13:02:02 GMT
Subject: [lworld] RFR: 8369805: [lworld] C2: assert(is_InlineType())
 failed: invalid node class: Con
In-Reply-To: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>
References: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>
Message-ID: <ZMdt__iA-KiczdfgXTg9KFJ8AAeXPhvhL8Qews_exS0=.620d2325-a395-4264-99fa-8ac416b3f99a@github.com>

On Wed, 22 Oct 2025 13:55:03 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `TestLWorld.java` was failing intermittently with `-XX:+StressIGVN` and `-XX:+StressLoopPeeling` due to not handling `top` correctly in `InlineTypeNode::merge_with()` during IGVN.
> 
> We have the following graph during IGVN:
> <img width="558" height="304" alt="image" src="https://github.com/user-attachments/assets/6c146038-208f-4f5a-bcfa-5be0d5b67537" />
> 
> The following steps happen:
> 1. `6837 Phi` was created in Loop Peeling to merge data nodes from the peeled iteration and the remaining loop (this is the reason we are only seeing this failure with `StressLoopPeeling` - there are simply more chances with more phis to get unlucky and hit the assert).
> 2. When processing `6837 Phi` in IGVN, we apply `PhiNode::try_push_inline_types_down()` in order to push the `InlineType` nodes down recursively. 
> 3. Doing it recursively, we will then call `PhiNode::try_push_inline_types_down()` on `6535 Phi`.
> 4. We create a new initial `InlineType` node based on the same klass as `6259 InlineType` (i.e. the same fields) but use `Phis` for the inputs or `InlineType` nodes if the fields are value objects themselves:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L87-L89
> This new `InlineType` node represents the resulting "pushed down" `InlineType`. Let's call it `inline-type-result`.
> 5.  We now populate the phi inputs of `inline-type-result` by visiting the `InlineType` inputs of `6535 Phi`.
> 6. We visit the first input `6259 InlineType`: We update the first input of the phis of `inline-type-result` by calling `merge_with()` on `inline-type-result`.
> 7. We visit all inputs of `inline-type-result`: These are either phis or `InlineType` nodes (see step 4). When we see an `InlineType` input, we must also see an `InlineType` input for `6259 InlineType` because we used the same klass in step 4. However, we miss here that we could also have a top input because the node is actually being removed in IGVN because we only take the other path of `6535 Phi`. Therefore this assumption is wrong:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L157-L161
> and we crash because `val2` is top.
> 
> The fix is straight forward to stop the merge since the node is dead. Since this is highly intermittent and occurring with `TestLWorld.java` only, I have not added a separate test case. Additionally to standard testing, I also ran `TestLWorld.java` 100 times in th...

Thanks Tobias for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1694#issuecomment-3436781011

From chagedorn at openjdk.org  Thu Oct 23 13:02:03 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 23 Oct 2025 13:02:03 GMT
Subject: [lworld] Integrated: 8369805: [lworld] C2: assert(is_InlineType())
 failed: invalid node class: Con
In-Reply-To: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>
References: <_o_zxPuFBD-x-mZtTHUm6AZhVU_rC6EGkj9bTqhHjlc=.858cfadd-fc1f-454f-bbed-01e4a3f5e54e@github.com>
Message-ID: <BgQheDs6MrYDjy_SB6YVdNgLiv6gQ00y7FcZCSI4sD0=.57bd409f-a4c5-456f-b285-a188768e9563@github.com>

On Wed, 22 Oct 2025 13:55:03 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `TestLWorld.java` was failing intermittently with `-XX:+StressIGVN` and `-XX:+StressLoopPeeling` due to not handling `top` correctly in `InlineTypeNode::merge_with()` during IGVN.
> 
> We have the following graph during IGVN:
> <img width="558" height="304" alt="image" src="https://github.com/user-attachments/assets/6c146038-208f-4f5a-bcfa-5be0d5b67537" />
> 
> The following steps happen:
> 1. `6837 Phi` was created in Loop Peeling to merge data nodes from the peeled iteration and the remaining loop (this is the reason we are only seeing this failure with `StressLoopPeeling` - there are simply more chances with more phis to get unlucky and hit the assert).
> 2. When processing `6837 Phi` in IGVN, we apply `PhiNode::try_push_inline_types_down()` in order to push the `InlineType` nodes down recursively. 
> 3. Doing it recursively, we will then call `PhiNode::try_push_inline_types_down()` on `6535 Phi`.
> 4. We create a new initial `InlineType` node based on the same klass as `6259 InlineType` (i.e. the same fields) but use `Phis` for the inputs or `InlineType` nodes if the fields are value objects themselves:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L87-L89
> This new `InlineType` node represents the resulting "pushed down" `InlineType`. Let's call it `inline-type-result`.
> 5.  We now populate the phi inputs of `inline-type-result` by visiting the `InlineType` inputs of `6535 Phi`.
> 6. We visit the first input `6259 InlineType`: We update the first input of the phis of `inline-type-result` by calling `merge_with()` on `inline-type-result`.
> 7. We visit all inputs of `inline-type-result`: These are either phis or `InlineType` nodes (see step 4). When we see an `InlineType` input, we must also see an `InlineType` input for `6259 InlineType` because we used the same klass in step 4. However, we miss here that we could also have a top input because the node is actually being removed in IGVN because we only take the other path of `6535 Phi`. Therefore this assumption is wrong:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L157-L161
> and we crash because `val2` is top.
> 
> The fix is straight forward to stop the merge since the node is dead. Since this is highly intermittent and occurring with `TestLWorld.java` only, I have not added a separate test case. Additionally to standard testing, I also ran `TestLWorld.java` 100 times in th...

This pull request has now been integrated.

Changeset: 60af17ff
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/60af17ff5995cfa5de075332355f7f475c163865
Stats:     12 lines in 2 files changed: 5 ins; 0 del; 7 mod

8369805: [lworld] C2: assert(is_InlineType()) failed: invalid node class: Con

Reviewed-by: thartmann

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

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

From rriggs at openjdk.org  Thu Oct 23 13:48:11 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Oct 2025 13:48:11 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
Message-ID: <mZdoeugM1bBhbyT6Klfomj5QIl7PYiS-sRInfYf99vU=.06834fac-8056-4f88-8a30-3657665e4ee4@github.com>

On Tue, 14 Oct 2025 12:34:14 GMT, David Beaumont <duke at openjdk.org> wrote:

>> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorganising to catch preview-only cases

Still looks good. One question.

src/hotspot/share/classfile/classLoader.cpp line 1522:

> 1520:   if (jimage_exists()) {
> 1521:     jimage_init(enable_preview);
> 1522:   }

This silently ignores enable_preview if there there is no open image. 
Is it only the exploded build that will not have an open image?
Should there be an assert on the false branch of  `jimage_exists`?

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1618#pullrequestreview-3362126080
PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2449299184

From duke at openjdk.org  Thu Oct 23 13:56:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 23 Oct 2025 13:56:57 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <mZdoeugM1bBhbyT6Klfomj5QIl7PYiS-sRInfYf99vU=.06834fac-8056-4f88-8a30-3657665e4ee4@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
 <mZdoeugM1bBhbyT6Klfomj5QIl7PYiS-sRInfYf99vU=.06834fac-8056-4f88-8a30-3657665e4ee4@github.com>
Message-ID: <BFrwZEqVVnMGY8X_MlsKOxlhGjnjbeBRcS-Uziy7fXo=.87725397-9748-4175-a270-cdfcce5d0e1f@github.com>

On Tue, 21 Oct 2025 18:21:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reorganising to catch preview-only cases
>
> src/hotspot/share/classfile/classLoader.cpp line 1522:
> 
>> 1520:   if (jimage_exists()) {
>> 1521:     jimage_init(enable_preview);
>> 1522:   }
> 
> This silently ignores enable_preview if there there is no open image. 
> Is it only the exploded build that will not have an open image?
> Should there be an assert on the false branch of  `jimage_exists`?

Interesting question. I'll have a think.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2455229688

From duke at openjdk.org  Thu Oct 23 13:56:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 23 Oct 2025 13:56:58 GMT
Subject: [lworld] RFR: 8366093: [lworld] Add preview mode to C++
 classloader [v2]
In-Reply-To: <0w4DRW58XsZbEEgPVpmVPj9iDgTeSwABKe-9gk2h3mw=.38539872-4ece-473d-8834-07b76109bdb4@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
 <ksWWHyV6KOm3FH3gd7Gp0oipmCclhOrlWEW4di_jQQQ=.84376781-431b-48f2-8d94-3d2c2ff259a0@github.com>
 <0w4DRW58XsZbEEgPVpmVPj9iDgTeSwABKe-9gk2h3mw=.38539872-4ece-473d-8834-07b76109bdb4@github.com>
Message-ID: <vXV7_sQvM-gn5OSGH3RQ578Bok_nHraq45k_t2OjR-4=.d23eca83-312b-4a0b-acb4-b483fa2b5749@github.com>

On Wed, 15 Oct 2025 09:07:37 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reorganising to catch preview-only cases
>
> src/java.base/share/native/libjimage/jimage.cpp line 190:
> 
>> 188:         index += preview_infix_len;
>> 189:         // Check we copied up to the expected '/' separator.
>> 190:         assert(name_buffer[index] == '/' && "bad string concatenation");
> 
> Here as well fwiw.

Done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1618#discussion_r2455230879

From rriggs at openjdk.org  Thu Oct 23 15:45:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Oct 2025 15:45:14 GMT
Subject: [lworld] RFR: 8369921: [lworld] Remove caches of primitive wrapper
 classes [v2]
In-Reply-To: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
References: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
Message-ID: <-vjewFvOLTOFrsh1JwNdLQ9Ebgyi91J2Fgp-rQkZPqw=.2fb7d396-3ec6-431b-b1ca-d64468823e9e@github.com>

> Disable use of wrapper cached values when --enable-preview and add javadoc descriptions for enable-preview.
> The wrapper classes are Byte, Short, Character, Integer, and Long.

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

  Review suggestions to put constant locals into non-preview block
  and use the same code pattern for Boolean.valueOf.
  Update some tests to run in --enable-preview as well as non-preview.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1685/files
  - new: https://git.openjdk.org/valhalla/pull/1685/files/5b7e32a8..10eab814

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

  Stats: 18 lines in 6 files changed: 15 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1685.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1685/head:pull/1685

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

From rriggs at openjdk.org  Thu Oct 23 15:51:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Oct 2025 15:51:14 GMT
Subject: RFR: 8368333: [lworld] Add preview mode to ImageReader and JRT
 file-system [v7]
In-Reply-To: <RcV9JYxCYZSDkckXnora8V0yvXkQZ9OHep0hHt-pPJM=.3fd34f9d-9c4a-4efd-8b50-fbf67a450978@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
 <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
 <RcV9JYxCYZSDkckXnora8V0yvXkQZ9OHep0hHt-pPJM=.3fd34f9d-9c4a-4efd-8b50-fbf67a450978@github.com>
Message-ID: <wQC6SrGmNky7njKjDxWHpCwd6ASDVy-SEQeCIfv2c3Y=.460857e8-38ba-4997-88b0-fbc6792b62cc@github.com>

On Wed, 22 Oct 2025 19:35:37 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageStrings.java line 38:
>> 
>>> 36:     // String offset constants are useful for efficient classification
>>> 37:     // of location entries without string comparison. These may change
>>> 38:     // between jimage versions (they are checked during initialization).
>> 
>> The checking seem only to be done when ImageStringsWriter is loaded/initialized.
>> There may be a small risk that a mismatch of the image with the ImageStringsReader could occur.
>> Can they be checked also by the reader?
>
> Hmm, I don't see a nice way to do this at runtime since you can't lookup string offsets by their value (as far as I can see).
> 
> It's no more fragile than the old code (which had hard-coded constants for "class" and "" (and wasn't self-checking their validity). At least now it's tested at build time.
> 
> If the version number matches it should be safe. I'll add a comment about how changing existing entries is problematic.

Seems unlikely to mismatch.  
ImageStringReader.match(offset, string, indxe) could be used to check the Strings or ImageStringReader.get(offset).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2455711286

From matsaave at openjdk.org  Thu Oct 23 20:24:57 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 23 Oct 2025 20:24:57 GMT
Subject: [lworld] RFR: 8370217: [lworld] Crash in add_migrated_value_classes
 after merging JDK-8350550
Message-ID: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>

The method add_migrated_value_classes() is being called in non-preview mode leading to an assert due to the expected classes not being present in the AOT cache. The check for `EnableValhalla` is replaced with a check for preview mode. Verified with tier 1-5 tests.

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

Commit messages:
 - 8370217: [lworld] Crash in add_migrated_value_classes after merging JDK-8350550

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

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

From rriggs at openjdk.org  Thu Oct 23 20:26:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Oct 2025 20:26:38 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
Message-ID: <svv9AIskuHSbLUI_WQxVtVxmrsRjFFe-rDy8XQFdx6c=.baa00720-61eb-4933-85df-60772e7bccb0@github.com>

On Wed, 22 Oct 2025 18:17:30 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>  - Add alternate version of the substitutability method

When comparing the oops, do they need some additional handling?
Supposing for example, they are buffered value objects (from different sources).
It seems necessary to recurse (effectively) with those oops/refs.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1695#issuecomment-3438994804

From duke at openjdk.org  Thu Oct 23 20:34:13 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 23 Oct 2025 20:34:13 GMT
Subject: [lworld] Integrated: 8366093: [lworld] Add preview mode to C++
 classloader
In-Reply-To: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
References: <fXchIENgiRpYDgX6jTQx7gUAmAvOQ6mf-XeJHEKJXsQ=.ca647234-35fd-4167-988e-f805f30bc7fe@github.com>
Message-ID: <Ua13Iygtvc1OEGpLZikgFEIjaxZuB6-enBkpw0-wwHU=.25068d3e-bf49-4241-91a7-1a69b069ea73@github.com>

On Tue, 23 Sep 2025 19:11:41 GMT, David Beaumont <duke at openjdk.org> wrote:

> C++ changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes being zero (which matches location flags for "normal" entries).

This pull request has now been integrated.

Changeset: 6d774f68
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6d774f688b000f02f8a211b657051d28ca51727a
Stats:     328 lines in 8 files changed: 217 ins; 50 del; 61 mod

8366093: [lworld] Add preview mode to C++ classloader

Reviewed-by: phubner, rriggs

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

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

From coleenp at openjdk.org  Thu Oct 23 20:29:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Oct 2025 20:29:40 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <u-Ol4AJxge_ezHUOn80vVd8RjL9dm_aFVDTc-ard-DQ=.850770cb-6aa5-4615-8c2b-2dc02bb39591@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <TIVyPa2k3BOcGb3fO9TL77jrfU8BscN6fLuEziyDFsM=.b25fcb46-76f4-4a89-a548-3508684f5c5c@github.com>
 <u-Ol4AJxge_ezHUOn80vVd8RjL9dm_aFVDTc-ard-DQ=.850770cb-6aa5-4615-8c2b-2dc02bb39591@github.com>
Message-ID: <g-lz5cU7xAGDzaD30knFdnSyTh05DPohS6iPBDpZ41U=.f5c77e50-2125-4b4c-87ff-e1e11cbfd2a6@github.com>

On Thu, 23 Oct 2025 12:12:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java line 1417:
>> 
>>> 1415:         int size = map[i * 2 + 2];
>>> 1416:         int nlong = size / 8;
>>> 1417:         for (int j = 0; j < nlong; j++) {
>> 
>> Are we sure that for all value objects with `size >= 8`, they are always 8-byte aligned?
>
> There's a processing during the map generation that ensures this property (see last loop in FieldLayoutBuilder::generate_acmp_maps().

I hate to ask but doesn't memcmp do this, ie optimize the sizes for comparison?  Or is there a Java API that does this compare a, b for size and compare long first?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2457012287

From fparain at openjdk.org  Thu Oct 23 20:43:54 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 Oct 2025 20:43:54 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v3]
In-Reply-To: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
Message-ID: <NK5SWWiGU7JX5YZs5FqZOgR5JHtZkpCeY1nBndRfilQ=.206c2d01-c50e-47fc-91a8-6f24eecfa9d0@github.com>

> This is an alternate version of the substitutability method.
> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'upstream/lworld' into new_acmp
 - Apply changes suggested in review
 - Merge remote-tracking branch 'upstream/lworld' into new_acmp
 - Add alternate version of the substitutability method

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

Changes: https://git.openjdk.org/valhalla/pull/1695/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1695&range=02
  Stats: 337 lines in 18 files changed: 332 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1695.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1695/head:pull/1695

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

From fparain at openjdk.org  Thu Oct 23 20:43:57 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 Oct 2025 20:43:57 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <TIVyPa2k3BOcGb3fO9TL77jrfU8BscN6fLuEziyDFsM=.b25fcb46-76f4-4a89-a548-3508684f5c5c@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <TIVyPa2k3BOcGb3fO9TL77jrfU8BscN6fLuEziyDFsM=.b25fcb46-76f4-4a89-a548-3508684f5c5c@github.com>
Message-ID: <wb49oEYed06vjVbUHrHIE-pnhtVZrNladQL5f2C4x2A=.055f74bd-1b82-4e48-b645-755542b92aa0@github.com>

On Wed, 22 Oct 2025 21:15:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>>  - Add alternate version of the substitutability method
>
> src/hotspot/share/classfile/fieldLayoutBuilder.hpp line 289:
> 
>> 287:   FieldLayout* _layout;
>> 288:   FieldLayout* _static_layout;
>> 289:   GrowableArray<Pair<int,int>>* _nonoop_acmp_map ;
> 
> Suggestion:
> 
>   GrowableArray<Pair<int,int>>* _nonoop_acmp_map;

Fixed

> src/hotspot/share/oops/instanceKlass.hpp line 650:
> 
>> 648:   ReferenceType reference_type() const     { return (ReferenceType)_reference_type; }
>> 649: 
>> 650:   int acmp_maps_offset() const { return _acmp_maps_offset; }
> 
> Probably assert `_acmp_maps_offset != 0`

Fixed

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2457247239
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2457246135

From coleenp at openjdk.org  Thu Oct 23 20:29:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Oct 2025 20:29:38 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
Message-ID: <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>

On Wed, 22 Oct 2025 18:17:30 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>  - Add alternate version of the substitutability method

It's really great work.  I have some questions and minor suggested changes.

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

> 1579:   if (!access_flags().is_identity_class() && !access_flags().is_interface()
> 1580:       && _class_name != vmSymbols::java_lang_Object()) {
> 1581:     // Acmp map required for abstract and concrete value classes

Thank you for this comment.  Explains why abstract classes are omitted from above.

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

> 5544:     // Current format of acmp maps:
> 5545:     // All maps are stored contiguously in a single int array because it might
> 5546:     // be to early to instantiate an Object array (to be investigated)

Suggestion:

    // be to early too instantiate an Object array (to be investigated)

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

> 1301:   int start = map->adr_at(last_idx)->first > offset ? 0 : last_idx;
> 1302:   bool inserted = false;
> 1303:   for (int c = start; c < map->length() && !inserted ; c++) {

You don't need to check inserted in this for loop because you have breaks, if I'm reading this right.

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

> 1359:   _nonoop_acmp_map = new GrowableArray<Pair<int,int>>();
> 1360:   _oop_acmp_map = new GrowableArray<int>();
> 1361:   if (_is_empty_inline_class) return;

Why not return first before allocating these GrowableArray in resource area?

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

> 1379:       case LayoutRawBlock::REGULAR:
> 1380:         {
> 1381:           FieldInfo* fi = _field_info->adr_at(b->field_index());

Is there an assumption that the block field indexes are in ascending order?

src/hotspot/share/interpreter/bytecodeTracer.cpp line 95:

> 93:   void trace(const methodHandle& method, address bcp, uintptr_t tos, uintptr_t tos2, outputStream* st) {
> 94:     ResourceMark rm;
> 95:     ttyLocker ttyl;

This should be removed with [JDK-8370044](https://bugs.openjdk.org/browse/JDK-8370044)

src/hotspot/share/prims/unsafe.cpp line 970:

> 968: 
> 969:   if (!k->is_inline_klass()) {
> 970:         THROW_MSG_NULL(vmSymbols::java_lang_IllegalArgumentException(), "Argument is not a concrete value class");

Suggestion:

    THROW_MSG_NULL(vmSymbols::java_lang_IllegalArgumentException(), "Argument is not a concrete value class");

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

PR Review: https://git.openjdk.org/valhalla/pull/1695#pullrequestreview-3371719787
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2456541098
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2456520373
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2457181896
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2456569995
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2457185262
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2456605058
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2456615932

From coleenp at openjdk.org  Thu Oct 23 20:47:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Oct 2025 20:47:56 GMT
Subject: [lworld] RFR: 8370509: [lworld] EnableValhalla is not needed for sync
Message-ID: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>

I took out EnableValhalla as a conditional test in the ObjectSynchronizer code.  If the inline type bit is set in the markWord or the klass is InlineKlass, we can't synchronize on the object.
I added a test but it was sort of a duplicate of all runtime/valhalla/inlinetypes/MonitorEnterTest.java and duplicates all tests that do locking so I didn't add a test.
Testing with tier1-4, still in progress.

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

Commit messages:
 - 8370509: [lworld] EnableValhalla is not needed for sync

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

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

From duke at openjdk.org  Thu Oct 23 20:49:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 23 Oct 2025 20:49:10 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v6]
In-Reply-To: <U6cMchyMzg6fQsecZ3MPVVYZrDh8oB0464rQ8dcXCDk=.9c3419b1-0593-402d-aa8f-07913d543304@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>
 <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>
 <B3NeaC3cZlfBlcPmwx1_7iQf2m1t4TQSEDWXMuIBFMk=.eaa9c5f7-cc6b-4d31-b139-4dfa94bed517@github.com>
 <U6cMchyMzg6fQsecZ3MPVVYZrDh8oB0464rQ8dcXCDk=.9c3419b1-0593-402d-aa8f-07913d543304@github.com>
Message-ID: <-h3f2-ixhpzxnqUkwKlZVrZWerifLxvE8Yu-fMxLao8=.615a45ae-6291-4f5e-9c01-e213961460c0@github.com>

On Wed, 22 Oct 2025 19:33:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> They are NOT opposites. It is not possible to use only one or these flags and continue to be logically correct.
>
> Hmm, the implementation of `isPreviewOnly()` is exactly `!hasNormalVersion(flags)`

Oh I see what you mean. The outer API is `isPreviewOnly()` because that matches the semantics of the flags it is used to create in the parent directory (ImageLocation flags). However, as stated in the comments, the private (completely encapsulated) flag values inside the class are best defined in terms of additive flags. This is so you can merge entries easily.

If the inner flag was an "IS_PREVIEW_ONLY" flag, you'd have it *set* and later *cleared* when a new resource entry that *wasn't* a preview entry was processed. By making the flags "IS_XXX_VERSION", you just set them for each resource, completely independently, and then, when the references are merged, you just OR the flags together.

I mean I could change the public API to be talking about "has normal version", but then the code that calculates the parent directory's flags will look less clear than it does now. Instead of "parent dir is preview only if all entries are preview only" it would be "parent directory is preview only if no child entries have normal versions".

This is just an example of the internal working of an encapsulated class not matching its public API for technical reasons. But that's why you encapsulate things, so the inner working can do what they do best, and the outer API can be friendly to the callers.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2457273279

From fparain at openjdk.org  Thu Oct 23 20:55:26 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 Oct 2025 20:55:26 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
Message-ID: <9amCNaGFK3GuKNUJCWAB_-2LCurzOs6OCTDzITMR87o=.e3a43efe-986f-4545-9689-c5caaa6f3a38@github.com>

On Thu, 23 Oct 2025 18:13:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>>  - Add alternate version of the substitutability method
>
> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1361:
> 
>> 1359:   _nonoop_acmp_map = new GrowableArray<Pair<int,int>>();
>> 1360:   _oop_acmp_map = new GrowableArray<int>();
>> 1361:   if (_is_empty_inline_class) return;
> 
> Why not return first before allocating these GrowableArray in resource area?

It streamlines the code in InstanceKlass::fill_instance_klass() by not having to handle the null map case.

> src/hotspot/share/interpreter/bytecodeTracer.cpp line 95:
> 
>> 93:   void trace(const methodHandle& method, address bcp, uintptr_t tos, uintptr_t tos2, outputStream* st) {
>> 94:     ResourceMark rm;
>> 95:     ttyLocker ttyl;
> 
> This should be removed with [JDK-8370044](https://bugs.openjdk.org/browse/JDK-8370044)

It is just a quick hack because I needed to use TraceBytecode to evaluate the new acmp.
I'll remove it before pushing.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2457297856
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2457288265

From rriggs at openjdk.org  Thu Oct 23 21:06:08 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Oct 2025 21:06:08 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v6]
In-Reply-To: <-h3f2-ixhpzxnqUkwKlZVrZWerifLxvE8Yu-fMxLao8=.615a45ae-6291-4f5e-9c01-e213961460c0@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>
 <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>
 <B3NeaC3cZlfBlcPmwx1_7iQf2m1t4TQSEDWXMuIBFMk=.eaa9c5f7-cc6b-4d31-b139-4dfa94bed517@github.com>
 <U6cMchyMzg6fQsecZ3MPVVYZrDh8oB0464rQ8dcXCDk=.9c3419b1-0593-402d-aa8f-07913d543304@github.com>
 <-h3f2-ixhpzxnqUkwKlZVrZWerifLxvE8Yu-fMxLao8=.615a45ae-6291-4f5e-9c01-e213961460c0@github.com>
Message-ID: <9BUM_QWelFHvaTWWyoUl_WCMhm9xgkV25otkaNxlSh8=.ac1d71e1-8a34-4c13-8f7b-fb885763069e@github.com>

On Thu, 23 Oct 2025 20:46:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Hmm, the implementation of `isPreviewOnly()` is exactly `!hasNormalVersion(flags)`
>
> Oh I see what you mean. The outer API is `isPreviewOnly()` because that matches the semantics of the flags it is used to create in the parent directory (ImageLocation flags). However, as stated in the comments, the private (completely encapsulated) flag values inside the class are best defined in terms of additive flags. This is so you can merge entries easily.
> 
> If the inner flag was an "IS_PREVIEW_ONLY" flag, you'd have it *set* and later *cleared* when a new resource entry that *wasn't* a preview entry was processed. By making the flags "IS_XXX_VERSION", you just set them for each resource, completely independently, and then, when the references are merged, you just OR the flags together.
> 
> I mean I could change the public API to be talking about "has normal version", but then the code that calculates the parent directory's flags will look less clear than it does now. Instead of "parent dir is preview only if all entries are preview only" it would be "parent directory is preview only if no child entries have normal versions".
> 
> This is just an example of the internal working of an encapsulated class not matching its public API for technical reasons. But that's why you encapsulate things, so the inner working can do what they do best, and the outer API can be friendly to the callers.

Leave it alone, maybe it will ultimately show its value.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2457342522

From fparain at openjdk.org  Thu Oct 23 20:55:22 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 23 Oct 2025 20:55:22 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <svv9AIskuHSbLUI_WQxVtVxmrsRjFFe-rDy8XQFdx6c=.baa00720-61eb-4933-85df-60772e7bccb0@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <svv9AIskuHSbLUI_WQxVtVxmrsRjFFe-rDy8XQFdx6c=.baa00720-61eb-4933-85df-60772e7bccb0@github.com>
Message-ID: <Qc7bLtYQY6NvCtri0nSNKGlzHz-EZT_NgGI4cOpvATA=.f96f7b52-f77c-4dfd-bf9f-ef5d328cd639@github.com>

On Thu, 23 Oct 2025 20:24:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> When comparing the oops, do they need some additional handling? Supposing for example, they are buffered value objects (from different sources). It seems necessary to recurse (effectively) with those oops/refs.

The recursion is handled in ValueObjectMethods.isSubstitutableAlt() line 1447, the oops are compare using an acmp bytecode which will recurse if both oops are non null and instances of the same value class.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1695#issuecomment-3439098903

From liach at openjdk.org  Thu Oct 23 23:55:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Oct 2025 23:55:25 GMT
Subject: [lworld] RFR: 8369921: [lworld] Remove caches of primitive wrapper
 classes [v2]
In-Reply-To: <2hgmo4bo68x3p_vYZE1NxIfF9b5GNTH-cGdxCplDkP0=.caaa59e9-3aab-4370-819d-10bc1c72a937@github.com>
References: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
 <2hgmo4bo68x3p_vYZE1NxIfF9b5GNTH-cGdxCplDkP0=.caaa59e9-3aab-4370-819d-10bc1c72a937@github.com>
Message-ID: <mUTJzCchtW8KMlwSsPotQ5cv_JBFFkW09d6pNOP6lnc=.6470a63f-f394-4879-8937-935403b55bbe@github.com>

On Mon, 20 Oct 2025 15:11:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestions to put constant locals into non-preview block
>>   and use the same code pattern for Boolean.valueOf.
>>   Update some tests to run in --enable-preview as well as non-preview.
>
> src/java.base/share/classes/java/lang/Short.java line 301:
> 
>> 299:     public static Short valueOf(short s) {
>> 300:         final int offset = 128;
>> 301:         int sAsInt = s;
> 
> Same remark, I recommend moving this into the preview feature check block.

I think you missed the `sAsInt` variable.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1685#discussion_r2457996306

From amenkov at openjdk.org  Fri Oct 24 01:05:12 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 24 Oct 2025 01:05:12 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat fields
 formats
Message-ID: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>

The fix re-implements flat object support in heap dumper.
New approach does not require changes in .hprof format.
Flat value objects are dumped as heap-allocated objects with generated ID.
For heap-allocated objects the ID is their address (oop), they are always aligned.
ID generator for flat objects uses unaligned values (so there is no conflicts with oops).

HeapDump test was reimplemented (it was disabled for a long time)
Changes in hprof test lib were reverted (they are not needed anymore)

testing: tier1..4,hs-tier5-svc

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

Commit messages:
 - new implementation
 - revert old implementation
 - revert old implementation

Changes: https://git.openjdk.org/valhalla/pull/1700/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1700&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341771
  Stats: 1420 lines in 10 files changed: 297 ins; 941 del; 182 mod
  Patch: https://git.openjdk.org/valhalla/pull/1700.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1700/head:pull/1700

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

From dsimms at openjdk.org  Fri Oct 24 09:04:44 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 24 Oct 2025 09:04:44 GMT
Subject: [lworld] RFR: [lworld] 8366093 breaks build
Message-ID: <-0JIICkYv1wKrmIqV_a4edTusiB3-_4V534Il38NacU=.707fe353-e1a0-4d01-aa06-837358dccaca@github.com>

stdc assert

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

Commit messages:
 - [lworld] 8366093 breaks build

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

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

From dsimms at openjdk.org  Fri Oct 24 09:33:40 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 24 Oct 2025 09:33:40 GMT
Subject: [lworld] Integrated: [lworld] 8366093 breaks build
In-Reply-To: <-0JIICkYv1wKrmIqV_a4edTusiB3-_4V534Il38NacU=.707fe353-e1a0-4d01-aa06-837358dccaca@github.com>
References: <-0JIICkYv1wKrmIqV_a4edTusiB3-_4V534Il38NacU=.707fe353-e1a0-4d01-aa06-837358dccaca@github.com>
Message-ID: <qQMch7yu-HtHpIT8M1NzIRFTQHbA_wUkfWDBQid8-4E=.608a24a9-4e85-43f2-bad1-d99861bd09c7@github.com>

On Fri, 24 Oct 2025 08:55:25 GMT, David Simms <dsimms at openjdk.org> wrote:

> stdc assert

This pull request has now been integrated.

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

[lworld] 8366093 breaks build

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

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

From dsimms at openjdk.org  Fri Oct 24 10:21:58 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 24 Oct 2025 10:21:58 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <BieWCKj9ygKJrwRatYZR3STxTVDMQPbQiLLmZSeKYDI=.ba5d8fcc-bfc1-49e1-8d8c-2078ff7f7dd6@github.com>
References: <BieWCKj9ygKJrwRatYZR3STxTVDMQPbQiLLmZSeKYDI=.ba5d8fcc-bfc1-49e1-8d8c-2078ff7f7dd6@github.com>
Message-ID: <hWt6B56gfyp8fczAktslBBsBcPr77VHawu-t8Z3wVRg=.5220c754-5d48-4887-bff4-b1cf54d2dfbb@github.com>

> Merge jdk-26+19

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits:

 - Merge branch 'lworld' into lworld_merge_jdk_26_19
 - Adjust testing
 - Logical merge issue
 - Merge jdk
   
   Merge tag 'jdk-26+19' into lworld_merge_jdk_26_19
   
   Added tag jdk-26+19 for changeset b37a1a33
 - 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds
   
   Reviewed-by: jpai, dfuchs, vyazici
 - 8367413: Fix potential truncation error in Arguments::set_heap_size()
   
   Reviewed-by: ayang, lkorinth
 - 8360031: C2 compilation asserts in MemBarNode::remove
   
   Reviewed-by: dlong, kvn, shade
 - 8286865: vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/Test.java fails with Out of space in CodeCache
   
   Reviewed-by: dlong, chagedorn
 - 8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped
   
   Reviewed-by: valeriep
 - 8364346: Typo in IR framework README
   
   Reviewed-by: thartmann, fandreuzzi, chagedorn
 - ... and 86 more: https://git.openjdk.org/valhalla/compare/7257a072...6b6c7bd1

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

Changes: https://git.openjdk.org/valhalla/pull/1697/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1697&range=01
  Stats: 13114 lines in 507 files changed: 8339 ins; 2510 del; 2265 mod
  Patch: https://git.openjdk.org/valhalla/pull/1697.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1697/head:pull/1697

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

From phubner at openjdk.org  Fri Oct 24 11:57:31 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 24 Oct 2025 11:57:31 GMT
Subject: [lworld] RFR: 8370509: [lworld] EnableValhalla is not needed for
 sync
In-Reply-To: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
References: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
Message-ID: <u44Zpn9Ia327px5WO35hiyriEM9XlWBE1mexYA2AlDg=.96e7b816-d0f8-4cbb-a9bd-7580ed939fb3@github.com>

On Thu, 23 Oct 2025 20:30:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I took out EnableValhalla as a conditional test in the ObjectSynchronizer code.  If the inline type bit is set in the markWord or the klass is InlineKlass, we can't synchronize on the object.
> I added a test but it was sort of a duplicate of all runtime/valhalla/inlinetypes/MonitorEnterTest.java and duplicates all tests that do locking so I didn't add a test.
> Testing with tier1-4, still in progress.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 7939:

> 7937:   orr(mark, mark, markWord::unlocked_value);
> 7938:   // Mask inline_type bit such that we go to the slow path if object is an inline type
> 7939:   andr(mark, mark, ~((int) markWord::inline_type_bit_in_place));

Since `EnableValhalla=true` by default, we were already exercising this path by default. 

Can we get into a situation where we do not use the object monitor table and the markword is inflated while we perform this check? We would get in trouble with this bit check if we can.

src/hotspot/share/runtime/synchronizer.cpp line 687:

> 685: intptr_t ObjectSynchronizer::FastHashCode(Thread* current, oop obj) {
> 686:   // VM should be calling bootstrap method
> 687:   assert(!obj->klass()->is_inline_klass(), "should not reach here");

Nitpick: more descriptive message.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1699#discussion_r2460025047
PR Review Comment: https://git.openjdk.org/valhalla/pull/1699#discussion_r2460036561

From duke at openjdk.org  Fri Oct 24 12:23:20 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 24 Oct 2025 12:23:20 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v8]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <RWU1Eb2oGuf9BBbC4gxzM920f1AgKY3PLDE0H9SnrQA=.ecc57a76-37e9-44ea-8ab7-4ed913068b41@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Resync after dependent PR submit.
  
  * Removing package root flag based on feedback.
  * Changing existing package flags during writing to match altered flag values.
  * Feedback changes, and fixing some comments.
  * Renaming slightly confusing "testEncoder" method.
  * Fixing unit tests to use new constructor.
  * Word smithing flags definitions.
  * Add workaround until new image writing code is in
  * Clarifying flag docs for /packages/xxx case
  * Java ImageReader changes for preview mode

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

Changes: https://git.openjdk.org/valhalla/pull/1619/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1619&range=07
  Stats: 1400 lines in 19 files changed: 1139 ins; 107 del; 154 mod
  Patch: https://git.openjdk.org/valhalla/pull/1619.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1619/head:pull/1619

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

From fparain at openjdk.org  Fri Oct 24 13:57:37 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 24 Oct 2025 13:57:37 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
Message-ID: <4BrLkRJDuPVg1D_Arw-EC0axkTgy32dSIBBKV0EEnlk=.b552943f-c41e-48d8-a124-554cbbe5b04f@github.com>

On Thu, 23 Oct 2025 20:26:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>>  - Add alternate version of the substitutability method
>
> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1381:
> 
>> 1379:       case LayoutRawBlock::REGULAR:
>> 1380:         {
>> 1381:           FieldInfo* fi = _field_info->adr_at(b->field_index());
> 
> Is there an assumption that the block field indexes are in ascending order?

I'm not sure I understand the question.
LayoutRawBlocks represent the fields layout, they are chained in ascending offset order.
The field_index is the index in the FieldInfo array (from the class file) where this field is declared.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2460605982

From duke at openjdk.org  Fri Oct 24 14:24:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 24 Oct 2025 14:24:54 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v7]
In-Reply-To: <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
 <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
Message-ID: <klxqhu-jbi_uMlSH7xTcOjxf3JcMmj0wcxkU4fyyNx4=.957a162b-e0cd-41de-a3bb-3b80b81dee85@github.com>

On Tue, 21 Oct 2025 18:52:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request with a new target base due to a merge or a rebase.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 48:
> 
>> 46:     public static final int ATTRIBUTE_COMPRESSED = 6;
>> 47:     public static final int ATTRIBUTE_UNCOMPRESSED = 7;
>> 48:     public static final int ATTRIBUTE_PREVIEW_FLAGS = 8;
> 
> Please add a comment above these constants that the values are defined in ImageFile.hpp.

Done. Thought really I'd say they are defined here, since this is what the code that creates the jimage file uses (so these constants are definitive). The C++ ones are copies for the C++ reading code.

> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 57:
> 
>> 55:     /** If set, the associated module has resources (in normal or preview mode). */
>> 56:     // TODO: Make this private again when image writer code is updated.
>> 57:     public static final int FLAGS_HAS_CONTENT = 0x4;
> 
> Please change the prefix of these to distinguish them from the ImageLocation flags.
> For example, "PKG_" or "MR_".

Done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2460165787
PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2460317902

From duke at openjdk.org  Fri Oct 24 14:24:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 24 Oct 2025 14:24:55 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v7]
In-Reply-To: <wQC6SrGmNky7njKjDxWHpCwd6ASDVy-SEQeCIfv2c3Y=.460857e8-38ba-4997-88b0-fbc6792b62cc@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
 <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
 <RcV9JYxCYZSDkckXnora8V0yvXkQZ9OHep0hHt-pPJM=.3fd34f9d-9c4a-4efd-8b50-fbf67a450978@github.com>
 <wQC6SrGmNky7njKjDxWHpCwd6ASDVy-SEQeCIfv2c3Y=.460857e8-38ba-4997-88b0-fbc6792b62cc@github.com>
Message-ID: <B812yZVGqgtGp892A5PTZzDkWb9QUVXiqIajviN1SIw=.edf31f46-405e-43d0-8276-2e06229c9aaa@github.com>

On Thu, 23 Oct 2025 15:48:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hmm, I don't see a nice way to do this at runtime since you can't lookup string offsets by their value (as far as I can see).
>> 
>> It's no more fragile than the old code (which had hard-coded constants for "class" and "" (and wasn't self-checking their validity). At least now it's tested at build time.
>> 
>> If the version number matches it should be safe. I'll add a comment about how changing existing entries is problematic.
>
> Seems unlikely to mismatch.  
> ImageStringReader.match(offset, string, indxe) could be used to check the Strings or ImageStringReader.get(offset).

Trouble is, if the jimage is corrupt wrt the offsets, you cannot trust the offset, so `ImageStringReader.get(offset)` can't be trusted to be well defined.

The question you would have to ask at runtime is:
* what's the valid offset of this known string?
and not:
* what's the string at this (untrusted) offset.

The latter is just undefined if you can't trust the offset, and if you can trust the offset, you don't need to test it.
And I'd argue that if you can't trust one offset, you can't really trust any offsets and you're just broken already.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2460246042

From duke at openjdk.org  Fri Oct 24 14:24:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 24 Oct 2025 14:24:57 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v3]
In-Reply-To: <eEadIVC18QiELX5jGiX_UWe-vvYV0cFM_YzNsVSkF4A=.3c3cb92e-0f73-4a00-98ed-1689a2767151@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <rau5MZw9mVOYl6fGIgHGAVQ1sjBkuKcVTb7cwFJ9UgM=.29853cbf-2fc6-4f55-9a56-e4cab00b24db@github.com>
 <bDOeaTSG72SWQ-O8bHKI8u_iL5oiCqpbuC2FPGydbwQ=.edbde1a2-956e-4bf3-a2da-8550c7f08600@github.com>
 <eEadIVC18QiELX5jGiX_UWe-vvYV0cFM_YzNsVSkF4A=.3c3cb92e-0f73-4a00-98ed-1689a2767151@github.com>
Message-ID: <gIlrALK7FYAuqgZzLenq-Nzf9Rj3qbwKLzqFLcr1nkY=.8dcdb963-63e9-4ad9-b522-a172730e93b4@github.com>

On Wed, 8 Oct 2025 19:44:20 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 86:
>> 
>>> 84:         return new ModuleReference(moduleName, FLAGS_HAS_CONTENT | previewFlag(isPreview));
>>> 85:     }
>>> 86: 
>> 
>> Using "of" as the prefix for the method name instead of "for" would align better with many other APIs.
>
> Hmm, I've always used "ofXxx" only when the `Xxx` is part of the given input.
> 
> In this case the term "resource" isn't referring to the input, but the type of thing the reference is used for (something with content). In that situation `ofResource(<none-of-the-parameters-reference-a-resource>)` feels weird to me.
> 
> Maybe `forResourceIn(<module-name>, <flag>)` makes it clearer a resource is not being passed into the method.
> Thoughts?

I changed the methods to `forPackageIn(<modname>...)` and `forEmptyPackageIn(<modname>...)`.

`ModuleReference` sits right on the boudary of package/module stuff. It references a module, but stores flags related to the package it's associated with. As such naming here is a bit fiddly.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2460332684

From duke at openjdk.org  Fri Oct 24 14:24:59 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 24 Oct 2025 14:24:59 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v7]
In-Reply-To: <RcV9JYxCYZSDkckXnora8V0yvXkQZ9OHep0hHt-pPJM=.3fd34f9d-9c4a-4efd-8b50-fbf67a450978@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
 <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
 <RcV9JYxCYZSDkckXnora8V0yvXkQZ9OHep0hHt-pPJM=.3fd34f9d-9c4a-4efd-8b50-fbf67a450978@github.com>
Message-ID: <hRS486dLSF-4_Ah1fqTze2coRPMYDY8K1YJtHl4KJqY=.7947da8b-f399-4c23-b650-9aff5c293756@github.com>

On Wed, 22 Oct 2025 19:36:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ModuleReference.java line 120:
>> 
>>> 118:      * under many modules, it only has content in one.
>>> 119:      */
>>> 120:     public boolean hasContent() {
>> 
>> As suggested, `hasResoruces` would be consistent with the lookups for resources.
>
> Will do.

Done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2460337276

From duke at openjdk.org  Fri Oct 24 14:25:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 24 Oct 2025 14:25:00 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v6]
In-Reply-To: <9BUM_QWelFHvaTWWyoUl_WCMhm9xgkV25otkaNxlSh8=.ac1d71e1-8a34-4c13-8f7b-fb885763069e@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <w8c6fjdq8ZcO5eBQBDYm07vheuEChmr_0djvbDsEqiI=.8c2aede2-b98d-443e-b5b6-022f9b683160@github.com>
 <ZSuUtYi7N1G7KODIpQiM9ml9mkLuJ5KZwl4EKtU1Ybg=.fa3e0634-4acb-44fd-9e4b-b1281a169ecb@github.com>
 <B3NeaC3cZlfBlcPmwx1_7iQf2m1t4TQSEDWXMuIBFMk=.eaa9c5f7-cc6b-4d31-b139-4dfa94bed517@github.com>
 <U6cMchyMzg6fQsecZ3MPVVYZrDh8oB0464rQ8dcXCDk=.9c3419b1-0593-402d-aa8f-07913d543304@github.com>
 <-h3f2-ixhpzxnqUkwKlZVrZWerifLxvE8Yu-fMxLao8=.615a45ae-6291-4f5e-9c01-e213961460c0@github.com>
 <9BUM_QWelFHvaTWWyoUl_WCMhm9xgkV25otkaNxlSh8=.ac1d71e1-8a34-4c13-8f7b-fb885763069e@github.com>
Message-ID: <53f72u2YPpyaRrBfEM1_qo6RqKtQHbOZXVPpZ_8t66g=.35a92feb-f978-4462-9b2a-35612f56a555@github.com>

On Thu, 23 Oct 2025 21:03:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Oh I see what you mean. The outer API is `isPreviewOnly()` because that matches the semantics of the flags it is used to create in the parent directory (ImageLocation flags). However, as stated in the comments, the private (completely encapsulated) flag values inside the class are best defined in terms of additive flags. This is so you can merge entries easily.
>> 
>> If the inner flag was an "IS_PREVIEW_ONLY" flag, you'd have it *set* and later *cleared* when a new resource entry that *wasn't* a preview entry was processed. By making the flags "IS_XXX_VERSION", you just set them for each resource, completely independently, and then, when the references are merged, you just OR the flags together.
>> 
>> I mean I could change the public API to be talking about "has normal version", but then the code that calculates the parent directory's flags will look less clear than it does now. Instead of "parent dir is preview only if all entries are preview only" it would be "parent directory is preview only if no child entries have normal versions".
>> 
>> This is just an example of the internal working of an encapsulated class not matching its public API for technical reasons. But that's why you encapsulate things, so the inner working can do what they do best, and the outer API can be friendly to the callers.
>
> Leave it alone, maybe it will ultimately show its value.

I did remove the (single use) `hasNormalVersion()` method. It was previously also use in the sorting of entries, but that changed and left it dangling a bit. Thanks for making me look at the code again.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2460344263

From rriggs at openjdk.org  Fri Oct 24 14:52:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Oct 2025 14:52:42 GMT
Subject: [lworld] RFR: 8369921: [lworld] Remove caches of primitive wrapper
 classes [v3]
In-Reply-To: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
References: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
Message-ID: <TwLTl3FUrhuIKPpnL0qGK_YWyZBpIV1gEV2Z4606ZpQ=.8c4f83c4-91fd-45b2-925a-5cd59fc80a5d@github.com>

> Disable use of wrapper cached values when --enable-preview and add javadoc descriptions for enable-preview.
> The wrapper classes are Byte, Short, Character, Integer, and Long.

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

  One more assignment into the !Preview block in Short.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1685/files
  - new: https://git.openjdk.org/valhalla/pull/1685/files/10eab814..7a94a947

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

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

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

From fparain at openjdk.org  Fri Oct 24 15:05:07 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 24 Oct 2025 15:05:07 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v4]
In-Reply-To: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
Message-ID: <0aWk2VCrN4MKNKp8-DKC9OkEsVRUZIdGLdJZ-ju5Z7g=.29bc8bf4-ffd1-4861-be00-66b386b2f399@github.com>

> This is an alternate version of the substitutability method.
> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

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

  More fixes uggested in reviews

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1695/files
  - new: https://git.openjdk.org/valhalla/pull/1695/files/22b74040..661ffa7f

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

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

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

From fparain at openjdk.org  Fri Oct 24 15:05:13 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 24 Oct 2025 15:05:13 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
Message-ID: <tcPs5Lr3NSXWG7lIlUD29vyt_hfayrX4fIzmsULKuOA=.55902b94-d016-4054-92ef-04045b1a4808@github.com>

On Thu, 23 Oct 2025 18:04:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>>  - Add alternate version of the substitutability method
>
> src/hotspot/share/classfile/classFileParser.cpp line 5546:
> 
>> 5544:     // Current format of acmp maps:
>> 5545:     // All maps are stored contiguously in a single int array because it might
>> 5546:     // be to early to instantiate an Object array (to be investigated)
> 
> Suggestion:
> 
>     // be to early too instantiate an Object array (to be investigated)

Fixed

> src/hotspot/share/prims/unsafe.cpp line 970:
> 
>> 968: 
>> 969:   if (!k->is_inline_klass()) {
>> 970:         THROW_MSG_NULL(vmSymbols::java_lang_IllegalArgumentException(), "Argument is not a concrete value class");
> 
> Suggestion:
> 
>     THROW_MSG_NULL(vmSymbols::java_lang_IllegalArgumentException(), "Argument is not a concrete value class");

Fixed

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2460925463
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2460923613

From fparain at openjdk.org  Fri Oct 24 15:05:16 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 24 Oct 2025 15:05:16 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <9amCNaGFK3GuKNUJCWAB_-2LCurzOs6OCTDzITMR87o=.e3a43efe-986f-4545-9689-c5caaa6f3a38@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
 <9amCNaGFK3GuKNUJCWAB_-2LCurzOs6OCTDzITMR87o=.e3a43efe-986f-4545-9689-c5caaa6f3a38@github.com>
Message-ID: <pnkaj6WfRItFr94_S1y0j7HILYz8RPEJ15xk35RoVdA=.696e0e62-8be0-43ca-9acc-c0b625aad4b2@github.com>

On Thu, 23 Oct 2025 20:50:07 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/interpreter/bytecodeTracer.cpp line 95:
>> 
>>> 93:   void trace(const methodHandle& method, address bcp, uintptr_t tos, uintptr_t tos2, outputStream* st) {
>>> 94:     ResourceMark rm;
>>> 95:     ttyLocker ttyl;
>> 
>> This should be removed with [JDK-8370044](https://bugs.openjdk.org/browse/JDK-8370044)
>
> It is just a quick hack because I needed to use TraceBytecode to evaluate the new acmp.
> I'll remove it before pushing.

Removed

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2460924456

From liach at openjdk.org  Fri Oct 24 15:10:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 24 Oct 2025 15:10:30 GMT
Subject: [lworld] RFR: 8369921: [lworld] Remove caches of primitive wrapper
 classes [v3]
In-Reply-To: <TwLTl3FUrhuIKPpnL0qGK_YWyZBpIV1gEV2Z4606ZpQ=.8c4f83c4-91fd-45b2-925a-5cd59fc80a5d@github.com>
References: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
 <TwLTl3FUrhuIKPpnL0qGK_YWyZBpIV1gEV2Z4606ZpQ=.8c4f83c4-91fd-45b2-925a-5cd59fc80a5d@github.com>
Message-ID: <sKjJeFyLfeiz7V9lO-yFOsfzQgEHVAJYa9Y5A7mpga8=.82608160-90f5-4873-b957-d532c9dda636@github.com>

On Fri, 24 Oct 2025 14:52:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Disable use of wrapper cached values when --enable-preview and add javadoc descriptions for enable-preview.
>> The wrapper classes are Byte, Short, Character, Integer, and Long.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One more assignment into the !Preview block in Short.

Looks great, thanks!

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1685#pullrequestreview-3377404277

From rriggs at openjdk.org  Fri Oct 24 15:37:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Oct 2025 15:37:44 GMT
Subject: [lworld] Integrated: 8369921: [lworld] Remove caches of primitive
 wrapper classes
In-Reply-To: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
References: <xhgKDnMgkU7N5QcFjei0yMrCbIWRS3Fjv3H8gAtyftM=.c30a7118-f8fa-4b0c-bf08-7625847255d2@github.com>
Message-ID: <9FILloN44W6Ez8vz9i3hsBAhGtBlbZy-EGbkwr40qb0=.21f1e227-edd8-4c84-9000-a87443b53ecd@github.com>

On Fri, 17 Oct 2025 19:28:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Disable use of wrapper cached values when --enable-preview and add javadoc descriptions for enable-preview.
> The wrapper classes are Byte, Short, Character, Integer, and Long.

This pull request has now been integrated.

Changeset: b3ccb6ab
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b3ccb6abfdb6e2bff59a7d79bf01b669ac319257
Stats:     134 lines in 9 files changed: 83 ins; 0 del; 51 mod

8369921: [lworld] Remove caches of primitive wrapper classes

Reviewed-by: liach

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

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

From duke at openjdk.org  Fri Oct 24 17:05:58 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 24 Oct 2025 17:05:58 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v9]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <FBX9lTVmfUiXF8WKJ3HCelha85LFqbA42FIl5yW9zYo=.296882ee-f8ff-427f-9494-277713779621@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

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

  feedback changes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1619/files
  - new: https://git.openjdk.org/valhalla/pull/1619/files/5d2101c1..5445f160

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

  Stats: 43 lines in 5 files changed: 19 ins; 4 del; 20 mod
  Patch: https://git.openjdk.org/valhalla/pull/1619.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1619/head:pull/1619

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

From coleenp at openjdk.org  Fri Oct 24 17:24:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 17:24:32 GMT
Subject: [lworld] RFR: 8370509: [lworld] EnableValhalla is not needed for
 sync
In-Reply-To: <u44Zpn9Ia327px5WO35hiyriEM9XlWBE1mexYA2AlDg=.96e7b816-d0f8-4cbb-a9bd-7580ed939fb3@github.com>
References: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
 <u44Zpn9Ia327px5WO35hiyriEM9XlWBE1mexYA2AlDg=.96e7b816-d0f8-4cbb-a9bd-7580ed939fb3@github.com>
Message-ID: <Q0noy8iNpxBTGQ4uaSF9z8u-GuMWLofqBG-_sGeyPdE=.8e302b19-ddde-4e77-ade9-1e4e8c562d68@github.com>

On Fri, 24 Oct 2025 11:51:53 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> I took out EnableValhalla as a conditional test in the ObjectSynchronizer code.  If the inline type bit is set in the markWord or the klass is InlineKlass, we can't synchronize on the object.
>> I added a test but it was sort of a duplicate of all runtime/valhalla/inlinetypes/MonitorEnterTest.java and duplicates all tests that do locking so I didn't add a test.
>> Testing with tier1-4, still in progress.
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 7939:
> 
>> 7937:   orr(mark, mark, markWord::unlocked_value);
>> 7938:   // Mask inline_type bit such that we go to the slow path if object is an inline type
>> 7939:   andr(mark, mark, ~((int) markWord::inline_type_bit_in_place));
> 
> Since `EnableValhalla=true` by default, we were already exercising this path by default. 
> 
> Can we get into a situation where we do not use the object monitor table and the markword is inflated while we perform this check? We would get in trouble with this bit check if we can.

The code fetches the markWord, and tests for monitor value where an ObjectMonitor* may be installed.  It doesn't refetch the markWord from the object so that if a concurrent thread changes it, it'll always go slow path already.  Both platforms test the bit on a copy of the markWord after it's been fetched from the object and then checked for monitor_value. 
I've sort of always wondered why it's not checked at DiagnoseSyncOnValueBasedClasses but that has a load_klass which is more instructions.  This code can check the bit in the markWord instead.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1699#discussion_r2461359206

From coleenp at openjdk.org  Fri Oct 24 17:29:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 17:29:07 GMT
Subject: [lworld] RFR: 8370509: [lworld] EnableValhalla is not needed for
 sync [v2]
In-Reply-To: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
References: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
Message-ID: <RBFdARRFsh1Tnh2abs-eMck-A-gAqy3wwgl8pz_Nhxo=.d3406e29-9a02-4ddd-917d-e0bc93094388@github.com>

> I took out EnableValhalla as a conditional test in the ObjectSynchronizer code.  If the inline type bit is set in the markWord or the klass is InlineKlass, we can't synchronize on the object.
> I added a test but it was sort of a duplicate of all runtime/valhalla/inlinetypes/MonitorEnterTest.java and duplicates all tests that do locking so I didn't add a test.
> Testing with tier1-4, still in progress.

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

  More descriptive assert message for FastHashCode of value classes.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1699/files
  - new: https://git.openjdk.org/valhalla/pull/1699/files/37518d91..01b053f6

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

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

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

From coleenp at openjdk.org  Fri Oct 24 17:33:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 17:33:34 GMT
Subject: [lworld] RFR: 8370217: [lworld] Crash in
 add_migrated_value_classes after merging JDK-8350550
In-Reply-To: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
References: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
Message-ID: <kFM2BD7xcmskWzyPlt_h1EjqWANMwGmBMGT4O_DsM7U=.965b4e02-bec8-43a9-9252-cd667f3abaad@github.com>

On Thu, 23 Oct 2025 20:18:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The method add_migrated_value_classes() is being called in non-preview mode leading to an assert due to the expected classes not being present in the AOT cache. The check for `EnableValhalla` is replaced with a check for preview mode. Verified with tier 1-5 tests.

src/hotspot/share/classfile/systemDictionary.cpp line 215:

> 213:     } else {
> 214:       ClassLoaderData* cld = ClassLoaderDataGraph::find_or_create(class_loader);
> 215:       if (CDSConfig::is_valhalla_preview()) {

Since this method was refactored to not be only CDS, I think you should use Arguments::enable_preview() as the test instead of the CDS specific test.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1698#discussion_r2461390638

From coleenp at openjdk.org  Fri Oct 24 17:47:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 17:47:29 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v4]
In-Reply-To: <0aWk2VCrN4MKNKp8-DKC9OkEsVRUZIdGLdJZ-ju5Z7g=.29bc8bf4-ffd1-4861-be00-66b386b2f399@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <0aWk2VCrN4MKNKp8-DKC9OkEsVRUZIdGLdJZ-ju5Z7g=.29bc8bf4-ffd1-4861-be00-66b386b2f399@github.com>
Message-ID: <a1WVzeXxxr7uJRLG97lxsM3Ovbr4c6dksyrWH8siuls=.7ca96412-8f0d-40b1-9174-ab1df52bf740@github.com>

On Fri, 24 Oct 2025 15:05:07 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More fixes uggested in reviews

I had a couple of comments and a comment request.

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

> 5550:     //                           |               |
> 5551:     //                           --------------------- Pair of integer describing a segment of
> 5552:     //                                                 contiguous non-oop fields

Thanks for the ascii art - very helpful.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1695#pullrequestreview-3378048091
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2461398316

From coleenp at openjdk.org  Fri Oct 24 17:47:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 17:47:30 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <9amCNaGFK3GuKNUJCWAB_-2LCurzOs6OCTDzITMR87o=.e3a43efe-986f-4545-9689-c5caaa6f3a38@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
 <9amCNaGFK3GuKNUJCWAB_-2LCurzOs6OCTDzITMR87o=.e3a43efe-986f-4545-9689-c5caaa6f3a38@github.com>
Message-ID: <rincAuIbrJPsuSMnHpRHOKpg6oX3SjW9SQFuBmCl6nw=.3e35628d-e932-462d-bf95-07f4bcdc53b2@github.com>

On Thu, 23 Oct 2025 20:52:24 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1361:
>> 
>>> 1359:   _nonoop_acmp_map = new GrowableArray<Pair<int,int>>();
>>> 1360:   _oop_acmp_map = new GrowableArray<int>();
>>> 1361:   if (_is_empty_inline_class) return;
>> 
>> Why not return first before allocating these GrowableArray in resource area?
>
> It streamlines the code in InstanceKlass::fill_instance_klass() by not having to handle the null map case.

Okay. I can't decide if you need a comment to prevent someone from changing this to have the quick exit.  I guess they'll get a crash for the null case.

>> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1381:
>> 
>>> 1379:       case LayoutRawBlock::REGULAR:
>>> 1380:         {
>>> 1381:           FieldInfo* fi = _field_info->adr_at(b->field_index());
>> 
>> Is there an assumption that the block field indexes are in ascending order?
>
> I'm not sure I understand the question.
> LayoutRawBlocks represent the fields layout, they are chained in ascending offset order.
> The field_index is the index in the FieldInfo array (from the class file) where this field is declared.

Yes, that was the question.  I meant to ask if the offsets are in ascending order, so that makes the code to coalesce them simpler.  Can you add a comment at 1367 that the field offsets are in ascending order and that makes reading this easier.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2461400686
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2461413743

From fparain at openjdk.org  Fri Oct 24 19:13:56 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 24 Oct 2025 19:13:56 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v5]
In-Reply-To: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
Message-ID: <Vqw6OUDuP-k2RbS9JdKAoSKO7Cr86JYgLFDYjlUz1gs=.14ec49ff-de90-4509-acf5-b47085a2ef7a@github.com>

> This is an alternate version of the substitutability method.
> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

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

  Remove useless check

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1695/files
  - new: https://git.openjdk.org/valhalla/pull/1695/files/661ffa7f..cf456a90

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

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

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

From fparain at openjdk.org  Fri Oct 24 19:14:01 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 24 Oct 2025 19:14:01 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v2]
In-Reply-To: <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <pNPEjTfOBAlctzWBMmEjkHczKWJezwLSQV8lRIC6sms=.ea11bf64-3297-4699-b6c4-f23b9ef34785@github.com>
 <--5Oj_KaLyy0_D9ilqkmRBUatM-ULP8UbgpNiHIi58c=.31bd4109-42b2-45b0-9b8d-622c4d7cdbda@github.com>
Message-ID: <AizjJ8u4iNlzJiBFbAFNwZAyb--LF2MJ_3TfbF8ixYs=.181dcd89-6d99-4d12-834a-ab8916097b78@github.com>

On Thu, 23 Oct 2025 20:26:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>>  - Add alternate version of the substitutability method
>
> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1303:
> 
>> 1301:   int start = map->adr_at(last_idx)->first > offset ? 0 : last_idx;
>> 1302:   bool inserted = false;
>> 1303:   for (int c = start; c < map->length() && !inserted ; c++) {
> 
> You don't need to check inserted in this for loop because you have breaks, if I'm reading this right.

Correct. It's a remain of a previous version where there was two nested loops and break couldn't be used.
Fixed

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2461709179

From amenkov at openjdk.org  Sat Oct 25 00:48:03 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 25 Oct 2025 00:48:03 GMT
Subject: [lworld] RFR: 8367711: [lworld] JDI test updates
In-Reply-To: <7IB6ODxOTYQy_u-Hjf-hNAEIqLCwsElPuH9UPKoFT-0=.86147cf3-e35a-4ac9-9e57-8939c5ee92b1@github.com>
References: <7IB6ODxOTYQy_u-Hjf-hNAEIqLCwsElPuH9UPKoFT-0=.86147cf3-e35a-4ac9-9e57-8939c5ee92b1@github.com>
Message-ID: <OcHt4Q-uhgrHo3Evx0NDOFQEV2g3XoMLp0tko4fOAx0=.c1c488ac-f1f2-45eb-adc0-9bab29c002b0@github.com>

On Sat, 25 Oct 2025 00:42:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Update for JDI tests.
> This is follow up for [1519](https://github.com/openjdk/valhalla/pull/1519) (feedback was added after integration)

@plummercj Could you please take a look - maybe you have some other comments

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

PR Comment: https://git.openjdk.org/valhalla/pull/1702#issuecomment-3445377710

From amenkov at openjdk.org  Sat Oct 25 00:48:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 25 Oct 2025 00:48:02 GMT
Subject: [lworld] RFR: 8367711: [lworld] JDI test updates
Message-ID: <7IB6ODxOTYQy_u-Hjf-hNAEIqLCwsElPuH9UPKoFT-0=.86147cf3-e35a-4ac9-9e57-8939c5ee92b1@github.com>

Update for JDI tests.
This is follow up for [1519](https://github.com/openjdk/valhalla/pull/1519) (feedback was added after integration)

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

Commit messages:
 - jdi tests

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

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

From dsimms at openjdk.org  Sat Oct 25 05:56:39 2025
From: dsimms at openjdk.org (David Simms)
Date: Sat, 25 Oct 2025 05:56:39 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <BieWCKj9ygKJrwRatYZR3STxTVDMQPbQiLLmZSeKYDI=.ba5d8fcc-bfc1-49e1-8d8c-2078ff7f7dd6@github.com>
References: <BieWCKj9ygKJrwRatYZR3STxTVDMQPbQiLLmZSeKYDI=.ba5d8fcc-bfc1-49e1-8d8c-2078ff7f7dd6@github.com>
Message-ID: <sxMhy6DxLVSG9rKKhfMi9KwjYrVMnj1rCyu5mn95uJE=.f7c18616-f43b-44db-acf5-11fd5b6360a3@github.com>

On Thu, 23 Oct 2025 09:10:00 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+19

This pull request has now been integrated.

Changeset: c447cf3c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c447cf3c6bdbad73d4a7e6d4b8b532657b2e1443
Stats:     13114 lines in 507 files changed: 8339 ins; 2510 del; 2265 mod

Merge jdk

Merge jdk-26+19

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

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

From ethan at mccue.dev  Sun Oct 26 03:12:41 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 25 Oct 2025 23:12:41 -0400
Subject: Calling instance method from value class constructor is a little
 confusing
Message-ID: <CA+NR86jFbdHKcgJaugvmEQ=C2xGqnRtiv6nzcGXMgXGSa1JFEQ@mail.gmail.com>

Just a note from playing with the EA build. Minimal example:

import java.util.ArrayList;

value class HittableList2 {
    private final ArrayList<Object> objects
            = new ArrayList<>();

    HittableList2() {}

    HittableList2(Object object) {
        add(object);
    }

    void add(Object object) {
        objects.add(object);
    }
}

This gives the error

/Users/emccue/Development/raytracer/src/HittableList2.java:10: error:
cannot reference add(Object) before constructor has been called
        add(object);
        ^

I know this means the superclass's constructor (and that I need to put an
explicit super() at the top of the method), but reading that straight
"cannot reference ... before constructor has been called - I'm in the
constructor!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251025/3028b1c8/attachment.htm>

From joemwangimburu at gmail.com  Sun Oct 26 13:30:52 2025
From: joemwangimburu at gmail.com (Joe Mwangi)
Date: Sun, 26 Oct 2025 16:30:52 +0300
Subject: Observations and Questions on Flattening Behavior and Memory
 Alignment in Value Objects
Message-ID: <CANRu=4gX+JbfzfdcRV8Ghhy4YmE3X0w79GsYyp+Ym82yP+FZEA@mail.gmail.com>

Hi Valhalla Development Team,

Thank you for providing the latest build for testing progress on value
objects in the JVM. I?ve been running a few experiments to understand the
behavior of custom value types and their memory characteristics, and I must
say I?m very impressed by the implementation so far. Memory usage appears
significantly reduced in many cases (sometimes to nearly ? of the original).

Here?s a simple test I used:

public class ValhallaTest {
    value record PointRecord(short x, short y, short z) {}

    void main() throws InterruptedException {
        Thread.sleep(9000); // allow time to attach VisualVM
        System.out.println("Starting");
        int size = 10_000_000;
        var pointRecords = new PointRecord[size];
        for (int i = 0; i < size; i++) {
            pointRecords[i] = new PointRecord((short) 2, (short) 2, (short) 3);
        }
        Thread.sleep(20000);
    }
}

Using VisualVM, I inspected live objects and heap usage, with the following
observations:

   1.

   No individual PointRecord objects were detected ? only the PointRecord[]
   array, confirming full flattening (no identity objects).
   2.

   PointRecord(short, short, short) logically occupies 6 bytes, but the
   array reports *80 000 000 B* for 10 M elements ? 8 bytes per element,
   suggesting alignment to 64 bits.
   3.

   PointRecord(short x, short y) ? *40 000 000 B* ? 4 bytes per element.
   4.

   PointRecord(byte x) ? *20 000 000 B* ? 2 bytes per element.

It appears the prototype aligns flattened array elements to the smallest
power of two ? the logical size (not just 4-byte boundaries). Beyond 64
bits (? 8 bytes), flattening seems to stop, possibly reverting to identity
semantics, which makes sense given mutation and tearing concerns.

A few questions came up from these results:

   1.

   Will arrays need to be immutable to guarantee flattening for value
   elements larger than 64 bits? Think about parsing large files, where a
   large array with larger sized value object will be important, hence mutable
   array being key, and then do simd parsing.
   2.

   Since value objects are scalarized across stack calls, will there be
   tooling to analyze whether scalarization actually occurs (e.g.,
   register-based limits determined by the JVM, if not enough register space,
   value object gains identity)?
   3.

   In C, struct size can be predicted from field types. For Java value
   objects, since layout is JVM-dependent, is there a plan for tooling
   (perhaps jcmd or JFR integration) to expose explicit size/layout
   information beyond array inspection? The default above example shows that a
   6 bytes size value object is actually 8 bytes, but in C, it shall remain 6
   byte size.

Overall, this is very exciting work. The model feels both efficient and
semantically robust, offering a fresh take compared to languages that rely
on purely compile-time memory determinism. I?ll continue exploring
performance and GC interaction aspects later, but even this preliminary
testing shows remarkable promise.

Thanks again to the entire team for the great work.

Kind regards,
*Joe Mwangi*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251026/b34e1654/attachment-0001.htm>

From forax at univ-mlv.fr  Sun Oct 26 14:38:17 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 26 Oct 2025 15:38:17 +0100 (CET)
Subject: Observations and Questions on Flattening Behavior and Memory
 Alignment in Value Objects
In-Reply-To: <CANRu=4gX+JbfzfdcRV8Ghhy4YmE3X0w79GsYyp+Ym82yP+FZEA@mail.gmail.com>
References: <CANRu=4gX+JbfzfdcRV8Ghhy4YmE3X0w79GsYyp+Ym82yP+FZEA@mail.gmail.com>
Message-ID: <1867135675.24347867.1761489497222.JavaMail.zimbra@univ-eiffel.fr>

> From: "Joe Mwangi" <joemwangimburu at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Sunday, October 26, 2025 2:30:52 PM
> Subject: Observations and Questions on Flattening Behavior and Memory Alignment
> in Value Objects

> Hi Valhalla Development Team,

Hello Joe, 
i'm not part of the implementation team (i'm part of the spec team), but i can answer to some of your questions, 

> Thank you for providing the latest build for testing progress on value objects
> in the JVM. I?ve been running a few experiments to understand the behavior of
> custom value types and their memory characteristics, and I must say I?m very
> impressed by the implementation so far. Memory usage appears significantly
> reduced in many cases (sometimes to nearly ? of the original).

> Here?s a simple test I used:
> public class ValhallaTest { value record PointRecord ( short x, short y, short
> z) {} void main () throws InterruptedException { Thread.sleep( 9000 ); // allow
> time to attach VisualVM System.out.println( "Starting" ); int size = 10_000_000
> ; var pointRecords = new PointRecord [size]; for ( int i = 0 ; i < size; i++) {
> pointRecords[i] = new PointRecord (( short ) 2 , ( short ) 2 , ( short ) 3 ); }
> Thread.sleep( 20000 ); } }

> Using VisualVM, I inspected live objects and heap usage, with the following
> observations:

>     1.

> No individual PointRecord objects were detected ? only the PointRecord[] array,
> confirming full flattening (no identity objects).
>     2.

> PointRecord(short, short, short) logically occupies 6 bytes, but the array
> reports 80 000 000 B for 10 M elements ? 8 bytes per element, suggesting
> alignment to 64 bits.

it's short + short + short + byte (for null) + alignment, hence 64 bits. 

    1. 

PointRecord(short x, short y) ? 40 000 000 B ? 4 bytes per element. 
    2. 

PointRecord(byte x) ? 20 000 000 B ? 2 bytes per element. 

> It appears the prototype aligns flattened array elements to the smallest power of two ? the logical size (not just 4-byte boundaries). Beyond 64 bits (? 8 bytes), flattening seems to stop, possibly reverting to identity semantics, which makes sense given mutation and tearing concerns. 

So it's more than you need to add a bit (a byte) representing null and then it has to be a power of two (alignment) because you want to read the location in one read/write to avoid tearing. 

> A few questions came up from these results: 

    1. 

Will arrays need to be immutable to guarantee flattening for value elements larger than 64 bits? Think about parsing large files, where a large array with larger sized value object will be important, hence mutable array being key, and then do simd parsing. 

The array needs to have non-null elements, and you need a way to opt-out of atomicity (allow tearing). 
The exact way to do the latter is still in flux. 

About using simd, there is an issue because you can read/write using simd but then you need to extract the value from the simd register to a general purpose register and this is actually quite slow, 
so the Hotspot does not do that. 

>     1.
>     2.

> Since value objects are scalarized across stack calls, will there be tooling to
> analyze whether scalarization actually occurs (e.g., register-based limits
> determined by the JVM, if not enough register space, value object gains
> identity)?

as far as i know, c2 (the only JIT that optimize value classes) will scalarize depending on the size of the instance but not depending on if you have not enough registers, the registers will be spilled on stack in that case. 

>     1.
>     2.

> In C, struct size can be predicted from field types. For Java value objects,
> since layout is JVM-dependent, is there a plan for tooling (perhaps jcmd or JFR
> integration) to expose explicit size/layout information beyond array
> inspection? The default above example shows that a 6 bytes size value object is
> actually 8 bytes, but in C, it shall remain 6 byte size.

you can use -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlineLayout but it only works for fields, not for arrays. 

> Overall, this is very exciting work. The model feels both efficient and
> semantically robust, offering a fresh take compared to languages that rely on
> purely compile-time memory determinism. I?ll continue exploring performance and
> GC interaction aspects later, but even this preliminary testing shows
> remarkable promise.

> Thanks again to the entire team for the great work.

> Kind regards,
> Joe Mwangi

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

From joemwangimburu at gmail.com  Sun Oct 26 21:47:38 2025
From: joemwangimburu at gmail.com (Joe Mwangi)
Date: Mon, 27 Oct 2025 00:47:38 +0300
Subject: Observations and Questions on Flattening Behavior and Memory
 Alignment in Value Objects
In-Reply-To: <1867135675.24347867.1761489497222.JavaMail.zimbra@univ-eiffel.fr>
References: <CANRu=4gX+JbfzfdcRV8Ghhy4YmE3X0w79GsYyp+Ym82yP+FZEA@mail.gmail.com>
 <1867135675.24347867.1761489497222.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CANRu=4gxUn9mjxN+Z0Nw=djtkpPAXG3huvMpL-WD0y+XVqtHDA@mail.gmail.com>

Dear R?mi,

Thanks so much for the detailed reply and for clarifying some of my
questions. Also, the -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlineLayout
seems quite useful. It also shows layout has reserved space at the
beginning, presumably when identity is required and lack of it if
flattening happens (I guess, but still useful information). I wasn't aware
null is embedded too. Was wondering why if a value object has an exact 32
bits (an int, e.g. new PointRecord(int x)), it's actual size is 64. The
additional null marker makes sense why. Also, it seems null-restriction
means better memory optimisation. I'll keep doing more test to learn more.

Regards

On Sun, 26 Oct 2025 at 17:38, Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Joe Mwangi" <joemwangimburu at gmail.com>
> *To: *"valhalla-dev" <valhalla-dev at openjdk.org>
> *Sent: *Sunday, October 26, 2025 2:30:52 PM
> *Subject: *Observations and Questions on Flattening Behavior and Memory
> Alignment in Value Objects
>
> Hi Valhalla Development Team,
>
>
> Hello Joe,
> i'm not part of the implementation team (i'm part of the spec team), but i
> can answer to some of your questions,
>
> Thank you for providing the latest build for testing progress on value
> objects in the JVM. I?ve been running a few experiments to understand the
> behavior of custom value types and their memory characteristics, and I must
> say I?m very impressed by the implementation so far. Memory usage appears
> significantly reduced in many cases (sometimes to nearly ? of the original).
>
> Here?s a simple test I used:
> public class ValhallaTest { value record PointRecord(short x, short y,
> short z) {} void main() throws InterruptedException { Thread.sleep(9000); //
> allow time to attach VisualVM System.out.println("Starting"); int size =
> 10_000_000; var pointRecords = new PointRecord[size]; for (int i = 0; i <
> size; i++) { pointRecords[i] = new PointRecord((short) 2, (short) 2, (
> short) 3); } Thread.sleep(20000); } }
>
> Using VisualVM, I inspected live objects and heap usage, with the
> following observations:
>
>    1.
>
>    No individual PointRecord objects were detected ? only the
>    PointRecord[] array, confirming full flattening (no identity objects).
>    2.
>
>    PointRecord(short, short, short) logically occupies 6 bytes, but the
>    array reports *80 000 000 B* for 10 M elements ? 8 bytes per element,
>    suggesting alignment to 64 bits.
>
>
>
> it's short + short + short + byte (for null) + alignment, hence 64 bits.
>
>
>    1.
>
>    PointRecord(short x, short y) ? *40 000 000 B* ? 4 bytes per element.
>    2.
>
>    PointRecord(byte x) ? *20 000 000 B* ? 2 bytes per element.
>
> > It appears the prototype aligns flattened array elements to the smallest
> power of two ? the logical size (not just 4-byte boundaries). Beyond 64
> bits (? 8 bytes), flattening seems to stop, possibly reverting to identity
> semantics, which makes sense given mutation and tearing concerns.
>
> So it's more than you need to add a bit (a byte) representing null and
> then it has to be a power of two (alignment) because you want to read the
> location in one read/write to avoid tearing.
>
>
> > A few questions came up from these results:
>
>    1.
>
>    Will arrays need to be immutable to guarantee flattening for value
>    elements larger than 64 bits? Think about parsing large files, where a
>    large array with larger sized value object will be important, hence mutable
>    array being key, and then do simd parsing.
>
>
> The array needs to have non-null elements, and you need a way to opt-out
> of atomicity (allow tearing).
> The exact way to do the latter is still in flux.
>
> About using simd, there is an issue because you can read/write using simd
> but then you need to extract the value from the simd register to a general
> purpose register and this is actually quite slow,
> so the Hotspot does not do that.
>
>
>    1.
>    2.
>
>    Since value objects are scalarized across stack calls, will there be
>    tooling to analyze whether scalarization actually occurs (e.g.,
>    register-based limits determined by the JVM, if not enough register space,
>    value object gains identity)?
>
>
> as far as i know, c2 (the only JIT that optimize value classes) will
> scalarize depending on the size of the instance but not depending on if you
> have not enough registers, the registers will be spilled on stack in that
> case.
>
>
>    1.
>    2.
>
>    In C, struct size can be predicted from field types. For Java value
>    objects, since layout is JVM-dependent, is there a plan for tooling
>    (perhaps jcmd or JFR integration) to expose explicit size/layout
>    information beyond array inspection? The default above example shows that a
>    6 bytes size value object is actually 8 bytes, but in C, it shall remain 6
>    byte size.
>
>
> you can use -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlineLayout but it
> only works for fields, not for arrays.
>
> Overall, this is very exciting work. The model feels both efficient and
> semantically robust, offering a fresh take compared to languages that rely
> on purely compile-time memory determinism. I?ll continue exploring
> performance and GC interaction aspects later, but even this preliminary
> testing shows remarkable promise.
>
> Thanks again to the entire team for the great work.
>
> Kind regards,
> *Joe Mwangi*
>
>
> regards,
> R?mi
>
>

-- 
Joe Mwangi
Principal Scientist
Nuclear Power and Energy Agency (NuPEA)

Tel:          : +254701378543
Twitter      : https://twitter.com/JoeMwangiMburu
Facebook : https://www.facebook.com/joemwangimburu
LinkedIn   : http://www.linkedin.com/in/joemwangimburu
NuPEA    : http://www.nuclear.co.ke/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251027/38956f6b/attachment-0001.htm>

From dsimms at openjdk.org  Mon Oct 27 10:14:25 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 27 Oct 2025 10:14:25 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <4x6V6XuZNbQdOF1uWkr96R-kGzx9B_5kh7w50HGayQE=.312b51b5-c6ab-4f17-8802-aefa23fa8109@github.com>

Merge tag 'jdk-26+20' into lworld_merge_jdk_26_20

Added tag jdk-26+20 for changeset b5b83247

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

Commit messages:
 - Merge jdk
 - 8369656: Calling CompletableFuture.join() could execute task in common pool
 - 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug
 - 8369258: C2: enable ReassociateInvariants for all loop types
 - 8365609: Fix several potential NULL native pointer dereferences in the desktop module
 - 8369167: C2: refactor LShiftINode/LShiftLNode Value/Identity/Ideal
 - 8369881: C2: Unexpected node in SuperWord truncation: ReverseBytesS, ReverseBytesUS
 - 8357809: Test jdk/jshell/JdiListeningExecutionControlTest.java failed with com.sun.jdi.connect.TransportTimeoutException
 - 8368940: Missing ResourceMark when stalling for shutdown
 - 8369251: Opensource few tests
 - ... and 98 more: https://git.openjdk.org/valhalla/compare/c447cf3c...c937a38d

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

Changes: https://git.openjdk.org/valhalla/pull/1703/files
  Stats: 19009 lines in 404 files changed: 11702 ins; 6259 del; 1048 mod
  Patch: https://git.openjdk.org/valhalla/pull/1703.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1703/head:pull/1703

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

From dsimms at openjdk.org  Mon Oct 27 11:13:45 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 27 Oct 2025 11:13:45 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <4x6V6XuZNbQdOF1uWkr96R-kGzx9B_5kh7w50HGayQE=.312b51b5-c6ab-4f17-8802-aefa23fa8109@github.com>
References: <4x6V6XuZNbQdOF1uWkr96R-kGzx9B_5kh7w50HGayQE=.312b51b5-c6ab-4f17-8802-aefa23fa8109@github.com>
Message-ID: <mkbHmGmvOdAUd2KeI3Cq74N365Z4ng5MkUF7YHIp3dA=.a9087380-d60a-40a4-a2ee-ec06bdfc727e@github.com>

On Mon, 27 Oct 2025 10:07:04 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+20' into lworld_merge_jdk_26_20
> 
> Added tag jdk-26+20 for changeset b5b83247

This pull request has now been integrated.

Changeset: 612168ef
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/612168ef780cc06071d6f95c3416f6a7bda788d6
Stats:     19009 lines in 404 files changed: 11702 ins; 6259 del; 1048 mod

Merge jdk

Merge jdk-26+20

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

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

From duke at openjdk.org  Mon Oct 27 11:20:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 27 Oct 2025 11:20:02 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v7]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <iRXc76bfugjfFgeQNY1sO7ED6P8da1uwuzZtWwEcsAw=.0849b0c8-ba2c-4c4f-92bc-852c22ee987c@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - General tidying after resync.
   
   * tweaking tests for readability
   * Fixing up after dependent PR changes
 - Resquashing after sync.
   
   * feedback and remove unused code
   * new tests for ImageLocation
   * Restoring lost changes and updating some comments.
   * add system property guard to preview mode
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Merge branch 'jdk_8368333_java/squashed' into jdk_8368467_reader/squashed
 - Rolled up changes after rebase.
   
   * Removing package root flag based on feedback.
   * Changing existing package flags during writing to match altered flag values.
   * Feedback changes, and fixing some comments.
   * Renaming slightly confusing "testEncoder" method.
   * Fixing unit tests to use new constructor.
   * Word smithing flags definitions.
   * Add workaround until new image writing code is in
   * Clarifying flag docs for /packages/xxx case
   * Java ImageReader changes for preview mode
 - Merge branch 'jdk_8366093_cpp/squashed' into jdk_8368333_java/squashed
 - Reorganising to catch preview-only cases
 - [[RESET BRANCH FOR MERGE]]
 - [[RESET BRANCH FOR MERGE]]
 - feedback and remove unused code
 - Resync after dependent PR change.
   
   * new tests for ImageLocation
   * Restoring lost changes and updating some comments.
   * add system property guard to preview mode
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - ... and 15 more: https://git.openjdk.org/valhalla/compare/b22f6a47...86d1c928

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

Changes: https://git.openjdk.org/valhalla/pull/1621/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=06
  Stats: 3844 lines in 35 files changed: 2234 ins; 405 del; 1205 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

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

From duke at openjdk.org  Mon Oct 27 11:31:23 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 27 Oct 2025 11:31:23 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v8]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <DXl23FCFL_RUbMYng1PEZ3zRAUVqd6kKdOYB735At70=.fe03e2ff-ac7e-4f6a-900c-4431e9c578d3@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'lworld' into jdk_8368467_reader/squashed
 - General tidying after resync.
   
   * tweaking tests for readability
   * Fixing up after dependent PR changes
 - Resquashing after sync.
   
   * feedback and remove unused code
   * new tests for ImageLocation
   * Restoring lost changes and updating some comments.
   * add system property guard to preview mode
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.
 - Merge branch 'jdk_8368333_java/squashed' into jdk_8368467_reader/squashed
 - Rolled up changes after rebase.
   
   * Removing package root flag based on feedback.
   * Changing existing package flags during writing to match altered flag values.
   * Feedback changes, and fixing some comments.
   * Renaming slightly confusing "testEncoder" method.
   * Fixing unit tests to use new constructor.
   * Word smithing flags definitions.
   * Add workaround until new image writing code is in
   * Clarifying flag docs for /packages/xxx case
   * Java ImageReader changes for preview mode
 - Merge branch 'jdk_8366093_cpp/squashed' into jdk_8368333_java/squashed
 - Reorganising to catch preview-only cases
 - [[RESET BRANCH FOR MERGE]]
 - [[RESET BRANCH FOR MERGE]]
 - feedback and remove unused code
 - ... and 16 more: https://git.openjdk.org/valhalla/compare/7257a072...35b3c2a3

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

Changes: https://git.openjdk.org/valhalla/pull/1621/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=07
  Stats: 3524 lines in 27 files changed: 2024 ins; 355 del; 1145 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

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

From lois.foltan at oracle.com  Mon Oct 27 12:42:23 2025
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 27 Oct 2025 12:42:23 +0000
Subject: Calling instance method from value class constructor is a little
 confusing
In-Reply-To: <CA+NR86jFbdHKcgJaugvmEQ=C2xGqnRtiv6nzcGXMgXGSa1JFEQ@mail.gmail.com>
References: <CA+NR86jFbdHKcgJaugvmEQ=C2xGqnRtiv6nzcGXMgXGSa1JFEQ@mail.gmail.com>
Message-ID: <BLAPR10MB5156BF6B5C1D204DDBC327AA8AFCA@BLAPR10MB5156.namprd10.prod.outlook.com>

Hi Ethan,

Thanks for your feedback!  I?ve created JBS issue https://bugs.openjdk.org/browse/JDK-8370687 to track improving this error message.

Lois



Confidential ? Oracle Internal
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Ethan McCue <ethan at mccue.dev>
Date: Saturday, October 25, 2025 at 11:13?PM
To: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Subject: Calling instance method from value class constructor is a little confusing
Just a note from playing with the EA build. Minimal example:

import java.util.ArrayList;

value class HittableList2 {
    private final ArrayList<Object> objects
            = new ArrayList<>();

    HittableList2() {}

    HittableList2(Object object) {
        add(object);
    }

    void add(Object object) {
        objects.add(object);
    }
}

This gives the error

/Users/emccue/Development/raytracer/src/HittableList2.java:10: error: cannot reference add(Object) before constructor has been called
        add(object);
        ^

I know this means the superclass's constructor (and that I need to put an explicit super() at the top of the method), but reading that straight "cannot reference ... before constructor has been called - I'm in the constructor!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251027/df9d3c12/attachment.htm>

From duke at openjdk.org  Mon Oct 27 12:55:36 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 27 Oct 2025 12:55:36 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v9]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <V24DOirrLz9al1hsBbM3l0WKuZn01TIJv4Q_Xl_05WE=.bee8c7bd-3645-4a6d-bde2-092a3917dd1f@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Rollup after resync of dependent PR.
  
  * Fixing up after dependent PR changes
  * feedback and remove unused code
  * new tests for ImageLocation
  * Restoring lost changes and updating some comments.
  * add system property guard to preview mode
  * Remove TODOs now jimage version is bumped
  * jimage writer changes to support preview mode.

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

Changes: https://git.openjdk.org/valhalla/pull/1621/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=08
  Stats: 2050 lines in 14 files changed: 892 ins; 155 del; 1003 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

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

From phubner at openjdk.org  Mon Oct 27 13:05:05 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 27 Oct 2025 13:05:05 GMT
Subject: [lworld] RFR: 8370509: [lworld] EnableValhalla is not needed for
 sync [v2]
In-Reply-To: <RBFdARRFsh1Tnh2abs-eMck-A-gAqy3wwgl8pz_Nhxo=.d3406e29-9a02-4ddd-917d-e0bc93094388@github.com>
References: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
 <RBFdARRFsh1Tnh2abs-eMck-A-gAqy3wwgl8pz_Nhxo=.d3406e29-9a02-4ddd-917d-e0bc93094388@github.com>
Message-ID: <d5MTFuMnksege3zPgD2uSpz0p9tBnJ2jqlCFzZheiYE=.ac541971-b72b-4589-ba5b-6efffba3cde5@github.com>

On Fri, 24 Oct 2025 17:29:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I took out EnableValhalla as a conditional test in the ObjectSynchronizer code.  If the inline type bit is set in the markWord or the klass is InlineKlass, we can't synchronize on the object.
>> I added a test but it was sort of a duplicate of all runtime/valhalla/inlinetypes/MonitorEnterTest.java and duplicates all tests that do locking so I didn't add a test.
>> Testing with tier1-4, still in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More descriptive assert message for FastHashCode of value classes.

Marked as reviewed by phubner (Author).

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

PR Review: https://git.openjdk.org/valhalla/pull/1699#pullrequestreview-3383371910

From fparain at openjdk.org  Mon Oct 27 13:22:48 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 27 Oct 2025 13:22:48 GMT
Subject: [lworld] RFR: 8370509: [lworld] EnableValhalla is not needed for
 sync [v2]
In-Reply-To: <RBFdARRFsh1Tnh2abs-eMck-A-gAqy3wwgl8pz_Nhxo=.d3406e29-9a02-4ddd-917d-e0bc93094388@github.com>
References: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
 <RBFdARRFsh1Tnh2abs-eMck-A-gAqy3wwgl8pz_Nhxo=.d3406e29-9a02-4ddd-917d-e0bc93094388@github.com>
Message-ID: <3GMvUKnzqbWfU2RPnUYgJSAyjDraCxY_KN5fxf542hQ=.2df1b446-e53a-4325-8e4d-e96425a6a69c@github.com>

On Fri, 24 Oct 2025 17:29:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I took out EnableValhalla as a conditional test in the ObjectSynchronizer code.  If the inline type bit is set in the markWord or the klass is InlineKlass, we can't synchronize on the object.
>> I added a test but it was sort of a duplicate of all runtime/valhalla/inlinetypes/MonitorEnterTest.java and duplicates all tests that do locking so I didn't add a test.
>> Testing with tier1-4, still in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More descriptive assert message for FastHashCode of value classes.

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1699#pullrequestreview-3383459639

From fparain at openjdk.org  Mon Oct 27 13:24:44 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 27 Oct 2025 13:24:44 GMT
Subject: [lworld] RFR: 8314996: [lworld]
 java/lang/Thread/virtual/stress/PingPong.java fails since jdk-22+8
In-Reply-To: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>
References: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>
Message-ID: <dAsLR9YLJnXDJl2nogi3jSpRn69W87tRCEVcKCOx1sY=.b8e1a281-846c-4b41-af4f-7bb6250ec847@github.com>

On Fri, 3 Oct 2025 14:54:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> When running with JTREG_REPEAT_COUNT=1000 I get the same error as skynet in [JDK-8342977](https://bugs.openjdk.org/browse/JDK-8342977), so I'm using that number for the ProblemList-Virtual.txt. This fails intermittently without JTREG_TEST_THREAD_FACTORY=Virtual, so maybe this belongs in ProblemList.txt instead, as well as Skynet.

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1657#pullrequestreview-3383470878

From dsimms at openjdk.org  Mon Oct 27 14:57:12 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 27 Oct 2025 14:57:12 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <E9Fkeap5uAolRcFzDXtpe59dASuNwpW7FpkuFHmyS2I=.52d175b7-0220-458c-884a-61000c75d984@github.com>

Merge jdk-26+21

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

Commit messages:
 - Further 8365722 problem listed
 - Merge jdk
 - 8370156: Fix jpackage IconTest
 - 8064922: [macos] Test javax/swing/JTabbedPane/4624207/bug4624207.java fails
 - 8367002: Missing compiled exception handler for "recursive" exception
 - 8359472: JVM crashes when attaching a dynamic agent before JVMTI_PHASE_LIVE
 - 8359057: AbstractInterpreter::is_not_reached returns incorrectly with invokedynamic
 - 8367008: Algorithm identifiers for HmacSHA* should always have NULL as params
 - 8370377: Avoid resolving constant pool entries during preimage generation in the training run
 - 8370442: Compilation error in jpackage EntitlementsTest test
 - ... and 107 more: https://git.openjdk.org/valhalla/compare/612168ef...b15d2e2d

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

Changes: https://git.openjdk.org/valhalla/pull/1704/files
  Stats: 17104 lines in 500 files changed: 10241 ins; 3427 del; 3436 mod
  Patch: https://git.openjdk.org/valhalla/pull/1704.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1704/head:pull/1704

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

From liach at openjdk.org  Mon Oct 27 15:25:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Oct 2025 15:25:54 GMT
Subject: [lworld] RFR: 8370687: [lworld] Improve before constructor has been
 called error message
Message-ID: <VxBE_8ALpU33-5C9Qf8HEXZ6taO21FA4hGjAQu-JOQQ=.f926301f-105c-45b6-9783-c8a7e239fd9a@github.com>

Now we have an early construction by default mode on for value classes, where post-super calls requires explicit constructor invocation. We can tweak the messages slightly to accomplish this.

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

Commit messages:
 - 8370687: [lworld] Improve before constructor has been called error message

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

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

From dsimms at openjdk.org  Mon Oct 27 15:40:08 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 27 Oct 2025 15:40:08 GMT
Subject: [lworld] RFR: Not intended for checkin
Message-ID: <rEBn52jSn2JvCSV3e5f0jJviGdlnJdG4jOdwUH-QHpA=.e027e96f-cde3-4ce1-bb42-1abb44c1e251@github.com>

Just a test

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

Commit messages:
 - Not intended for checkin

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

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

From duke at openjdk.org  Mon Oct 27 15:43:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 27 Oct 2025 15:43:12 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v9]
In-Reply-To: <V24DOirrLz9al1hsBbM3l0WKuZn01TIJv4Q_Xl_05WE=.bee8c7bd-3645-4a6d-bde2-092a3917dd1f@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
 <V24DOirrLz9al1hsBbM3l0WKuZn01TIJv4Q_Xl_05WE=.bee8c7bd-3645-4a6d-bde2-092a3917dd1f@github.com>
Message-ID: <iSfdXb8gaGw6hYLdzaR7l0P2EpTy7cWZ3z8S-z2wslY=.91159d03-ef50-447c-8db8-0a0c789e05d1@github.com>

On Mon, 27 Oct 2025 12:55:36 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>> 
>> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Rollup after resync of dependent PR.
>   
>   * Fixing up after dependent PR changes
>   * feedback and remove unused code
>   * new tests for ImageLocation
>   * Restoring lost changes and updating some comments.
>   * add system property guard to preview mode
>   * Remove TODOs now jimage version is bumped
>   * jimage writer changes to support preview mode.

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

> 204:                 } catch (InvalidTreeException err) {
> 205:                     // It has been observed some badly created jar file to contain
> 206:                     // invalid directory entry marked as not directory (see 8131762).

I'm not 100% sure of the value of retaining stderr logging like this, especially if the code continues after ignoring the input, but it's the same behaviour as before, so I'm leaving it as-is.

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

> 259:             // Intermediate packages are marked "empty" (no resources). This might
> 260:             // later be merged with a non-empty reference for the same package.
> 261:             ModuleReference emptyRef = ModuleReference.forEmptyPackageIn(modName, isPreviewPath);

This convinces me that `forEmptyPackageIn` is a better name than `forEmptyPackage`, since the passing of the module name as the first parameter no longer raises eyebrows.

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

> 274:                 ModuleReference resourceRef = ModuleReference.forPackageIn(modName, isPreviewPath);
> 275:                 packageToModules.computeIfAbsent(fullPkgName, p -> new HashSet<>()).add(resourceRef);
> 276:                 // Init adds new node to parent (don't add resources to directAccess).

I'd be happy to rename the `directAccess` field. It's really a holder for directories. The fact it's "direct access" is rather a statement of its form (obvious since it's a map really) and not its function.
Thoughts?

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

> 293:         }
> 294: 
> 295:         // Helper to iterate package names up to, and including, the complete name.

If this comment isn't clear enough I can elaborate. Basically lets you iterate indices in "foo.bar.baz" as `3, 7, 11, -1` (including an index at the end of the string before it returns `-1`). This is just here to make the for-loop cleaner where the real business logic is.

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

> 309:         }
> 310: 
> 311:         private String removeRadical(Node node) {

I don't think this method obviously earns its keep, so would be happy to inline it, perhaps with a string constant. But also happy to leave it.

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

> 414:                         // A resource location, remove "/modules"
> 415:                         String s = tree.toResourceName(current);
> 416:                         current.setLocation(outLocations.get(s));

Calling this via the method adds a check that nothing is being overwritten.

test/jdk/jdk/internal/jimage/ImageLocationTest.java line 89:

> 87:     }
> 88: 
> 89:     @Test

The `getPackageFlags` tests check that module references get merged correctly to create the parent directory flags we expect. While adding individual resources you build up a *list* of references in each package, one for each resource (directly or indirectly) in that package.
This is a key reason for how the new code can simplify things around the outer "add each resource in turn" loop, by just collecting the references and merging them later to get the right result.

test/jdk/jdk/internal/jimage/ImageLocationTest.java line 119:

> 117:                 ModuleReference.forEmptyPackage("modbaz", true));
> 118:         int previewOnlyFlags = ImageLocation.getPackageFlags(refs);
> 119:         // Note the asymmetry between this and the getFlags() case. Unlike

This is a flag combination you can't see for locations in `/modules`, because "has-preview-version" there means "is-not-a-preview-resource" and thus cannot imply "preview only". But there is no concept of "is-a-preview-resource" for things in the `/packages` space.

However, the code using the flags doesn't really care about what combinations exist since the flags are designed to be used independently of each other, each answering a specific question at a certain place in the processing code.
* `hasPreviewVersion` means:
    *  Put this entry first so we can skip 99% of packages with no preview content during pre-processing.
* `isPreviewOnly` means:
    *  Don't add this to the `/packages` directory when *not* in preview mode.
    *  Put the node for this location in the preview-only map to be added separately during directory completion (in preview mode).

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 251:

> 249: 
> 250:             // Preview version of classes either overwrite existing entries or are added to directories.
> 251:             assertEquals("Preview: com.foo.HasPreviewVersion", loader.loadAndGetToString("modfoo", "com.foo.HasPreviewVersion"));

This "load the class, run its `toString()` method and test the result" could be encapsulated a bit more if you think it would make the intent of the test clearer. E.g.:


assertClassToString("modfoo", "com.foo.HasPreviewVersion", "Preview: com.foo.HasPreviewVersion", loader);


Or even:


loader.assertNormalVersion("modfoo", "com.foo.NormalFoo");
loader.assertPreviewVersion("modfoo", "com.foo.HasPreviewVersion");


Thoughts?

test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 318:

> 316:     }
> 317: 
> 318:     /// Note: This list is inherently a little fragile and may end up being more

Sorry about this enormous non-diff. It's because of moving the static init into a holder class because we now want "module" + "path" as two separate things, pre-calculated, for benchmarking the new APIs.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465642516
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465648972
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465656652
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465667236
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465672206
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465677574
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465700949
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465738045
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465769498
PR Review Comment: https://git.openjdk.org/valhalla/pull/1621#discussion_r2465776447

From dsimms at openjdk.org  Mon Oct 27 15:56:29 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 27 Oct 2025 15:56:29 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <E9Fkeap5uAolRcFzDXtpe59dASuNwpW7FpkuFHmyS2I=.52d175b7-0220-458c-884a-61000c75d984@github.com>
References: <E9Fkeap5uAolRcFzDXtpe59dASuNwpW7FpkuFHmyS2I=.52d175b7-0220-458c-884a-61000c75d984@github.com>
Message-ID: <sPdjpGRRCVhopTWnCbqsKrNuruFDpUxOtm73TXbhYfQ=.62a8e1b7-eff0-4056-8d87-a113ccb63483@github.com>

> Merge jdk-26+21

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

  Adjust testing for 8369043

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1704/files
  - new: https://git.openjdk.org/valhalla/pull/1704/files/b15d2e2d..82f5f8fa

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

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

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

From dsimms at openjdk.org  Mon Oct 27 16:51:10 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 27 Oct 2025 16:51:10 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <E9Fkeap5uAolRcFzDXtpe59dASuNwpW7FpkuFHmyS2I=.52d175b7-0220-458c-884a-61000c75d984@github.com>
References: <E9Fkeap5uAolRcFzDXtpe59dASuNwpW7FpkuFHmyS2I=.52d175b7-0220-458c-884a-61000c75d984@github.com>
Message-ID: <Q3QfWkL8gORlJuuQPtm-HNNAuQL_XBHcrcxPP9tXIkA=.f9f51cc3-7c6c-40b9-989e-e20971b2e20d@github.com>

On Mon, 27 Oct 2025 14:50:11 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+21

This pull request has now been integrated.

Changeset: 8cf3b7ad
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8cf3b7ad40492eec7c0bd015eb6772ea2c4bd50b
Stats:     17105 lines in 500 files changed: 10242 ins; 3427 del; 3436 mod

Merge jdk

Merge jdk-26+21

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

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

From fparain at openjdk.org  Mon Oct 27 17:44:48 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 27 Oct 2025 17:44:48 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v6]
In-Reply-To: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
Message-ID: <iTaKUtDpECwR_uyAFQxw06rwDbieBJVjTmUiFDmlo7w=.cc096d93-28e6-4bfd-8337-89a553c4b6ae@github.com>

> This is an alternate version of the substitutability method.
> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

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

  Add comment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1695/files
  - new: https://git.openjdk.org/valhalla/pull/1695/files/cf456a90..f5f7448e

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

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

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

From liach at openjdk.org  Mon Oct 27 18:48:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Oct 2025 18:48:06 GMT
Subject: [lworld] RFR: 8370687: [lworld] Improve before constructor has
 been called error message [v2]
In-Reply-To: <VxBE_8ALpU33-5C9Qf8HEXZ6taO21FA4hGjAQu-JOQQ=.f926301f-105c-45b6-9783-c8a7e239fd9a@github.com>
References: <VxBE_8ALpU33-5C9Qf8HEXZ6taO21FA4hGjAQu-JOQQ=.f926301f-105c-45b6-9783-c8a7e239fd9a@github.com>
Message-ID: <TDnEMaPxR-zAOU0DJMHdX8j5OxN5BFIyCGdT5skRmzo=.f619c461-5bba-4b8e-a544-3a9170448a58@github.com>

> Now we have an early construction by default mode on for value classes, where post-super calls requires explicit constructor invocation. We can tweak the messages slightly to accomplish this.

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

 - Revise message a bit more
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/before-ctor-message
 - 8370687: [lworld] Improve before constructor has been called error message

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1705/files
  - new: https://git.openjdk.org/valhalla/pull/1705/files/d2a57358..730d7d95

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

  Stats: 17107 lines in 501 files changed: 10242 ins; 3427 del; 3438 mod
  Patch: https://git.openjdk.org/valhalla/pull/1705.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1705/head:pull/1705

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

From vromero at openjdk.org  Mon Oct 27 18:53:44 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Oct 2025 18:53:44 GMT
Subject: [lworld] RFR: 8370687: [lworld] Improve before constructor has
 been called error message [v2]
In-Reply-To: <TDnEMaPxR-zAOU0DJMHdX8j5OxN5BFIyCGdT5skRmzo=.f619c461-5bba-4b8e-a544-3a9170448a58@github.com>
References: <VxBE_8ALpU33-5C9Qf8HEXZ6taO21FA4hGjAQu-JOQQ=.f926301f-105c-45b6-9783-c8a7e239fd9a@github.com>
 <TDnEMaPxR-zAOU0DJMHdX8j5OxN5BFIyCGdT5skRmzo=.f619c461-5bba-4b8e-a544-3a9170448a58@github.com>
Message-ID: <NKl9yrlvSwvns33vzaZP3-YEZxIslPKBfeKiD5qHxFc=.97bb051a-9317-4ae8-9eed-9a1c767ec188@github.com>

On Mon, 27 Oct 2025 18:48:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Now we have an early construction by default mode on for value classes, where post-super calls requires explicit constructor invocation. We can tweak the messages slightly to accomplish this.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Revise message a bit more
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/before-ctor-message
>  - 8370687: [lworld] Improve before constructor has been called error message

lgtm

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1705#pullrequestreview-3384994008

From coleenp at openjdk.org  Mon Oct 27 19:00:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 19:00:50 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v6]
In-Reply-To: <iTaKUtDpECwR_uyAFQxw06rwDbieBJVjTmUiFDmlo7w=.cc096d93-28e6-4bfd-8337-89a553c4b6ae@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <iTaKUtDpECwR_uyAFQxw06rwDbieBJVjTmUiFDmlo7w=.cc096d93-28e6-4bfd-8337-89a553c4b6ae@github.com>
Message-ID: <3Rr55yMTuW2VORspexmEpufuw0m5NHT5z7KHKJnOiYQ=.56aef665-ae46-429e-b9fd-ae3fdf6103b6@github.com>

On Mon, 27 Oct 2025 17:44:48 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

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

> 1299:   }
> 1300:   last_idx = last_idx == -1 ? 0 : last_idx;
> 1301:   int start = map->adr_at(last_idx)->first > offset ? 0 : last_idx;

last_idx is an optimization to try to prevent searching through the field map to find where to insert {offset,size} for the new entry.  When would it not be ascending?  super classes and inlined classes are inserted in order that they're found  in the LayoutBlocks so wouldn't the offsets be ascending?

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

> 1321: }
> 1322: 
> 1323: static int insert_map_at_offset(GrowableArray<Pair<int,int>>* nonoop_map, GrowableArray<int>* oop_map,

This copies the contents of the maps from an inline class that's flattened into this class or a super class into the map for this class.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2466725977
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2466690671

From coleenp at openjdk.org  Mon Oct 27 19:00:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 19:00:50 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v6]
In-Reply-To: <3Rr55yMTuW2VORspexmEpufuw0m5NHT5z7KHKJnOiYQ=.56aef665-ae46-429e-b9fd-ae3fdf6103b6@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <iTaKUtDpECwR_uyAFQxw06rwDbieBJVjTmUiFDmlo7w=.cc096d93-28e6-4bfd-8337-89a553c4b6ae@github.com>
 <3Rr55yMTuW2VORspexmEpufuw0m5NHT5z7KHKJnOiYQ=.56aef665-ae46-429e-b9fd-ae3fdf6103b6@github.com>
Message-ID: <bXXTC-69pinekRzTM4DDKnAmnS2v631SVNvxCJRB4pU=.4616ac9b-74d6-43ef-9d2b-2e27383e5c8d@github.com>

On Mon, 27 Oct 2025 18:47:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment
>
> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1301:
> 
>> 1299:   }
>> 1300:   last_idx = last_idx == -1 ? 0 : last_idx;
>> 1301:   int start = map->adr_at(last_idx)->first > offset ? 0 : last_idx;
> 
> last_idx is an optimization to try to prevent searching through the field map to find where to insert {offset,size} for the new entry.  When would it not be ascending?  super classes and inlined classes are inserted in order that they're found  in the LayoutBlocks so wouldn't the offsets be ascending?

You answered this in slack for me.  Can you put this at the top of this function:


The insert_segment creates an ordered list of maps {offset, size} from the LayoutRawBlocks.  LayoutRawBlocks are queued in ascending offset order, and are processed in this order.  This allows the last_idx optimization which would be critical for classes with a huge number of fields.
But, this property is not required, and, if you look at the entire set of fields being processed, they might not all be processed by ascending offset order.
Inherited fields are inserted first, by copying them from the super-class, and then local fields are processed. It is possible to have local fields interleaved with super-class fields. So all fields are not necessarily processed in ascending offset order. The algorithm tries to do it, and optimizes the insertion when it is done that way, but it also handles cases where this is not the case.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2466757559

From fparain at openjdk.org  Mon Oct 27 19:27:57 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 27 Oct 2025 19:27:57 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v7]
In-Reply-To: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
Message-ID: <SvxT2sCf13DrLKxl91WwWGB6lddGContUhAzgxRTLFg=.aceb20d4-99aa-4840-9851-384cf2862ae3@github.com>

> This is an alternate version of the substitutability method.
> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

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

  Add comment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1695/files
  - new: https://git.openjdk.org/valhalla/pull/1695/files/f5f7448e..e9e79fe6

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

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

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

From fparain at openjdk.org  Mon Oct 27 19:30:28 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 27 Oct 2025 19:30:28 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v6]
In-Reply-To: <bXXTC-69pinekRzTM4DDKnAmnS2v631SVNvxCJRB4pU=.4616ac9b-74d6-43ef-9d2b-2e27383e5c8d@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <iTaKUtDpECwR_uyAFQxw06rwDbieBJVjTmUiFDmlo7w=.cc096d93-28e6-4bfd-8337-89a553c4b6ae@github.com>
 <3Rr55yMTuW2VORspexmEpufuw0m5NHT5z7KHKJnOiYQ=.56aef665-ae46-429e-b9fd-ae3fdf6103b6@github.com>
 <bXXTC-69pinekRzTM4DDKnAmnS2v631SVNvxCJRB4pU=.4616ac9b-74d6-43ef-9d2b-2e27383e5c8d@github.com>
Message-ID: <hO2yNwNSr5XGv__fJXojtBLGmwz4qSZ6AgoXclzP0MA=.2cfdaded-1c23-4fea-a992-aa40265ec9ae@github.com>

On Mon, 27 Oct 2025 18:57:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1301:
>> 
>>> 1299:   }
>>> 1300:   last_idx = last_idx == -1 ? 0 : last_idx;
>>> 1301:   int start = map->adr_at(last_idx)->first > offset ? 0 : last_idx;
>> 
>> last_idx is an optimization to try to prevent searching through the field map to find where to insert {offset,size} for the new entry.  When would it not be ascending?  super classes and inlined classes are inserted in order that they're found  in the LayoutBlocks so wouldn't the offsets be ascending?
>
> You answered this in slack for me.  Can you put this at the top of this function:
> 
> 
> The insert_segment creates an ordered list of maps {offset, size} from the LayoutRawBlocks.  LayoutRawBlocks are queued in ascending offset order, and are processed in this order.  This allows the last_idx optimization which would be critical for classes with a huge number of fields.
> But, this property is not required, and, if you look at the entire set of fields being processed, they might not all be processed by ascending offset order.
> Inherited fields are inserted first, by copying them from the super-class, and then local fields are processed. It is possible to have local fields interleaved with super-class fields. So all fields are not necessarily processed in ascending offset order. The algorithm tries to do it, and optimizes the insertion when it is done that way, but it also handles cases where this is not the case.

Comments have been added in `FieldLayoutBuilder::generate_acmp_maps()`.
Let me know if the explanation  is sufficient to clarify how the code works.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2466837183

From coleenp at openjdk.org  Mon Oct 27 19:34:27 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 19:34:27 GMT
Subject: [lworld] RFR: 8314996: [lworld]
 java/lang/Thread/virtual/stress/PingPong.java fails since jdk-22+8
In-Reply-To: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>
References: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>
Message-ID: <iyEc41nk9Err6DrZAOMs1QBeKW80qZT9oQlyl29HlhQ=.5206caf6-7663-42e4-91cd-4d60f457b2c9@github.com>

On Fri, 3 Oct 2025 14:54:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> When running with JTREG_REPEAT_COUNT=1000 I get the same error as skynet in [JDK-8342977](https://bugs.openjdk.org/browse/JDK-8342977), so I'm using that number for the ProblemList-Virtual.txt. This fails intermittently without JTREG_TEST_THREAD_FACTORY=Virtual, so maybe this belongs in ProblemList.txt instead, as well as Skynet.

Thanks Paul and Fred.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1657#issuecomment-3452970815

From coleenp at openjdk.org  Mon Oct 27 19:35:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 19:35:30 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v7]
In-Reply-To: <SvxT2sCf13DrLKxl91WwWGB6lddGContUhAzgxRTLFg=.aceb20d4-99aa-4840-9851-384cf2862ae3@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <SvxT2sCf13DrLKxl91WwWGB6lddGContUhAzgxRTLFg=.aceb20d4-99aa-4840-9851-384cf2862ae3@github.com>
Message-ID: <thvoIroBEY42I-BmAzP4lcoiwnFNWzlyTly2K1HluHE=.bb3302fd-aa04-488e-983b-81cb7fc30f44@github.com>

On Mon, 27 Oct 2025 19:27:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by coleenp (Committer).

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

> 1363:   // Local fields are processed in ascending offset order, so an insertion is very likely be performed
> 1364:   // next to the previous insertion. However, in some cases local fields and inherited fields can be
> 1365:   // interleaved, in which case the search of the insertion position cannot depend on the previous insertion.

thanks.

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

PR Review: https://git.openjdk.org/valhalla/pull/1695#pullrequestreview-3385146100
PR Review Comment: https://git.openjdk.org/valhalla/pull/1695#discussion_r2466845979

From coleenp at openjdk.org  Mon Oct 27 19:38:25 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 19:38:25 GMT
Subject: [lworld] Integrated: 8314996: [lworld]
 java/lang/Thread/virtual/stress/PingPong.java fails since jdk-22+8
In-Reply-To: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>
References: <iBc0e3I6vsrbVTyf3J98oTluRcCSJkLv8Ur8RFAN2Fs=.1ce71d9b-ced8-4ca6-bdcb-2d87f35a909f@github.com>
Message-ID: <NBp1OPw1Mr2-_6tDE2Fhq4I7UA3bpgsbjxnZ_8FlyII=.40607bd6-0d7e-444c-b8de-d0477f568e4a@github.com>

On Fri, 3 Oct 2025 14:54:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> When running with JTREG_REPEAT_COUNT=1000 I get the same error as skynet in [JDK-8342977](https://bugs.openjdk.org/browse/JDK-8342977), so I'm using that number for the ProblemList-Virtual.txt. This fails intermittently without JTREG_TEST_THREAD_FACTORY=Virtual, so maybe this belongs in ProblemList.txt instead, as well as Skynet.

This pull request has now been integrated.

Changeset: c3b382ea
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c3b382eae0900dedebc987e3e74acdd72ee98354
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8314996: [lworld] java/lang/Thread/virtual/stress/PingPong.java fails since jdk-22+8

Reviewed-by: phubner, fparain

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

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

From coleenp at openjdk.org  Mon Oct 27 19:41:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 19:41:34 GMT
Subject: [lworld] RFR: 8370509: [lworld] EnableValhalla is not needed for
 sync [v2]
In-Reply-To: <RBFdARRFsh1Tnh2abs-eMck-A-gAqy3wwgl8pz_Nhxo=.d3406e29-9a02-4ddd-917d-e0bc93094388@github.com>
References: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
 <RBFdARRFsh1Tnh2abs-eMck-A-gAqy3wwgl8pz_Nhxo=.d3406e29-9a02-4ddd-917d-e0bc93094388@github.com>
Message-ID: <axl6pYhfeoLlrgffRmKfcC0N0uQ-AuWwMJjWAbNKohQ=.fe23a64e-af8f-4288-af3c-8911bc5a8f4e@github.com>

On Fri, 24 Oct 2025 17:29:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I took out EnableValhalla as a conditional test in the ObjectSynchronizer code.  If the inline type bit is set in the markWord or the klass is InlineKlass, we can't synchronize on the object.
>> I added a test but it was sort of a duplicate of all runtime/valhalla/inlinetypes/MonitorEnterTest.java and duplicates all tests that do locking so I didn't add a test.
>> Testing with tier1-4, still in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More descriptive assert message for FastHashCode of value classes.

Thanks Paul and Fred for reviewing.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1699#issuecomment-3452993343

From coleenp at openjdk.org  Mon Oct 27 19:41:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 19:41:36 GMT
Subject: [lworld] Integrated: 8370509: [lworld] EnableValhalla is not needed
 for sync
In-Reply-To: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
References: <8T5tMjOrp8R6vwTjY7FrEGUGZVJQEWqgMNJ-cl5KLLQ=.0794b712-a3ad-4138-9d6c-f146e69cc328@github.com>
Message-ID: <hOsGWkhxWq2BrT_3y-jLLu9f3Gwx0DpFtUsr96JDDEE=.4ee6f2a5-0ce5-4e11-907d-2cfac56a3f3d@github.com>

On Thu, 23 Oct 2025 20:30:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I took out EnableValhalla as a conditional test in the ObjectSynchronizer code.  If the inline type bit is set in the markWord or the klass is InlineKlass, we can't synchronize on the object.
> I added a test but it was sort of a duplicate of all runtime/valhalla/inlinetypes/MonitorEnterTest.java and duplicates all tests that do locking so I didn't add a test.
> Testing with tier1-4, still in progress.

This pull request has now been integrated.

Changeset: ba1a3055
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ba1a3055dec3a12163aa77a683ea000062f1ecaf
Stats:     18 lines in 3 files changed: 0 ins; 3 del; 15 mod

8370509: [lworld] EnableValhalla is not needed for sync

Reviewed-by: phubner, fparain

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

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

From coleenp at openjdk.org  Mon Oct 27 19:43:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Oct 2025 19:43:31 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v7]
In-Reply-To: <SvxT2sCf13DrLKxl91WwWGB6lddGContUhAzgxRTLFg=.aceb20d4-99aa-4840-9851-384cf2862ae3@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <SvxT2sCf13DrLKxl91WwWGB6lddGContUhAzgxRTLFg=.aceb20d4-99aa-4840-9851-384cf2862ae3@github.com>
Message-ID: <5MH13Si2TZDSImaCtkh8gkxQpjP3owSSC31GVaRJbBM=.8bdee877-b361-44d0-bb88-e5c64ea19353@github.com>

On Mon, 27 Oct 2025 19:27:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

At the risk of repeating myself, this is great work!

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1695#pullrequestreview-3385183652

From liach at openjdk.org  Mon Oct 27 20:35:28 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Oct 2025 20:35:28 GMT
Subject: [lworld] RFR: 8370687: Improve before constructor has been called
 error message [v2]
In-Reply-To: <TDnEMaPxR-zAOU0DJMHdX8j5OxN5BFIyCGdT5skRmzo=.f619c461-5bba-4b8e-a544-3a9170448a58@github.com>
References: <VxBE_8ALpU33-5C9Qf8HEXZ6taO21FA4hGjAQu-JOQQ=.f926301f-105c-45b6-9783-c8a7e239fd9a@github.com>
 <TDnEMaPxR-zAOU0DJMHdX8j5OxN5BFIyCGdT5skRmzo=.f619c461-5bba-4b8e-a544-3a9170448a58@github.com>
Message-ID: <XOSbFg65fuwJk6Pe1aBZM9mVytWPAXMAk5i-wkV0ZmM=.ecec6372-ab22-4fff-ac86-0329545d0c4b@github.com>

On Mon, 27 Oct 2025 18:48:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Now we have an early construction by default mode on for value classes, where post-super calls requires explicit constructor invocation. We can tweak the messages slightly to accomplish this.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Revise message a bit more
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/before-ctor-message
>  - 8370687: [lworld] Improve before constructor has been called error message

Will integrate with the mainline one after the review period for the mainline PR.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1705#issuecomment-3453195962

From liach at openjdk.org  Mon Oct 27 20:35:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 Oct 2025 20:35:32 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v7]
In-Reply-To: <SvxT2sCf13DrLKxl91WwWGB6lddGContUhAzgxRTLFg=.aceb20d4-99aa-4840-9851-384cf2862ae3@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <SvxT2sCf13DrLKxl91WwWGB6lddGContUhAzgxRTLFg=.aceb20d4-99aa-4840-9851-384cf2862ae3@github.com>
Message-ID: <3Jo6wOI_9fjtp_IjOP6KupvfurTFlWWSnCicbNF9DSs=.48d05185-f6ea-4ed2-9eac-696e3c17ab02@github.com>

On Mon, 27 Oct 2025 19:27:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

The library part looks acceptable, even though ideally I wish the VM would be able to request specialized comparison methods for each value type, so core library can provide specialized bytecode.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1695#pullrequestreview-3385359096

From ethan at mccue.dev  Tue Oct 28 00:08:55 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 27 Oct 2025 20:08:55 -0400
Subject: Raytracing Experience Report
Message-ID: <CA+NR86j08y06gA74qZs4GsHm_Ch9SmYnEfxe9+2234sdgQDBfw@mail.gmail.com>

Hi all,

I have been following along in the "Ray Tracing in a Weekend" book and
trying to make as many classes as possible value classes. (Vec3, Ray, etc.)

https://github.com/bowbahdoe/raytracer

https://raytracing.github.io/books/RayTracingInOneWeekend.html

(without value classes)

time java --enable-preview --class-path build/classes Main > image.ppm


real 4m33.190s
user 4m28.984s
sys 0m5.511s

(with value classes)

time java --enable-preview --class-path build/classes Main > image.ppm


real 3m54.623s
user 3m52.205s
sys 0m2.064s

So by the end the version using value classes beats the version without
them by ~14% using unscientific measurements.

But that is at the end, running the ray tracer on a relatively large scene
with all the features turned on. Before that point there were some
checkpoints where using value classes performed noticeably worse than the
equivalent code sans the value modifier

https://github.com/bowbahdoe/raytracer/tree/no-value-faster

real 1m22.172s
user 1m9.871s
sys 0m12.951s

https://github.com/bowbahdoe/raytracer/tree/with-value-slower

real 3m34.440s
user 3m19.656s
sys 0m14.870s

So for some reason just adding value to the records/classes makes the
program run a over 2x as slow.

https://github.com/bowbahdoe/raytracer/compare/no-value-faster...with-value-slower

Is there some intuition that explains this? I am on a stock M1 Arm Mac.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251027/aa1c7f88/attachment.htm>

From phubner at openjdk.org  Tue Oct 28 08:39:00 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 28 Oct 2025 08:39:00 GMT
Subject: [lworld] RFR: Problem list
 compiler/valhalla/inlinetypes/TestNullableArrays.java
Message-ID: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>

The test is causing a lot of noise in the CI.

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

Commit messages:
 - Problem list C1 segfault.

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

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

From dsimms at openjdk.org  Tue Oct 28 08:39:00 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 28 Oct 2025 08:39:00 GMT
Subject: [lworld] RFR: Problem list
 compiler/valhalla/inlinetypes/TestNullableArrays.java
In-Reply-To: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
References: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
Message-ID: <bQnw2Lqx4zTktVd-RSnzunxwqz3qnTUxZBLrnDq1z2s=.7d64ace1-d84e-44ac-abc7-673f923005d3@github.com>

On Tue, 28 Oct 2025 08:19:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is causing a lot of noise in the CI.

Ship it

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1707#pullrequestreview-3387284822

From phubner at openjdk.org  Tue Oct 28 08:39:01 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 28 Oct 2025 08:39:01 GMT
Subject: [lworld] RFR: Problem list
 compiler/valhalla/inlinetypes/TestNullableArrays.java
In-Reply-To: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
References: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
Message-ID: <ske0QXlpT_FQpWJ6xGgxjMTBr9b87WYsQO7B-RK3zcI=.984e4c36-0a88-49bd-93a2-c8168b514b73@github.com>

On Tue, 28 Oct 2025 08:19:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is causing a lot of noise in the CI.

Thanks for the quick review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1707#issuecomment-3455184102

From duke at openjdk.org  Tue Oct 28 08:39:01 2025
From: duke at openjdk.org (duke)
Date: Tue, 28 Oct 2025 08:39:01 GMT
Subject: [lworld] RFR: Problem list
 compiler/valhalla/inlinetypes/TestNullableArrays.java
In-Reply-To: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
References: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
Message-ID: <Yp0QL12POsDMuP6-OQhKHvgBqr6KU3TCRihEsPFDAcM=.2bd873a8-5c62-41c4-a4e7-4fedf5d24c3c@github.com>

On Tue, 28 Oct 2025 08:19:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is causing a lot of noise in the CI.

@Arraying 
Your change (at version 097b884388d5a5a13eee682585c034e7409ad8bc) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1707#issuecomment-3455190254

From phubner at openjdk.org  Tue Oct 28 09:19:42 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 28 Oct 2025 09:19:42 GMT
Subject: [lworld] Integrated: Problem list
 compiler/valhalla/inlinetypes/TestNullableArrays.java
In-Reply-To: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
References: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
Message-ID: <W-zwmygMFTSnKqjRB2Sh70Kr_PtPqA370JVghenPZOQ=.33931234-7ef3-4cbe-b766-20f1ada03261@github.com>

On Tue, 28 Oct 2025 08:19:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is causing a lot of noise in the CI.

This pull request has now been integrated.

Changeset: 8bd522b5
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8bd522b5d19d2902baad9d204af72fa4402ca2d4
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

Problem list compiler/valhalla/inlinetypes/TestNullableArrays.java

Reviewed-by: dsimms

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

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

From dfenacci at openjdk.org  Tue Oct 28 13:46:41 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 28 Oct 2025 13:46:41 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests
Message-ID: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>

# Issue

Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
[JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.

# Cause

Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.

# Fix

We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.

# Testing

Tier 1-3
Worst-time compiler/valhalla JTReg tests went from 16min to <2min

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

Commit messages:
 - JDK-8369530: update copyright year
 - JDK-8369530: [lworld] Improve execution time of compiler tests

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

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

From mhaessig at openjdk.org  Tue Oct 28 14:55:15 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 28 Oct 2025 14:55:15 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests
In-Reply-To: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
Message-ID: <6lwk0leq5Xpo3W7HsgcuGFGxFthNGbg5CKnooKKnaRg=.5a888e56-10cb-4fda-b841-ccec923532bc@github.com>

On Tue, 28 Oct 2025 10:41:52 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> # Issue
> 
> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
> 
> # Cause
> 
> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
> 
> # Fix
> 
> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
> 
> # Testing
> 
> Tier 1-3
> Worst-time compiler/valhalla JTReg tests went from 16min to <2min

Thank you for this vast improvement, @dafedafe! This looks good to me, bar the superfluous import.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java line 34:

> 32: import java.lang.invoke.MethodType;
> 33: import java.lang.reflect.Method;
> 34: import java.util.Arrays;

Suggestion:


I don't see why this is being added.

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

Marked as reviewed by mhaessig (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1708#pullrequestreview-3389200955
PR Review Comment: https://git.openjdk.org/valhalla/pull/1708#discussion_r2469879564

From chagedorn at openjdk.org  Tue Oct 28 14:55:16 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 28 Oct 2025 14:55:16 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests
In-Reply-To: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
Message-ID: <amwWiN90kQu_XQeYWFXHECLZLShB0uARUcZQISpKWag=.241c05ec-096a-40c0-9f1d-4084de05d1bc@github.com>

On Tue, 28 Oct 2025 10:41:52 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> # Issue
> 
> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
> 
> # Cause
> 
> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
> 
> # Fix
> 
> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
> 
> # Testing
> 
> Tier 1-3
> Worst-time compiler/valhalla JTReg tests went from 16min to <2min

That's an impressive improvement! Thanks for having a closer look at what we could do. Have you also played around with using Java threads instead (i.e. a `TestFramework` instance per thread that adds the scenario flags)?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1708#issuecomment-3456902661

From dfenacci at openjdk.org  Tue Oct 28 15:30:49 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 28 Oct 2025 15:30:49 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests
In-Reply-To: <amwWiN90kQu_XQeYWFXHECLZLShB0uARUcZQISpKWag=.241c05ec-096a-40c0-9f1d-4084de05d1bc@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
 <amwWiN90kQu_XQeYWFXHECLZLShB0uARUcZQISpKWag=.241c05ec-096a-40c0-9f1d-4084de05d1bc@github.com>
Message-ID: <W-p8Ouh1pKXU5o-3jc8YjgHsYZTQG7EJjhwsiarrpUM=.1eaa227c-219c-4804-a0c0-5deabfaedb88@github.com>

On Tue, 28 Oct 2025 14:52:40 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Have you also played around with using Java threads instead (i.e. a TestFramework instance per thread that adds the scenario flags)?

Not yet. For this fix I think it would be anyway better to let JTReg handle the different scenario process so that they can potentially be run on different machines. I have created [JDK-8370315](https://bugs.openjdk.org/browse/JDK-8370315) on mainline to look into it and also see if/when multiple threads can be beneficial.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1708#issuecomment-3457080005

From dfenacci at openjdk.org  Tue Oct 28 15:30:49 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 28 Oct 2025 15:30:49 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests [v2]
In-Reply-To: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
Message-ID: <nhUSGCOtNpQ-NuE8FdWYIkvmLMeP8QTydCayNRdzOAM=.9e3de0ba-ab5d-466c-b9a8-326130b4514d@github.com>

> # Issue
> 
> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
> 
> # Cause
> 
> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
> 
> # Fix
> 
> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
> 
> # Testing
> 
> Tier 1-3
> Worst-time compiler/valhalla JTReg tests went from 16min to <2min

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8369530: remove import

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1708/files
  - new: https://git.openjdk.org/valhalla/pull/1708/files/9e4666ac..411f809b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1708&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1708&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1708.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1708/head:pull/1708

PR: https://git.openjdk.org/valhalla/pull/1708

From dfenacci at openjdk.org  Tue Oct 28 15:30:53 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 28 Oct 2025 15:30:53 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests [v2]
In-Reply-To: <6lwk0leq5Xpo3W7HsgcuGFGxFthNGbg5CKnooKKnaRg=.5a888e56-10cb-4fda-b841-ccec923532bc@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
 <6lwk0leq5Xpo3W7HsgcuGFGxFthNGbg5CKnooKKnaRg=.5a888e56-10cb-4fda-b841-ccec923532bc@github.com>
Message-ID: <4w4pDvLaQy43DzYjHQ81w_Drz3FBbhBTR-I1KSJLvww=.dd8eb6f6-ba0a-4c40-8787-c0c9c4227c3b@github.com>

On Tue, 28 Oct 2025 14:50:06 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8369530: remove import
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java line 34:
> 
>> 32: import java.lang.invoke.MethodType;
>> 33: import java.lang.reflect.Method;
>> 34: import java.util.Arrays;
> 
> Suggestion:
> 
> 
> I don't see why this is being added.

Leftover of some experiments. I removed it.
Thanks for the review @mhaessig!

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1708#discussion_r2470009604

From liach at openjdk.org  Tue Oct 28 18:10:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 28 Oct 2025 18:10:54 GMT
Subject: [lworld] Integrated: 8370687: Improve before constructor has been
 called error message
In-Reply-To: <VxBE_8ALpU33-5C9Qf8HEXZ6taO21FA4hGjAQu-JOQQ=.f926301f-105c-45b6-9783-c8a7e239fd9a@github.com>
References: <VxBE_8ALpU33-5C9Qf8HEXZ6taO21FA4hGjAQu-JOQQ=.f926301f-105c-45b6-9783-c8a7e239fd9a@github.com>
Message-ID: <SHZ6dbVhnXx6vJejvR9Jzd5ppM7PMSWYgUOMFhaYVRI=.9bf97242-88be-4f3c-ab9a-492c0ef27739@github.com>

On Mon, 27 Oct 2025 15:20:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> Now we have an early construction by default mode on for value classes, where post-super calls requires explicit constructor invocation. We can tweak the messages slightly to accomplish this.

This pull request has now been integrated.

Changeset: ef116822
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ef1168224414d82101d177d9191b27f85ccd2826
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8370687: Improve before constructor has been called error message

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/valhalla/pull/1705

From matsaave at openjdk.org  Tue Oct 28 19:13:04 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 28 Oct 2025 19:13:04 GMT
Subject: [lworld] RFR: 8370217: [lworld] Crash in
 add_migrated_value_classes after merging JDK-8350550
In-Reply-To: <kFM2BD7xcmskWzyPlt_h1EjqWANMwGmBMGT4O_DsM7U=.965b4e02-bec8-43a9-9252-cd667f3abaad@github.com>
References: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
 <kFM2BD7xcmskWzyPlt_h1EjqWANMwGmBMGT4O_DsM7U=.965b4e02-bec8-43a9-9252-cd667f3abaad@github.com>
Message-ID: <By7V0V55jtByPfjg5l1EF9ZHrRFv0w6qOELi93xwSJc=.56688e53-f62f-4d5a-b489-2b0120940bc0@github.com>

On Fri, 24 Oct 2025 17:30:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The method add_migrated_value_classes() is being called in non-preview mode leading to an assert due to the expected classes not being present in the AOT cache. The check for `EnableValhalla` is replaced with a check for preview mode. Verified with tier 1-5 tests.
>
> src/hotspot/share/classfile/systemDictionary.cpp line 215:
> 
>> 213:     } else {
>> 214:       ClassLoaderData* cld = ClassLoaderDataGraph::find_or_create(class_loader);
>> 215:       if (CDSConfig::is_valhalla_preview()) {
> 
> Since this method was refactored to not be only CDS, I think you should use Arguments::enable_preview() as the test instead of the CDS specific test.

Although it's redundant at the moment, I think this needs to also check for `EnableValhalla`. In case that enable-preview and EnableValhalla are separated, it needs to be clear what is being checked here. This will also be an easier case to grep for once we consider merging into mainline.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1698#discussion_r2470753195

From cjplummer at openjdk.org  Tue Oct 28 19:21:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 Oct 2025 19:21:55 GMT
Subject: [lworld] RFR: 8367711: [lworld] JDI test updates
In-Reply-To: <7IB6ODxOTYQy_u-Hjf-hNAEIqLCwsElPuH9UPKoFT-0=.86147cf3-e35a-4ac9-9e57-8939c5ee92b1@github.com>
References: <7IB6ODxOTYQy_u-Hjf-hNAEIqLCwsElPuH9UPKoFT-0=.86147cf3-e35a-4ac9-9e57-8939c5ee92b1@github.com>
Message-ID: <-ia6q0t4ElF3eDRwugM_DDGVMffGnVY7jeAXsUp_UZ0=.55c3e4ed-387f-4817-acc0-d4c4c37c6ff4@github.com>

On Sat, 25 Oct 2025 00:42:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Update for JDI tests.
> This is follow up for [1519](https://github.com/openjdk/valhalla/pull/1519) (feedback was added after integration)

Marked as reviewed by cjplummer (no project role).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1702#pullrequestreview-3390441603

From matsaave at openjdk.org  Tue Oct 28 19:31:16 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 28 Oct 2025 19:31:16 GMT
Subject: [lworld] RFR: 8370217: [lworld] Crash in
 add_migrated_value_classes after merging JDK-8350550 [v2]
In-Reply-To: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
References: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
Message-ID: <dHf3NKVKuEvJyzOWejDYNLxBFnuG4YViDN3oxNGsQm4=.5ca62c73-7148-48d3-a497-805f3191430c@github.com>

> The method add_migrated_value_classes() is being called in non-preview mode leading to an assert due to the expected classes not being present in the AOT cache. The check for `EnableValhalla` is replaced with a check for preview mode. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Coleen comments
 - Merge branch 'lworld' into crash_8370217
 - 8370217: [lworld] Crash in add_migrated_value_classes after merging JDK-8350550

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1698/files
  - new: https://git.openjdk.org/valhalla/pull/1698/files/8c9e3017..3546f6d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1698&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1698&range=00-01

  Stats: 12484 lines in 451 files changed: 6693 ins; 3205 del; 2586 mod
  Patch: https://git.openjdk.org/valhalla/pull/1698.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1698/head:pull/1698

PR: https://git.openjdk.org/valhalla/pull/1698

From duke at openjdk.org  Tue Oct 28 21:46:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 28 Oct 2025 21:46:29 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v10]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <hEO7f9vpgnLuTTI46PG_9_vY56oLpFFqrHOTWjDR8Go=.b795e7d3-6440-4735-87e0-0c38750b5b48@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Re-delete ImageReaderFactory (again).

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1621/files
  - new: https://git.openjdk.org/valhalla/pull/1621/files/f76c16e2..a6c83b18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=09
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=08-09

  Stats: 106 lines in 1 file changed: 0 ins; 106 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

PR: https://git.openjdk.org/valhalla/pull/1621

From davidalayachew at gmail.com  Wed Oct 29 04:27:55 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 29 Oct 2025 00:27:55 -0400
Subject: Compiler error message not clear for Valhalla EA 2
Message-ID: <CAA9v-_PfPObi0E6UhsD=Ar_Br9pgJhD=2sk=no7z4P5-hMmbKQ@mail.gmail.com>

Hello @valhalla-dev <valhalla-dev at openjdk.org>,

While testing out the new Valhalla EA that came out a few days ago, I ran
into the following compiler error.

Here is a minified example.

public value class abc
{

        public abc()
        {
                throw new UnsupportedOperationException();
        }

        public static void someHelperMethod()
        {}

}

And here is the compiler error message.

$ java --enable-preview abc.java
abc.java:5: error: unreachable statement
        {
        ^
1 error
error: compilation failed


That location is the opening curly brace of the constructor.

Can we have a more clear error message?

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251029/738bbcb3/attachment-0001.htm>

From davidalayachew at gmail.com  Wed Oct 29 04:30:23 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 29 Oct 2025 00:30:23 -0400
Subject: Compiler error message not clear for Valhalla EA 2
In-Reply-To: <CAA9v-_PfPObi0E6UhsD=Ar_Br9pgJhD=2sk=no7z4P5-hMmbKQ@mail.gmail.com>
References: <CAA9v-_PfPObi0E6UhsD=Ar_Br9pgJhD=2sk=no7z4P5-hMmbKQ@mail.gmail.com>
Message-ID: <CAA9v-_MoTAwTCZNwoctTBK58cgGysUm-QLmwC-bti_cx-zvTfA@mail.gmail.com>

The compiler error message goes away if I put a super(); as the first
statement in the constructor. But still, that error message could be
clearer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251029/36432d1e/attachment.htm>

From thartmann at openjdk.org  Wed Oct 29 06:26:32 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 29 Oct 2025 06:26:32 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests [v2]
In-Reply-To: <nhUSGCOtNpQ-NuE8FdWYIkvmLMeP8QTydCayNRdzOAM=.9e3de0ba-ab5d-466c-b9a8-326130b4514d@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
 <nhUSGCOtNpQ-NuE8FdWYIkvmLMeP8QTydCayNRdzOAM=.9e3de0ba-ab5d-466c-b9a8-326130b4514d@github.com>
Message-ID: <DVTol6jLkPelO5GIae7lzmHT2jHrSEBeKCulcqzDPXo=.897369bc-d1cb-4a55-be62-800b437c4133@github.com>

On Tue, 28 Oct 2025 15:30:49 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # Issue
>> 
>> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
>> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
>> 
>> # Cause
>> 
>> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
>> 
>> # Fix
>> 
>> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
>> 
>> # Testing
>> 
>> Tier 1-3
>> Worst-time compiler/valhalla JTReg tests went from 16min to <2min
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8369530: remove import

Marked as reviewed by thartmann (Committer).

Out of curiosity, what's the different in machine time for the tiers?

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1708#pullrequestreview-3391832981
PR Comment: https://git.openjdk.org/valhalla/pull/1708#issuecomment-3460025566

From thartmann at openjdk.org  Wed Oct 29 06:26:33 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 29 Oct 2025 06:26:33 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests
In-Reply-To: <W-p8Ouh1pKXU5o-3jc8YjgHsYZTQG7EJjhwsiarrpUM=.1eaa227c-219c-4804-a0c0-5deabfaedb88@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
 <amwWiN90kQu_XQeYWFXHECLZLShB0uARUcZQISpKWag=.241c05ec-096a-40c0-9f1d-4084de05d1bc@github.com>
 <W-p8Ouh1pKXU5o-3jc8YjgHsYZTQG7EJjhwsiarrpUM=.1eaa227c-219c-4804-a0c0-5deabfaedb88@github.com>
Message-ID: <FaSzM_GXmCaenyhihW_gsjH8O0MH8Z7vjGa-GGrxeQQ=.08d5aeb2-2fd0-4ea7-bc71-874b9b994af6@github.com>

On Tue, 28 Oct 2025 15:27:51 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> Not yet. For this fix I think it would be anyway better to let JTReg handle the different scenario process so that they can potentially be run on different machines. I have created [JDK-8370315](https://bugs.openjdk.org/browse/JDK-8370315) on mainline to look into it and also see if/when multiple threads can be beneficial.

Right, I wonder if scenarios should really be parallelized by the framework or if we shouldn't let jtreg take care of that (which has the advantage that it will also parallelize on different hosts, I think).

The changes look good to me.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1708#issuecomment-3460016914

From chagedorn at openjdk.org  Wed Oct 29 06:46:39 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 29 Oct 2025 06:46:39 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests [v2]
In-Reply-To: <nhUSGCOtNpQ-NuE8FdWYIkvmLMeP8QTydCayNRdzOAM=.9e3de0ba-ab5d-466c-b9a8-326130b4514d@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
 <nhUSGCOtNpQ-NuE8FdWYIkvmLMeP8QTydCayNRdzOAM=.9e3de0ba-ab5d-466c-b9a8-326130b4514d@github.com>
Message-ID: <nBSaWGQAXfESDjBhYOrlVBzCJJx4u7idy1VDb4bVXKo=.f3a53aa0-5d52-43a9-913c-bffbbfd4f883@github.com>

On Tue, 28 Oct 2025 15:30:49 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # Issue
>> 
>> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
>> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
>> 
>> # Cause
>> 
>> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
>> 
>> # Fix
>> 
>> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
>> 
>> # Testing
>> 
>> Tier 1-3
>> Worst-time compiler/valhalla JTReg tests went from 16min to <2min
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8369530: remove import

Looks good, thanks for taking care of that!

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAllocationMergeAndFolding.java line 122:

> 120:                 framework.addScenarios(new Scenario(7, "--enable-preview", "-XX:-UseCompressedOops"));
> 121:         } else {
> 122:                 framework.addScenarios(new Scenario(8, "--enable-preview", "-XX:+UseCompressedOops"));

Indentation is too big:

Suggestion:

            framework.addScenarios(InlineTypes.DEFAULT_SCENARIOS[index]);
        } else if (index == 7) {
            framework.addScenarios(new Scenario(7, "--enable-preview", "-XX:-UseCompressedOops"));
        } else {
            framework.addScenarios(new Scenario(8, "--enable-preview", "-XX:+UseCompressedOops"));

-------------

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1708#pullrequestreview-3391878035
PR Review Comment: https://git.openjdk.org/valhalla/pull/1708#discussion_r2471889558

From dfenacci at openjdk.org  Wed Oct 29 07:52:01 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 29 Oct 2025 07:52:01 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests [v3]
In-Reply-To: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
Message-ID: <VRvsy2zaA1kT3Cko4lilWustgnLyWOX6G9NiR1DxJTI=.e5aa92ec-5b06-444d-9ba1-23fa10a1ebf4@github.com>

> # Issue
> 
> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
> 
> # Cause
> 
> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
> 
> # Fix
> 
> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
> 
> # Testing
> 
> Tier 1-3
> Worst-time compiler/valhalla JTReg tests went from 16min to <2min

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestion from @chhagedorn
  
  Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1708/files
  - new: https://git.openjdk.org/valhalla/pull/1708/files/411f809b..0404eef2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1708&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1708&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1708.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1708/head:pull/1708

PR: https://git.openjdk.org/valhalla/pull/1708

From forax at univ-mlv.fr  Wed Oct 29 08:30:22 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 29 Oct 2025 09:30:22 +0100 (CET)
Subject: Compiler error message not clear for Valhalla EA 2
In-Reply-To: <CAA9v-_MoTAwTCZNwoctTBK58cgGysUm-QLmwC-bti_cx-zvTfA@mail.gmail.com>
References: <CAA9v-_PfPObi0E6UhsD=Ar_Br9pgJhD=2sk=no7z4P5-hMmbKQ@mail.gmail.com>
 <CAA9v-_MoTAwTCZNwoctTBK58cgGysUm-QLmwC-bti_cx-zvTfA@mail.gmail.com>
Message-ID: <646522914.26272263.1761726622870.JavaMail.zimbra@univ-eiffel.fr>

This is an interesting case because i'm not sure the compiler should emit an error here. 

Currently the error occurs because as you said the call to super() is added after the call to throw. 

But throwing an exception in a constructor of an identity class is valid, and i do not see a reason why this behavior should not be the same in the case of a value class. 

regards, 
R?mi 

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Wednesday, October 29, 2025 5:30:23 AM
> Subject: Re: Compiler error message not clear for Valhalla EA 2

> The compiler error message goes away if I put a super(); as the first statement
> in the constructor. But still, that error message could be clearer.

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Wednesday, October 29, 2025 5:27:55 AM
> Subject: Compiler error message not clear for Valhalla EA 2

> Hello [ mailto:valhalla-dev at openjdk.org | @valhalla-dev ] ,

> While testing out the new Valhalla EA that came out a few days ago, I ran into
> the following compiler error.

> Here is a minified example.

> public value class abc
> {

> public abc()
> {
> throw new UnsupportedOperationException();
> }

> public static void someHelperMethod()
> {}

> }

> And here is the compiler error message.

> $ java --enable-preview abc.java
> abc.java:5: error: unreachable statement
> {
> ^
> 1 error
> error: compilation failed

> That location is the opening curly brace of the constructor.

> Can we have a more clear error message?

> Thank you for your time and consideration.
> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251029/bb37c7d5/attachment.htm>

From forax at univ-mlv.fr  Wed Oct 29 08:49:35 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 29 Oct 2025 09:49:35 +0100 (CET)
Subject: Compiler error message not clear for Valhalla EA 2
In-Reply-To: <646522914.26272263.1761726622870.JavaMail.zimbra@univ-eiffel.fr>
References: <CAA9v-_PfPObi0E6UhsD=Ar_Br9pgJhD=2sk=no7z4P5-hMmbKQ@mail.gmail.com>
 <CAA9v-_MoTAwTCZNwoctTBK58cgGysUm-QLmwC-bti_cx-zvTfA@mail.gmail.com>
 <646522914.26272263.1761726622870.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <1571345652.26285572.1761727775202.JavaMail.zimbra@univ-eiffel.fr>

> From: "Remi Forax" <forax at univ-mlv.fr>
> To: "David Alayachew" <davidalayachew at gmail.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Wednesday, October 29, 2025 9:30:22 AM
> Subject: Re: Compiler error message not clear for Valhalla EA 2

> This is an interesting case because i'm not sure the compiler should emit an
> error here.

> Currently the error occurs because as you said the call to super() is added
> after the call to throw.

> But throwing an exception in a constructor of an identity class is valid, and i
> do not see a reason why this behavior should not be the same in the case of a
> value class.

or perhaps javac should behave more like when there is an explicit call to 'return' 

value class V { 
V ( int v ) { 
return ; 
} 
} 

java: 'return' not allowed before explicit constructor invocation 

> regards,
> R?mi

regards, 
R?mi 

>> From: "David Alayachew" <davidalayachew at gmail.com>
>> To: "valhalla-dev" <valhalla-dev at openjdk.org>
>> Sent: Wednesday, October 29, 2025 5:30:23 AM
>> Subject: Re: Compiler error message not clear for Valhalla EA 2

>> The compiler error message goes away if I put a super(); as the first statement
>> in the constructor. But still, that error message could be clearer.

>> From: "David Alayachew" <davidalayachew at gmail.com>
>> To: "valhalla-dev" <valhalla-dev at openjdk.org>
>> Sent: Wednesday, October 29, 2025 5:27:55 AM
>> Subject: Compiler error message not clear for Valhalla EA 2

>> Hello [ mailto:valhalla-dev at openjdk.org | @valhalla-dev ] ,

>> While testing out the new Valhalla EA that came out a few days ago, I ran into
>> the following compiler error.

>> Here is a minified example.

>> public value class abc
>> {

>> public abc()
>> {
>> throw new UnsupportedOperationException();
>> }

>> public static void someHelperMethod()
>> {}

>> }

>> And here is the compiler error message.

>> $ java --enable-preview abc.java
>> abc.java:5: error: unreachable statement
>> {
>> ^
>> 1 error
>> error: compilation failed

>> That location is the opening curly brace of the constructor.

>> Can we have a more clear error message?

>> Thank you for your time and consideration.
>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251029/5f300c13/attachment-0001.htm>

From mhaessig at openjdk.org  Wed Oct 29 09:49:15 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Wed, 29 Oct 2025 09:49:15 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests [v3]
In-Reply-To: <VRvsy2zaA1kT3Cko4lilWustgnLyWOX6G9NiR1DxJTI=.e5aa92ec-5b06-444d-9ba1-23fa10a1ebf4@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
 <VRvsy2zaA1kT3Cko4lilWustgnLyWOX6G9NiR1DxJTI=.e5aa92ec-5b06-444d-9ba1-23fa10a1ebf4@github.com>
Message-ID: <x_OgXyTGuxU1VeMOfM8o9v_WA2mTGjYddzI2O4VgNjE=.c9008a98-0759-4090-be4c-1d21d3822c3a@github.com>

On Wed, 29 Oct 2025 07:52:01 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # Issue
>> 
>> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
>> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
>> 
>> # Cause
>> 
>> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
>> 
>> # Fix
>> 
>> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
>> 
>> # Testing
>> 
>> Tier 1-3
>> Worst-time compiler/valhalla JTReg tests went from 16min to <2min
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestion from @chhagedorn
>   
>   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

Marked as reviewed by mhaessig (no project role).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1708#pullrequestreview-3392460840

From dfenacci at openjdk.org  Wed Oct 29 12:12:59 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 29 Oct 2025 12:12:59 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests
In-Reply-To: <amwWiN90kQu_XQeYWFXHECLZLShB0uARUcZQISpKWag=.241c05ec-096a-40c0-9f1d-4084de05d1bc@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
 <amwWiN90kQu_XQeYWFXHECLZLShB0uARUcZQISpKWag=.241c05ec-096a-40c0-9f1d-4084de05d1bc@github.com>
Message-ID: <k3e3oTHW_dDAK_Ia40C5PifoBaUA2j310Q3SEiVHYsw=.37ed762a-f131-4351-918a-0502d1451967@github.com>

On Tue, 28 Oct 2025 14:52:40 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> # Issue
>> 
>> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
>> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
>> 
>> # Cause
>> 
>> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
>> 
>> # Fix
>> 
>> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
>> 
>> # Testing
>> 
>> Tier 1-3
>> Worst-time compiler/valhalla JTReg tests went from 16min to <2min
>
> That's an impressive improvement! Thanks for having a closer look at what we could do. Have you also played around with using Java threads instead (i.e. a `TestFramework` instance per thread that adds the scenario flags)?

Thanks @chhagedorn @mhaessig @TobiHartmann for your reviews!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1708#issuecomment-3461184391

From dfenacci at openjdk.org  Wed Oct 29 12:13:00 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 29 Oct 2025 12:13:00 GMT
Subject: [lworld] Integrated: 8369530: [lworld] Improve execution time of
 compiler tests
In-Reply-To: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
Message-ID: <V5RaM3W8MzKTn8KdmdscoN_43aStWk0J7kkTpjBB4LQ=.c48b35f9-8189-44ed-8254-a3a0c7d1490a@github.com>

On Tue, 28 Oct 2025 10:41:52 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> # Issue
> 
> Several Valhalla compiler specific tests are slow and this affects the overall execution time of lower tiers.
> [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) has already improved the situation by splitting multiple @run statements in compiler tests into separate @test blocks for several tests. There are nevertheless still a handful of tests that take up to a dozen minutes to finish.
> 
> # Cause
> 
> Most tests affected are using multiple IR-Framework scenarios to start tests with different flags. The tests are started sequentially, adding the execution time of each test. The problem is similar to [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437) but at IR-Framework level.
> 
> # Fix
> 
> We can parallelize the execution of scenarios similar to what has been done in the [fix](https://github.com/openjdk/valhalla/pull/1681/files) for [JDK-8369437](https://bugs.openjdk.org/browse/JDK-8369437). Unfortunately the IR-Framework doesn't allow tests to be run on different machines and there is no simple way to make it interact with JTReg in that way. So, as a provisional and minimalistic solution, scenarios are added and started one by one and run by individual JTReg `@test` entries.
> 
> # Testing
> 
> Tier 1-3
> Worst-time compiler/valhalla JTReg tests went from 16min to <2min

This pull request has now been integrated.

Changeset: cf32b275
Author:    Damon Fenacci <dfenacci at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cf32b2750cb3ccbb33c2d63868d47c69610b8882
Stats:     958 lines in 12 files changed: 929 ins; 0 del; 29 mod

8369530: [lworld] Improve execution time of compiler tests

Reviewed-by: mhaessig, thartmann, chagedorn

-------------

PR: https://git.openjdk.org/valhalla/pull/1708

From dfenacci at openjdk.org  Wed Oct 29 12:12:59 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 29 Oct 2025 12:12:59 GMT
Subject: [lworld] RFR: 8369530: [lworld] Improve execution time of compiler
 tests [v2]
In-Reply-To: <DVTol6jLkPelO5GIae7lzmHT2jHrSEBeKCulcqzDPXo=.897369bc-d1cb-4a55-be62-800b437c4133@github.com>
References: <Ku3ebq2QY2gt9ZsUoHgkZ4zKODlKLUZIuzHxvbsSZJ0=.65a8137f-d5d8-4164-92ff-f443151c1e7e@github.com>
 <nhUSGCOtNpQ-NuE8FdWYIkvmLMeP8QTydCayNRdzOAM=.9e3de0ba-ab5d-466c-b9a8-326130b4514d@github.com>
 <DVTol6jLkPelO5GIae7lzmHT2jHrSEBeKCulcqzDPXo=.897369bc-d1cb-4a55-be62-800b437c4133@github.com>
Message-ID: <bwmuAPiM8yVVRvr3D1yz9aoD6qbT8n5dpe_7GmQQqhA=.3a24d351-7d27-46a9-89e6-993c2132970f@github.com>

On Wed, 29 Oct 2025 06:24:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Out of curiosity, what's the different in machine time for the tiers?

I would have expected the time to be slightly higher but the difference seems anyway smaller than the variance due to external factors.

Tier1: 23h 58m -> 23h 53m
Tier2: 1d 09h 23m -> 1d 07h 48m
Tier3 : 2d 23h 53m -> 3d 00h 12m

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1708#issuecomment-3461180164

From dfenacci at openjdk.org  Wed Oct 29 12:15:58 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 29 Oct 2025 12:15:58 GMT
Subject: git: openjdk/valhalla: lworld: 8369530: [lworld] Improve execution
 time of compiler tests
Message-ID: <65e0af14-3d23-4a9a-a3d3-57b89fbe4026@openjdk.org>

Changeset: cf32b275
Branch: lworld
Author:    Damon Fenacci <dfenacci at openjdk.org>
Date:      2025-10-29 12:10:10 +0000
URL:       https://git.openjdk.org/valhalla/commit/cf32b2750cb3ccbb33c2d63868d47c69610b8882

8369530: [lworld] Improve execution time of compiler tests

Reviewed-by: mhaessig, thartmann, chagedorn

! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAllocationMergeAndFolding.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestBasicFunctionality.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestJNICalls.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMethodHandles.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableInlineTypes.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestOnStackReplacement.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestValueClasses.java


From coleenp at openjdk.org  Wed Oct 29 12:25:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 29 Oct 2025 12:25:01 GMT
Subject: [lworld] RFR: 8370217: [lworld] Crash in
 add_migrated_value_classes after merging JDK-8350550 [v2]
In-Reply-To: <dHf3NKVKuEvJyzOWejDYNLxBFnuG4YViDN3oxNGsQm4=.5ca62c73-7148-48d3-a497-805f3191430c@github.com>
References: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
 <dHf3NKVKuEvJyzOWejDYNLxBFnuG4YViDN3oxNGsQm4=.5ca62c73-7148-48d3-a497-805f3191430c@github.com>
Message-ID: <d7h5oEtNULz30yuomjIP-mxGK_JDgn2yhTw9lyflQr4=.a552bc7d-f6bb-4e40-9879-699c2b72b8e4@github.com>

On Tue, 28 Oct 2025 19:31:16 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The method add_migrated_value_classes() is being called in non-preview mode leading to an assert due to the expected classes not being present in the AOT cache. The check for `EnableValhalla` is replaced with a check for preview mode. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Coleen comments
>  - Merge branch 'lworld' into crash_8370217
>  - 8370217: [lworld] Crash in add_migrated_value_classes after merging JDK-8350550

Looks good!  Small nit though, maybe EnableValhalla should be before Arguments::enable_preview() since that's the pattern in the rest of the code that we're going to be looking for when we figure out how to resolve this option (remove or keep).

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1698#pullrequestreview-3393045926

From fparain at openjdk.org  Wed Oct 29 13:48:54 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 29 Oct 2025 13:48:54 GMT
Subject: [lworld] RFR: 8370217: [lworld] Crash in
 add_migrated_value_classes after merging JDK-8350550 [v2]
In-Reply-To: <dHf3NKVKuEvJyzOWejDYNLxBFnuG4YViDN3oxNGsQm4=.5ca62c73-7148-48d3-a497-805f3191430c@github.com>
References: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
 <dHf3NKVKuEvJyzOWejDYNLxBFnuG4YViDN3oxNGsQm4=.5ca62c73-7148-48d3-a497-805f3191430c@github.com>
Message-ID: <NDGA7nkDJ2KKpxM7l2RI0UwY_zNSUZHwSc2FAyUnWMU=.ee90f0a5-c842-4d93-aa9f-b22d21e5beaf@github.com>

On Tue, 28 Oct 2025 19:31:16 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The method add_migrated_value_classes() is being called in non-preview mode leading to an assert due to the expected classes not being present in the AOT cache. The check for `EnableValhalla` is replaced with a check for preview mode. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Coleen comments
>  - Merge branch 'lworld' into crash_8370217
>  - 8370217: [lworld] Crash in add_migrated_value_classes after merging JDK-8350550

Marked as reviewed by fparain (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1698#pullrequestreview-3393530276

From duke at openjdk.org  Wed Oct 29 14:05:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 29 Oct 2025 14:05:31 GMT
Subject: RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode [v11]
In-Reply-To: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
References: <Nl6cNyOr9YumR-X8G-IEQjpZSOPkjDSgPylA7g1gvew=.4d9b4a51-c06d-4321-9c58-11e414d8ed3d@github.com>
Message-ID: <bm1D_VxtoDknSvtLzeI8uoGVVCYAUpfClQtDIRrTQ1I=.8455d8d2-b0cd-49da-80a6-de262bb0cee2@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
> 
> Compare and review this against https://github.com/openjdk/valhalla/pull/1619.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  fixing tests after refactoring

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1621/files
  - new: https://git.openjdk.org/valhalla/pull/1621/files/a6c83b18..67e07af2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=10
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1621&range=09-10

  Stats: 28 lines in 2 files changed: 0 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/valhalla/pull/1621.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1621/head:pull/1621

PR: https://git.openjdk.org/valhalla/pull/1621

From dsimms at openjdk.org  Wed Oct 29 14:27:57 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 29 Oct 2025 14:27:57 GMT
Subject: [lworld] Withdrawn: Not intended for checkin
In-Reply-To: <rEBn52jSn2JvCSV3e5f0jJviGdlnJdG4jOdwUH-QHpA=.e027e96f-cde3-4ce1-bb42-1abb44c1e251@github.com>
References: <rEBn52jSn2JvCSV3e5f0jJviGdlnJdG4jOdwUH-QHpA=.e027e96f-cde3-4ce1-bb42-1abb44c1e251@github.com>
Message-ID: <fiOZw2STbWnH_VNXE0kUml2HtlK1RIX9nBYhU7RhamQ=.5d9c7993-bdc1-42bc-804d-8623326e1d95@github.com>

On Mon, 27 Oct 2025 15:29:04 GMT, David Simms <dsimms at openjdk.org> wrote:

> Just a test

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/valhalla/pull/1706

From duke at openjdk.org  Wed Oct 29 15:46:25 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 29 Oct 2025 15:46:25 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v10]
In-Reply-To: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
Message-ID: <drFK1OD_8sCioEYOiQJXWmKp3HAuq2vJ8YPMV6SyKN0=.c7915bf9-42b8-4bbb-93c0-05adac51bedc@github.com>

> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
> 
> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
> 
> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618

David Beaumont has updated the pull request incrementally with two additional commits since the last revision:

 - remove ImageReaderFactory.java (again)
 - Reapplying feedback changes.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1619/files
  - new: https://git.openjdk.org/valhalla/pull/1619/files/5445f160..3253307a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1619&range=09
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1619&range=08-09

  Stats: 132 lines in 2 files changed: 0 ins; 106 del; 26 mod
  Patch: https://git.openjdk.org/valhalla/pull/1619.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1619/head:pull/1619

PR: https://git.openjdk.org/valhalla/pull/1619

From matsaave at openjdk.org  Wed Oct 29 15:52:49 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 29 Oct 2025 15:52:49 GMT
Subject: [lworld] RFR: 8370217: [lworld] Crash in
 add_migrated_value_classes after merging JDK-8350550 [v2]
In-Reply-To: <d7h5oEtNULz30yuomjIP-mxGK_JDgn2yhTw9lyflQr4=.a552bc7d-f6bb-4e40-9879-699c2b72b8e4@github.com>
References: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
 <dHf3NKVKuEvJyzOWejDYNLxBFnuG4YViDN3oxNGsQm4=.5ca62c73-7148-48d3-a497-805f3191430c@github.com>
 <d7h5oEtNULz30yuomjIP-mxGK_JDgn2yhTw9lyflQr4=.a552bc7d-f6bb-4e40-9879-699c2b72b8e4@github.com>
Message-ID: <N8BfkOCUFLN34LpXAd0y84mBUAXoiAMm9KpQWxqa3Q4=.94d4638a-33a2-460a-85f8-ef6a7df72727@github.com>

On Wed, 29 Oct 2025 12:22:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Looks good! Small nit though, maybe EnableValhalla should be before Arguments::enable_preview() since that's the pattern in the rest of the code that we're going to be looking for when we figure out how to resolve this option (remove or keep).

I'm not sure what you mean by this since the other cases that check for preview and valhalla are in this order:
`Arguments::enable_preview() && EnableValhalla`

You can see that pattern in cdsConfig and arguments.cpp.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1698#issuecomment-3462394144

From daniel.smith at oracle.com  Wed Oct 29 17:22:14 2025
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 29 Oct 2025 17:22:14 +0000
Subject: Compiler error message not clear for Valhalla EA 2
In-Reply-To: <646522914.26272263.1761726622870.JavaMail.zimbra@univ-eiffel.fr>
References: <CAA9v-_PfPObi0E6UhsD=Ar_Br9pgJhD=2sk=no7z4P5-hMmbKQ@mail.gmail.com>
 <CAA9v-_MoTAwTCZNwoctTBK58cgGysUm-QLmwC-bti_cx-zvTfA@mail.gmail.com>
 <646522914.26272263.1761726622870.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <D503E9F2-0816-405A-8DB8-3D76CF673963@oracle.com>

> On Oct 29, 2025, at 1:30?AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> This is an interesting case because i'm not sure the compiler should emit an error here.
> 
> Currently the error occurs because as you said the call to super() is added after the call to throw.
> 
> But throwing an exception in a constructor of an identity class is valid, and i do not see a reason why this behavior should not be the same in the case of a value class.

It seems appropriate to call it an error, although the error message is confusing. This is a standard reachability check, nothing fundamentally new.

But we have two spec problems:

1) JLS doesn't say that explicit constructor invocations must be reachable, although they really ought to be?they're not formally "statements", but they should be subject to the same rules. I filed a bug:

https://bugs.openjdk.org/browse/JDK-8370899

2) JEP 401 introduces the possibility of unreachable *implicit* constructor invocations, and these need to be accounted for as well. I think it probably makes sense to treat these just like explicit constructor invocations, but I guess there could be an argument that reachability shouldn't apply to implicit things... (I noticed that the implicit code at the end of a compact record constructor is not checked, in the spec or javac, for reachability.)

---

We do have practical use cases for constructors that always throw, so we should be careful not to break those cases. But I'm not sure it would make any sense to use the 'value' keyword with a class whose constructor always throws.


From amenkov at openjdk.org  Wed Oct 29 18:38:51 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 29 Oct 2025 18:38:51 GMT
Subject: [lworld] Integrated: 8367711: [lworld] JDI test updates
In-Reply-To: <7IB6ODxOTYQy_u-Hjf-hNAEIqLCwsElPuH9UPKoFT-0=.86147cf3-e35a-4ac9-9e57-8939c5ee92b1@github.com>
References: <7IB6ODxOTYQy_u-Hjf-hNAEIqLCwsElPuH9UPKoFT-0=.86147cf3-e35a-4ac9-9e57-8939c5ee92b1@github.com>
Message-ID: <s5L2fea57qY0XqibhqdcrJJlp_PHUwZK1yZZv3REQAM=.5462aa91-4ec0-439c-b985-c466b7a74650@github.com>

On Sat, 25 Oct 2025 00:42:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Update for JDI tests.
> This is follow up for [1519](https://github.com/openjdk/valhalla/pull/1519) (feedback was added after integration)

This pull request has now been integrated.

Changeset: 8ad1f114
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8ad1f114f8f3bbeb2471d2d96d1f8d78364e1f37
Stats:     36 lines in 3 files changed: 13 ins; 9 del; 14 mod

8367711: [lworld] JDI test updates

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.org/valhalla/pull/1702

From matsaave at openjdk.org  Wed Oct 29 19:26:15 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 29 Oct 2025 19:26:15 GMT
Subject: [lworld] RFR: 8370217: [lworld] Crash in
 add_migrated_value_classes after merging JDK-8350550 [v2]
In-Reply-To: <d7h5oEtNULz30yuomjIP-mxGK_JDgn2yhTw9lyflQr4=.a552bc7d-f6bb-4e40-9879-699c2b72b8e4@github.com>
References: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
 <dHf3NKVKuEvJyzOWejDYNLxBFnuG4YViDN3oxNGsQm4=.5ca62c73-7148-48d3-a497-805f3191430c@github.com>
 <d7h5oEtNULz30yuomjIP-mxGK_JDgn2yhTw9lyflQr4=.a552bc7d-f6bb-4e40-9879-699c2b72b8e4@github.com>
Message-ID: <BuUwf3RYqy5PdMpPVqIPUcynsTi3D8AjA_qHGSVeGa8=.4cb20256-ce65-480d-bd7b-e5d94810e089@github.com>

On Wed, 29 Oct 2025 12:22:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Coleen comments
>>  - Merge branch 'lworld' into crash_8370217
>>  - 8370217: [lworld] Crash in add_migrated_value_classes after merging JDK-8350550
>
> Looks good!  Small nit though, maybe EnableValhalla should be before Arguments::enable_preview() since that's the pattern in the rest of the code that we're going to be looking for when we figure out how to resolve this option (remove or keep).

Thanks for the reviews @coleenp and @fparain!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1698#issuecomment-3463459058

From matsaave at openjdk.org  Wed Oct 29 19:26:17 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 29 Oct 2025 19:26:17 GMT
Subject: [lworld] Integrated: 8370217: [lworld] Crash in
 add_migrated_value_classes after merging JDK-8350550
In-Reply-To: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
References: <KEe7yYmrlKyeDSagsF5oxMx7MJ5JrNV7HzBHi86TSdg=.5847922c-819b-4970-ba49-d17f3bb852b3@github.com>
Message-ID: <4QWi-vr83aCG5NF8BnC0VR5jeAg8mEukx63BW_syKGk=.c2745315-1a10-4e1d-a9dd-e4f80ef4649c@github.com>

On Thu, 23 Oct 2025 20:18:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The method add_migrated_value_classes() is being called in non-preview mode leading to an assert due to the expected classes not being present in the AOT cache. The check for `EnableValhalla` is replaced with a check for preview mode. Verified with tier 1-5 tests.

This pull request has now been integrated.

Changeset: a60678c0
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a60678c089387f1a72f176008f9bfef9fcad947b
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8370217: [lworld] Crash in add_migrated_value_classes after merging JDK-8350550

Reviewed-by: coleenp, fparain

-------------

PR: https://git.openjdk.org/valhalla/pull/1698

From sergey.kuksenko at oracle.com  Wed Oct 29 19:44:16 2025
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Wed, 29 Oct 2025 19:44:16 +0000
Subject: Raytracing Experience Report
In-Reply-To: <CA+NR86j08y06gA74qZs4GsHm_Ch9SmYnEfxe9+2234sdgQDBfw@mail.gmail.com>
References: <CA+NR86j08y06gA74qZs4GsHm_Ch9SmYnEfxe9+2234sdgQDBfw@mail.gmail.com>
Message-ID: <CH3PR10MB7833F23CBEA8F3B242D994999BFAA@CH3PR10MB7833.namprd10.prod.outlook.com>

Hi Ethan,

Thank you for the information. Your example and the code are pretty straightforward, and I was able to repeat and diagnose the issue.

The fact is, the performance issue is not directly related to value classes. The problem is that HittableList::hit method (invoked at Camera::rayColor) was inlined by JIT in the non-value version and wasn't inlined in the value classes version.
When you inline that invocation manually, you should get the same performance for both versions.
HittableList::hit was not inlined in the value classes version because value classes resulted in a different code size and changed the inline heuristics. It's a mainline issue; you'll encounter it quite rarely. Current inline heuristics work well in 99% of cases, and you should be very lucky (or unlucky) to get it in real life.

Best regards,
Sergey Kuksenko



________________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Ethan McCue <ethan at mccue.dev>
Sent: Monday, October 27, 2025 5:08 PM
To: valhalla-dev at openjdk.org
Subject: Raytracing Experience Report

Hi all,

I have been following along in the "Ray Tracing in a Weekend" book and trying to make as many classes as possible value classes. (Vec3, Ray, etc.)

https://github.com/bowbahdoe/raytracer

https://raytracing.github.io/books/RayTracingInOneWeekend.html

(without value classes)

time java --enable-preview --class-path build/classes Main > image.ppm

real 4m33.190s
user 4m28.984s
sys 0m5.511s

(with value classes)

time java --enable-preview --class-path build/classes Main > image.ppm

real 3m54.623s
user 3m52.205s
sys 0m2.064s

So by the end the version using value classes beats the version without them by ~14% using unscientific measurements.

But that is at the end, running the ray tracer on a relatively large scene with all the features turned on. Before that point there were some checkpoints where using value classes performed noticeably worse than the equivalent code sans the value modifier

https://github.com/bowbahdoe/raytracer/tree/no-value-faster

real 1m22.172s
user 1m9.871s
sys 0m12.951s

https://github.com/bowbahdoe/raytracer/tree/with-value-slower

real 3m34.440s
user 3m19.656s
sys 0m14.870s

So for some reason just adding value to the records/classes makes the program run a over 2x as slow.

https://github.com/bowbahdoe/raytracer/compare/no-value-faster...with-value-slower

Is there some intuition that explains this? I am on a stock M1 Arm Mac.

From rriggs at openjdk.org  Wed Oct 29 21:15:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Oct 2025 21:15:35 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v10]
In-Reply-To: <drFK1OD_8sCioEYOiQJXWmKp3HAuq2vJ8YPMV6SyKN0=.c7915bf9-42b8-4bbb-93c0-05adac51bedc@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <drFK1OD_8sCioEYOiQJXWmKp3HAuq2vJ8YPMV6SyKN0=.c7915bf9-42b8-4bbb-93c0-05adac51bedc@github.com>
Message-ID: <b2S9sAleFXdlLCJFSLl2MeG4eBMsSPhUhJueTb4tMIE=.ecacb25f-ee4b-4e4e-bd73-2502aa32ad30@github.com>

On Wed, 29 Oct 2025 15:46:25 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
>> 
>> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618
>
> David Beaumont has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove ImageReaderFactory.java (again)
>  - Reapplying feedback changes.

Looks ok.

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1619#pullrequestreview-3390750727

From rriggs at openjdk.org  Wed Oct 29 21:15:41 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Oct 2025 21:15:41 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v9]
In-Reply-To: <FBX9lTVmfUiXF8WKJ3HCelha85LFqbA42FIl5yW9zYo=.296882ee-f8ff-427f-9494-277713779621@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <FBX9lTVmfUiXF8WKJ3HCelha85LFqbA42FIl5yW9zYo=.296882ee-f8ff-427f-9494-277713779621@github.com>
Message-ID: <acIBTWZINoNzOEvChLyu_9mhitMW1gps2V8bRxECUm8=.93913461-8c62-4b02-a8c6-d05aec157155@github.com>

On Fri, 24 Oct 2025 17:05:58 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Java changes for supporting preview mode when preview mode resources (with new location flags) are available.
>> 
>> At the moment, this code will operate on non-preview jimage files (1.0) and act as if no preview resources are available by virtue of the default value for missing attributes and package flags being zero (which matches jimage 1.0).
>> 
>> This should be reviewed on top of https://github.com/openjdk/valhalla/pull/1618
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback changes

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 1:

> 1: /*

It seems odd to only have PreviewMode.DISABLED tests in ImageReaderTest.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2471002319

From rriggs at openjdk.org  Wed Oct 29 21:15:37 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Oct 2025 21:15:37 GMT
Subject: [lworld] RFR: 8368333: [lworld] Add preview mode to ImageReader
 and JRT file-system [v7]
In-Reply-To: <RcV9JYxCYZSDkckXnora8V0yvXkQZ9OHep0hHt-pPJM=.3fd34f9d-9c4a-4efd-8b50-fbf67a450978@github.com>
References: <Qs-Z4_hlO8C-E_-MDHadXVpn2JFv7qc5Xb_sLKcrVQI=.98be8bfb-3b83-4a54-97bc-da63285db05d@github.com>
 <64gGqzvKpvXvpTd6ihaE8f2xKgo8vK5Yj8mv0wK7pfg=.624ce55e-a125-4ceb-b9b7-6d9a9f873b71@github.com>
 <7jZBKEu1LgAOUdMBe0n76Oeik4QfDLvMR4wa30UKBXU=.4787e70c-28b9-4091-990b-5425a19233c2@github.com>
 <RcV9JYxCYZSDkckXnora8V0yvXkQZ9OHep0hHt-pPJM=.3fd34f9d-9c4a-4efd-8b50-fbf67a450978@github.com>
Message-ID: <Yc97Yw47B5prKvVIb1zlXuaLPms4BW1qUyMN130Bw6Q=.7d5803b2-9d10-4a13-a794-30d5ac7eb25c@github.com>

On Wed, 22 Oct 2025 19:38:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 282:
>> 
>>> 280:         // preview-only nodes. This is used to add preview-only content to
>>> 281:         // directories as they are completed.
>>> 282:         private final HashMap<String, Directory> previewDirectoriesToMerge;
>> 
>> Can this be cleared or freed after the ImageReader is open. Its no longer needed.
>
> It's used when directories are completed (as stated in the comment):
> 
> 
>     List<Node> previewOnlyNodes = getPreviewNodesToMerge(dir);
>     ...
>     children.addAll(previewOnlyNodes);
> 
> 
> This is so that a preview only directory (and all its content) appears correctly in its parent's child list.

So it is no longer needed after that.  
Since it is a field of a SharedImageReader that will be kept open for a while, it could be cleared to free the entries and make it clear the map is no longer used.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1619#discussion_r2471012817