From thartmann at openjdk.org  Tue Jul  1 08:30:57 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 1 Jul 2025 08:30:57 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with -XX:ForceNonTearable=*
Message-ID: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>

For test method `testFieldLoad1` the graph looks like this after parsing:
![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)

Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)

Later, a precedence edge from the membar to the load (now named `15 LoadL`) is added, leading to an unschedulable graph:
![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)

[JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them which is incorrect.

For now, I disabled skipping past `MemBarCPUOrders` in `MemNode::optimize_simple_memory_chain` and filed [JDK-8361145](https://bugs.openjdk.org/browse/JDK-8361145) for a follow-up investigation.

Thanks,
Tobias

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

Commit messages:
 - Some more problem listing
 - Problem listing for JDK-8361082
 - More tests
 - Added summary to test
 - 8359345: [lworld] C2 crashes with -XX:ForceNonTearable=*

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

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

From qamai at openjdk.org  Tue Jul  1 08:30:58 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 1 Jul 2025 08:30:58 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=*
In-Reply-To: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
Message-ID: <BBNUNAzrNjiSwlYNb1URuFFE0U631AFTdcBaktpG7iM=.a4285869-5967-4649-8d65-c3e5201f5f67@github.com>

On Mon, 30 Jun 2025 12:20:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> For test method `testFieldLoad1` the graph looks like this after parsing:
> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
> 
> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
> 
> Later, a precedence edge from the membar to the load (now named `15 LoadL`) is added, leading to an unschedulable graph:
> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
> 
> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them which is incorrect.
> 
> For now, I disabled skipping past `MemBarCPUOrders` in `MemNode::optimize_simple_memory_chain` and filed [JDK-8361145](https://bugs.openjdk.org/browse/JDK-8361145) for a follow-up investigation.
> 
> Thanks,
> Tobias

I thought final fields should not have anti-dependency? I assume this is where the precedence edge comes from.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1494#issuecomment-3020576882

From qamai at openjdk.org  Tue Jul  1 08:33:56 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 1 Jul 2025 08:33:56 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=*
In-Reply-To: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
Message-ID: <43MICU6Uym9y8gHOXXFNDJ8jvIXrmcHL0v5fIBNjasY=.2559e76c-6eb4-4052-8cb7-6cc3251b2fe5@github.com>

On Mon, 30 Jun 2025 12:20:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> For test method `testFieldLoad1` the graph looks like this after parsing:
> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
> 
> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
> 
> Later, a precedence edge from the membar to the load (now named `15 LoadL`) is added, leading to an unschedulable graph:
> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
> 
> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them which is incorrect.
> 
> For now, I disabled skipping past `MemBarCPUOrders` in `MemNode::optimize_simple_memory_chain` and filed [JDK-8361145](https://bugs.openjdk.org/browse/JDK-8361145) for a follow-up investigation.
> 
> Thanks,
> Tobias

Hmmm I think this is not correct. At `Before matching`, `46 LoadL` is a load from `MyValue2.l0`, which has `is_rewritable == false`, but afterward, at `After matching`, `15 loadL` loses this information, why?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1494#issuecomment-3022620079

From thartmann at openjdk.org  Tue Jul  1 08:33:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 1 Jul 2025 08:33:56 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=*
In-Reply-To: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
Message-ID: <Zx9Rpn_n5LBssnzbdeYfJgY6rwa7cmTQe3AZaiVQN-U=.17675098-62e5-4335-b1d0-ffc8cb59dbea@github.com>

On Mon, 30 Jun 2025 12:20:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> For test method `testFieldLoad1` the graph looks like this after parsing:
> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
> 
> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
> 
> Later, a precedence edge from the membar to the load (now named `15 LoadL`) is added, leading to an unschedulable graph:
> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
> 
> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them which is incorrect.
> 
> For now, I disabled skipping past `MemBarCPUOrders` in `MemNode::optimize_simple_memory_chain` and filed [JDK-8361145](https://bugs.openjdk.org/browse/JDK-8361145) for a follow-up investigation.
> 
> Thanks,
> Tobias

Thanks for your comments Quan-Anh, I missed them earlier. Let me double-check!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1494#issuecomment-3022626693

From qamai at openjdk.org  Tue Jul  1 08:46:57 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 1 Jul 2025 08:46:57 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=*
In-Reply-To: <Zx9Rpn_n5LBssnzbdeYfJgY6rwa7cmTQe3AZaiVQN-U=.17675098-62e5-4335-b1d0-ffc8cb59dbea@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
 <Zx9Rpn_n5LBssnzbdeYfJgY6rwa7cmTQe3AZaiVQN-U=.17675098-62e5-4335-b1d0-ffc8cb59dbea@github.com>
Message-ID: <QllESTClIrZ8e96Cy5ObHQOcMxJHikusIY9Ez7KXthM=.a63f0f8f-3dfd-4337-9677-1e669adb161d@github.com>

On Tue, 1 Jul 2025 08:30:59 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> For test method `testFieldLoad1` the graph looks like this after parsing:
>> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
>> 
>> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
>> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
>> 
>> Later, a precedence edge from the membar to the load (now named `15 LoadL`) is added, leading to an unschedulable graph:
>> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
>> 
>> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them which is incorrect.
>> 
>> For now, I disabled skipping past `MemBarCPUOrders` in `MemNode::optimize_simple_memory_chain` and filed [JDK-8361145](https://bugs.openjdk.org/browse/JDK-8361145) for a follow-up investigation.
>> 
>> Thanks,
>> Tobias
>
> Thanks for your comments Quan-Anh, I missed them earlier. Let me double-check!

@TobiHartmann I think I know why. `CastI2N` returns a `TypeNarrowOop::BOTTOM`, which is then casted to the correct type at `DecodeNNode`. However, at matching, we skip through the `DecodeN`. As a result, `15 loadL` is a load from `TypeOopPtr::BOTTOM + 16` which the alias cannot be known to be immutable. I think this mismatch type can happen easily due to dropping `CastPP` at the end of optimization. I suggest clearing `Flag_needs_anti_dependence_check` when we rewire the node at `MemNode::optimize_simple_memory_chain`, or even clearing them at creation if their `adr_type` is non-rewritable.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1494#issuecomment-3022722269

From thartmann at openjdk.org  Tue Jul  1 09:05:00 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 1 Jul 2025 09:05:00 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=*
In-Reply-To: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
Message-ID: <HEin1Gbvxv9Ludfzcl3ORWVJhdNw3AfpnzYTWv34Hqw=.0b0a1dd9-fac9-4166-a8c0-731dda5b1935@github.com>

On Mon, 30 Jun 2025 12:20:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> For test method `testFieldLoad1` the graph looks like this after parsing:
> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
> 
> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
> 
> Later, a precedence edge from the membar to the load (now named `15 LoadL`) is added, leading to an unschedulable graph:
> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
> 
> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them which is incorrect.
> 
> For now, I disabled skipping past `MemBarCPUOrders` in `MemNode::optimize_simple_memory_chain` and filed [JDK-8361145](https://bugs.openjdk.org/browse/JDK-8361145) for a follow-up investigation.
> 
> Thanks,
> Tobias

Good catch! Maybe we should just make the `CastI2N` a `TypeNode` and propagate the right type.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1494#issuecomment-3022816035

From thartmann at openjdk.org  Tue Jul  1 09:13:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 1 Jul 2025 09:13:56 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=*
In-Reply-To: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
Message-ID: <o7C3t4XMNEw3f3oaWVRBLwuSHgdJld3ytVD0pTcr-P4=.5d254120-b3fb-4608-adee-c411141240a0@github.com>

On Mon, 30 Jun 2025 12:20:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> For test method `testFieldLoad1` the graph looks like this after parsing:
> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
> 
> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
> 
> Later, a precedence edge from the membar to the load (now named `15 LoadL`) is added, leading to an unschedulable graph:
> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
> 
> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them which is incorrect.
> 
> For now, I disabled skipping past `MemBarCPUOrders` in `MemNode::optimize_simple_memory_chain` and filed [JDK-8361145](https://bugs.openjdk.org/browse/JDK-8361145) for a follow-up investigation.
> 
> Thanks,
> Tobias

Quick prototype looks promising, I'll give that a try.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1494#issuecomment-3022864561

From thartmann at openjdk.org  Tue Jul  1 10:21:02 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 1 Jul 2025 10:21:02 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=* [v2]
In-Reply-To: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
Message-ID: <prO1rnjdPd68_c6668QAJvlkZk2BJvgD2fMBuKDZG-U=.cfbccb99-f72f-45fa-8909-67d581564778@github.com>

> For test method `testFieldLoad1` the graph looks like this after parsing:
> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
> 
> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
> 
> Later in `PhaseCFG::insert_anti_dependences`, a precedence edge from the membar to the load (now named `15 LoadL`) is added, because the type of the `CastI2N` is `TypeNarrowOop::BOTTOM` and thus `AliasType::is_rewritable` is true (it should be false). The resulting graph is unschedulable:
> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
> 
> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them and an anti-dependency will be added.
> 
> The fix is to change `CastI2NNode` to a `TypeNode` that carries the exact type. This ways we can also avoid the `CastPPNode` after the decode.
> 
> Thanks,
> Tobias

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

  New fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1494/files
  - new: https://git.openjdk.org/valhalla/pull/1494/files/a7948605..d64bc05c

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

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

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

From thartmann at openjdk.org  Tue Jul  1 10:21:02 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 1 Jul 2025 10:21:02 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=*
In-Reply-To: <QllESTClIrZ8e96Cy5ObHQOcMxJHikusIY9Ez7KXthM=.a63f0f8f-3dfd-4337-9677-1e669adb161d@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
 <Zx9Rpn_n5LBssnzbdeYfJgY6rwa7cmTQe3AZaiVQN-U=.17675098-62e5-4335-b1d0-ffc8cb59dbea@github.com>
 <QllESTClIrZ8e96Cy5ObHQOcMxJHikusIY9Ez7KXthM=.a63f0f8f-3dfd-4337-9677-1e669adb161d@github.com>
Message-ID: <Ve__w7HNr99X3Ce2cKCmlGugPk6C1KNBpwGfmEIqFPs=.c8ba2541-d061-4b51-a3e0-816171802df5@github.com>

On Tue, 1 Jul 2025 08:44:36 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Thanks for your comments Quan-Anh, I missed them earlier. Let me double-check!
>
> @TobiHartmann I think I know why. `CastI2N` returns a `TypeNarrowOop::BOTTOM`, which is then casted to the correct type at `DecodeNNode`. However, at matching, we skip through the `DecodeN`. As a result, `15 loadL` is a load from `TypeOopPtr::BOTTOM + 16` which the alias cannot be known to be immutable. I think this mismatch type can happen easily due to dropping `CastPP` at the end of optimization. I suggest clearing `Flag_needs_anti_dependence_check` when we rewire the node at `MemNode::optimize_simple_memory_chain`, or even clearing them at creation if their `adr_type` is non-rewritable.

I'll pushed this and updated the description. Will run some more testing. Thanks again for looking into this, @merykitty.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1494#issuecomment-3023187269

From thartmann at openjdk.org  Tue Jul  1 12:38:02 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 1 Jul 2025 12:38:02 GMT
Subject: [lworld] RFR: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=* [v2]
In-Reply-To: <prO1rnjdPd68_c6668QAJvlkZk2BJvgD2fMBuKDZG-U=.cfbccb99-f72f-45fa-8909-67d581564778@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
 <prO1rnjdPd68_c6668QAJvlkZk2BJvgD2fMBuKDZG-U=.cfbccb99-f72f-45fa-8909-67d581564778@github.com>
Message-ID: <kyV-0AUpfDUr5D5lFJJ6VhM6Ziw0ihK6W0pvcSayeUM=.d97b15be-e22c-41c9-8654-243144f71991@github.com>

On Tue, 1 Jul 2025 10:21:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> For test method `testFieldLoad1` the graph looks like this after parsing:
>> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
>> 
>> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
>> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
>> 
>> Later in `PhaseCFG::insert_anti_dependences`, a precedence edge from the membar to the load (now named `15 LoadL`) is added, because the type of the `CastI2N` is `TypeNarrowOop::BOTTOM` and thus `AliasType::is_rewritable` is true (it should be false). The resulting graph is unschedulable:
>> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
>> 
>> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them and an anti-dependency will be added.
>> 
>> The fix is to change `CastI2NNode` to a `TypeNode` that carries the exact type. This ways we can also avoid the `CastPPNode` after the decode.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New fix

Testing is all green. I'm integrating this to get the CI clean. Thanks again!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1494#issuecomment-3023832618

From thartmann at openjdk.org  Tue Jul  1 12:38:03 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 1 Jul 2025 12:38:03 GMT
Subject: [lworld] Integrated: 8359345: [lworld] C2 crashes with
 -XX:ForceNonTearable=*
In-Reply-To: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
References: <AxzAxuKdjSXW3IirA-bKZPcwdt0GluhbuoZ2JM3j4K0=.3e6f7192-2519-40b1-b4d2-a2c5b5c0da7f@github.com>
Message-ID: <ejSLeeV28qFNAfhnXGOEz_q5adK3uXrM12_MJZzB4hc=.b787e57a-bc20-4cd6-90bb-139946f7aca3@github.com>

On Mon, 30 Jun 2025 12:20:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> For test method `testFieldLoad1` the graph looks like this after parsing:
> ![Screenshot from 2025-06-30 13-42-44](https://github.com/user-attachments/assets/94726f40-8260-47ab-86e1-a47b074a6929)
> 
> Now since [JDK-8354068](https://bugs.openjdk.org/browse/JDK-8354068) `MemNode::optimize_simple_memory_chain` rewires the memory input of strict field load `46 LoadL` to before the membar:
> ![Screenshot from 2025-06-30 15-06-13](https://github.com/user-attachments/assets/b8ac826e-1426-4212-8567-0aa1c8da5ad9)
> 
> Later in `PhaseCFG::insert_anti_dependences`, a precedence edge from the membar to the load (now named `15 LoadL`) is added, because the type of the `CastI2N` is `TypeNarrowOop::BOTTOM` and thus `AliasType::is_rewritable` is true (it should be false). The resulting graph is unschedulable:
> ![Screenshot from 2025-06-30 13-37-59](https://github.com/user-attachments/assets/ea1e5361-8863-4ebc-b733-155bc53bce72)
> 
> [JDK-8354981](https://bugs.openjdk.org/browse/JDK-8354981) added these `MemBarCPUOrders` around flat, atomic stores and then [JDK-8357474](https://bugs.openjdk.org/browse/JDK-8357474) also added them around loads. The same problem exists for `MemBarCPUOrders` emitted by stores. The memory input of following loads will be wired around them and an anti-dependency will be added.
> 
> The fix is to change `CastI2NNode` to a `TypeNode` that carries the exact type. This ways we can also avoid the `CastPPNode` after the decode.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: a565d8be
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a565d8bee48e4cf6bbcbb7e360c94a05fed02e3f
Stats:     290 lines in 4 files changed: 285 ins; 2 del; 3 mod

8359345: [lworld] C2 crashes with -XX:ForceNonTearable=*

Co-authored-by: Quan Anh Mai <qamai at openjdk.org>

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

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

From coleenp at openjdk.org  Tue Jul  1 20:00:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 20:00:30 GMT
Subject: [lworld] RFR: [lworld] Remove LockingMode from test
Message-ID: <Zs3-wWwOpXHMUx8JLdkpQXxGb0DKpMvlMffM-TahMYc=.9615fc87-618c-4c8d-adcd-4ae03b9c6b81@github.com>

See issue - the LockingMode flags will be removed in mainline, so adjusting this test.
Tested with the test.

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

Commit messages:
 - [lworld] Remove LockingMode from test

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

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

From rriggs at openjdk.org  Tue Jul  1 20:03:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Jul 2025 20:03:04 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v11]
In-Reply-To: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
Message-ID: <oJ5yL1GGh8TQzGeG3SO0NuR6XcRzio9KChaKwZogQo0=.77c8f983-a906-4dff-9493-9f706d89d5b7@github.com>

> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
> Simplified WeakHashMap javadoc updates for IdentityException. 
> Added note to System.identityHashCode to include value objects.
> Added to class javadoc for IdentityHashMap for value objects.

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

  Remove empty <p>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1327/files
  - new: https://git.openjdk.org/valhalla/pull/1327/files/023f4f81..b044e43e

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

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

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

From rriggs at openjdk.org  Tue Jul  1 20:03:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Jul 2025 20:03:04 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v10]
In-Reply-To: <ViIXa4HrmV-lHFFYjvjmmAlM2Y1LUa559mBhKG0sp2k=.1e4021c2-efd8-42f2-8eee-20c254d2fc85@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
 <ViIXa4HrmV-lHFFYjvjmmAlM2Y1LUa559mBhKG0sp2k=.1e4021c2-efd8-42f2-8eee-20c254d2fc85@github.com>
Message-ID: <r-w0Qtp1-jZW-PuaKUwCbHUuwFvO82SY1DnzystXB94=.f29e9be3-7375-4806-8eb0-00fe14b0a7e2@github.com>

On Thu, 26 Jun 2025 19:38:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
>> Simplified WeakHashMap javadoc updates for IdentityException. 
>> Added note to System.identityHashCode to include value objects.
>> Added to class javadoc for IdentityHashMap for value objects.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correctly describe computation of identityHashCode

If there are no more comments, I'll push this into Valhalla tomorrow.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1327#issuecomment-3025332991

From qamai at openjdk.org  Wed Jul  2 07:45:55 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 2 Jul 2025 07:45:55 GMT
Subject: [lworld] Integrated: 8336003: [lworld] TestLWorld::test151 triggers
 "Should have been buffered" assert
In-Reply-To: <LbfuN20bii5_XY-zAhkXX6FNd35Wd6f9KdTQ_T84M3o=.4500d3d6-64ad-42f5-af1d-c11e415c180b@github.com>
References: <LbfuN20bii5_XY-zAhkXX6FNd35Wd6f9KdTQ_T84M3o=.4500d3d6-64ad-42f5-af1d-c11e415c180b@github.com>
Message-ID: <22z5drfE58p3KphidDCa1Aouv9q44EC1-PcwtGcwLhQ=.bf275e52-1457-44db-b4cf-b120e0e6c9fe@github.com>

On Fri, 13 Jun 2025 22:53:32 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue here is that the IGVN cannot deduce that the `IsBuffered` input is a constant 1. This is because after the `InlineTypeNode` is pushed down through a `Phi` cluster, the `IsBuffered` input is a `Phi` cluster with loop phis, which makes it difficult for the IGVN to see through. A solution is to do another round of CCP after loop opts, but it is rather a big hammer. In this PR, I propose to make it possible for a `PhiNode` to look through its `Phi` inputs to discover the unique non-phi input of a `Phi` cluster. The test still fails but it seems more like an expected behaviour rather than an issue this time, I have modified the test a little bit for it to pass.
> 
> Please take a look and share your thoughts, thanks very much.

This pull request has now been integrated.

Changeset: 01af2b48
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/01af2b48708ca67e8bd9bea74b78bed6e2c2a180
Stats:     45 lines in 3 files changed: 41 ins; 3 del; 1 mod

8336003: [lworld] TestLWorld::test151 triggers "Should have been buffered" assert

Reviewed-by: thartmann

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

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

From dfenacci at openjdk.org  Wed Jul  2 10:57:04 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 2 Jul 2025 10:57:04 GMT
Subject: [lworld] RFR: 8329234: [lworld]
 compiler/gcbarriers/TestZGCBarrierElision.java fails after JDK-8329205
Message-ID: <hBxsl9gkCnljTCHzU0c3Hxv0_a_AOLJboVNJo1tovec=.2dc99e18-7380-4b62-adff-8c0a979a8d81@github.com>

The `compiler/gcbarriers/TestZGCBarrierElision.java` test failed after [JDK-8329205](https://bugs.openjdk.org/browse/JDK-8329205) but [JDK-8350515](https://bugs.openjdk.org/browse/JDK-8350515) fixed the issue.
This PR removes the TODO and uncomments the IR check.

Tests: Tier 1-3+

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

Commit messages:
 - JDK-8329234: [lworld] compiler/gcbarriers/TestZGCBarrierElision.java fails after JDK-8329205

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

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

From thartmann at openjdk.org  Wed Jul  2 11:17:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Jul 2025 11:17:52 GMT
Subject: [lworld] RFR: 8329234: [lworld]
 compiler/gcbarriers/TestZGCBarrierElision.java fails after JDK-8329205
In-Reply-To: <hBxsl9gkCnljTCHzU0c3Hxv0_a_AOLJboVNJo1tovec=.2dc99e18-7380-4b62-adff-8c0a979a8d81@github.com>
References: <hBxsl9gkCnljTCHzU0c3Hxv0_a_AOLJboVNJo1tovec=.2dc99e18-7380-4b62-adff-8c0a979a8d81@github.com>
Message-ID: <OgvwgtykPVqzmh_Vk6JqtK9fxYxL8KE1mVHpPAkaA_4=.b62d107b-f5be-4e2a-916b-49f43fdda3ae@github.com>

On Wed, 2 Jul 2025 10:45:19 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> The `compiler/gcbarriers/TestZGCBarrierElision.java` test failed after [JDK-8329205](https://bugs.openjdk.org/browse/JDK-8329205) but [JDK-8350515](https://bugs.openjdk.org/browse/JDK-8350515) fixed the issue.
> This PR removes the TODO and uncomments the IR check.
> 
> Tests: Tier 1-3+

Thanks for investigating Damon! Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1496#pullrequestreview-2978745931

From dfenacci at openjdk.org  Wed Jul  2 12:05:58 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 2 Jul 2025 12:05:58 GMT
Subject: [lworld] RFR: 8329234: [lworld]
 compiler/gcbarriers/TestZGCBarrierElision.java fails after JDK-8329205
In-Reply-To: <OgvwgtykPVqzmh_Vk6JqtK9fxYxL8KE1mVHpPAkaA_4=.b62d107b-f5be-4e2a-916b-49f43fdda3ae@github.com>
References: <hBxsl9gkCnljTCHzU0c3Hxv0_a_AOLJboVNJo1tovec=.2dc99e18-7380-4b62-adff-8c0a979a8d81@github.com>
 <OgvwgtykPVqzmh_Vk6JqtK9fxYxL8KE1mVHpPAkaA_4=.b62d107b-f5be-4e2a-916b-49f43fdda3ae@github.com>
Message-ID: <BFCHpZbRAnAjOuMOHZfp5J7_Bae5Az6EJ2yQkSxZkiE=.7f345896-77ba-4af5-ac7a-5dd05f2c1020@github.com>

On Wed, 2 Jul 2025 11:15:36 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The `compiler/gcbarriers/TestZGCBarrierElision.java` test failed after [JDK-8329205](https://bugs.openjdk.org/browse/JDK-8329205) but [JDK-8350515](https://bugs.openjdk.org/browse/JDK-8350515) fixed the issue.
>> This PR removes the TODO and uncomments the IR check.
>> 
>> Tests: Tier 1-3+
>
> Thanks for investigating Damon! Looks good to me.

Thanks for your review @TobiHartmann.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1496#issuecomment-3027612774

From duke at openjdk.org  Wed Jul  2 12:05:58 2025
From: duke at openjdk.org (duke)
Date: Wed, 2 Jul 2025 12:05:58 GMT
Subject: [lworld] RFR: 8329234: [lworld]
 compiler/gcbarriers/TestZGCBarrierElision.java fails after JDK-8329205
In-Reply-To: <hBxsl9gkCnljTCHzU0c3Hxv0_a_AOLJboVNJo1tovec=.2dc99e18-7380-4b62-adff-8c0a979a8d81@github.com>
References: <hBxsl9gkCnljTCHzU0c3Hxv0_a_AOLJboVNJo1tovec=.2dc99e18-7380-4b62-adff-8c0a979a8d81@github.com>
Message-ID: <Mi-zVcBTIICWsLbZW1y9Vp9UAsBl0oSAaTVEB79geoY=.984705b4-387e-49d2-a313-649cff4227a3@github.com>

On Wed, 2 Jul 2025 10:45:19 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> The `compiler/gcbarriers/TestZGCBarrierElision.java` test failed after [JDK-8329205](https://bugs.openjdk.org/browse/JDK-8329205) but [JDK-8350515](https://bugs.openjdk.org/browse/JDK-8350515) fixed the issue.
> This PR removes the TODO and uncomments the IR check.
> 
> Tests: Tier 1-3+

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1496#issuecomment-3027617788

From dfenacci at openjdk.org  Wed Jul  2 12:14:05 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 2 Jul 2025 12:14:05 GMT
Subject: [lworld] Integrated: 8329234: [lworld]
 compiler/gcbarriers/TestZGCBarrierElision.java fails after JDK-8329205
In-Reply-To: <hBxsl9gkCnljTCHzU0c3Hxv0_a_AOLJboVNJo1tovec=.2dc99e18-7380-4b62-adff-8c0a979a8d81@github.com>
References: <hBxsl9gkCnljTCHzU0c3Hxv0_a_AOLJboVNJo1tovec=.2dc99e18-7380-4b62-adff-8c0a979a8d81@github.com>
Message-ID: <zVxGSJcIXlRsC8iBUSOXzY_Tt7EYUoIYKomGR-MiJn0=.add2386d-22c5-407b-8049-348c2f2ee885@github.com>

On Wed, 2 Jul 2025 10:45:19 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> The `compiler/gcbarriers/TestZGCBarrierElision.java` test failed after [JDK-8329205](https://bugs.openjdk.org/browse/JDK-8329205) but [JDK-8350515](https://bugs.openjdk.org/browse/JDK-8350515) fixed the issue.
> This PR removes the TODO and uncomments the IR check.
> 
> Tests: Tier 1-3+

This pull request has now been integrated.

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

8329234: [lworld] compiler/gcbarriers/TestZGCBarrierElision.java fails after JDK-8329205

Reviewed-by: thartmann

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

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

From dfenacci at openjdk.org  Wed Jul  2 13:07:39 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 2 Jul 2025 13:07:39 GMT
Subject: [lworld] RFR: 8353182: [lworld] C2: Multiple IR test failures in
 compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569
Message-ID: <eobtitL6G48qjTgv4LKirqmosmqmjppCp5OSNNAcEBE=.5d30aa93-9226-476d-8576-896dea5468bd@github.com>

This is a very similar issue to [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420).

A few `TestZGCBarrierElision` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that ZGC barrier elision optimization does not elide necessary barriers and partially do so using `VarHandle::getAndSet` and checking that `GetAndSetP` nodes with barriers are created.
As found out in [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420), [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node.

Here as well, as the goal of the test is mainly to check for ZGC barrier presence, the sensible fix for now seems to be to modify the `TestZGCBarrierElision` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes.

Tests: Tier 1-3+

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

Commit messages:
 - JDK-8353182: [lworld] C2: Multiple IR test failures in compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569

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

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

From dfenacci at openjdk.org  Wed Jul  2 13:12:24 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 2 Jul 2025 13:12:24 GMT
Subject: [lworld] RFR: 8353182: [lworld] C2: Multiple IR test failures in
 compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569 [v2]
In-Reply-To: <eobtitL6G48qjTgv4LKirqmosmqmjppCp5OSNNAcEBE=.5d30aa93-9226-476d-8576-896dea5468bd@github.com>
References: <eobtitL6G48qjTgv4LKirqmosmqmjppCp5OSNNAcEBE=.5d30aa93-9226-476d-8576-896dea5468bd@github.com>
Message-ID: <BhccvACSdWgcfz4xYgnpZZDJNwB3WhyiZJ3WuifucS0=.2925fa1c-f90b-43fe-b986-1bee573d74a0@github.com>

> This is a very similar issue to [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420).
> 
> A few `TestZGCBarrierElision` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that ZGC barrier elision optimization does not elide necessary barriers and partially do so using `VarHandle::getAndSet` and checking that `GetAndSetP` nodes with barriers are created.
> As found out in [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420), [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node.
> 
> Here as well, as the goal of the test is mainly to check for ZGC barrier presence, the sensible fix for now seems to be to modify the `TestZGCBarrierElision` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes.
> 
> Tests: Tier 1-3+

Damon Fenacci 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 branch 'lworld' into JDK-8353182
 - JDK-8353182: [lworld] C2: Multiple IR test failures in compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569

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

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

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

From thartmann at openjdk.org  Wed Jul  2 13:25:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Jul 2025 13:25:56 GMT
Subject: [lworld] RFR: 8353182: [lworld] C2: Multiple IR test failures in
 compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569 [v2]
In-Reply-To: <BhccvACSdWgcfz4xYgnpZZDJNwB3WhyiZJ3WuifucS0=.2925fa1c-f90b-43fe-b986-1bee573d74a0@github.com>
References: <eobtitL6G48qjTgv4LKirqmosmqmjppCp5OSNNAcEBE=.5d30aa93-9226-476d-8576-896dea5468bd@github.com>
 <BhccvACSdWgcfz4xYgnpZZDJNwB3WhyiZJ3WuifucS0=.2925fa1c-f90b-43fe-b986-1bee573d74a0@github.com>
Message-ID: <QABj8IT7sf-1kyvdRxipkc1jqsuKbm4dkkswXqK2t5w=.ff928132-85b9-4ab0-b43d-6631fe0eea35@github.com>

On Wed, 2 Jul 2025 13:12:24 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> This is a very similar issue to [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420).
>> 
>> A few `TestZGCBarrierElision` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that ZGC barrier elision optimization does not elide necessary barriers and partially do so using `VarHandle::getAndSet` and checking that `GetAndSetP` nodes with barriers are created.
>> As found out in [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420), [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node.
>> 
>> Here as well, as the goal of the test is mainly to check for ZGC barrier presence, the sensible fix for now seems to be to modify the `TestZGCBarrierElision` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes.
>> 
>> Tests: Tier 1-3+
>
> Damon Fenacci 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 branch 'lworld' into JDK-8353182
>  - JDK-8353182: [lworld] C2: Multiple IR test failures in compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569

Thanks again Damon. Looks good to me!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1497#pullrequestreview-2979154855

From dfenacci at openjdk.org  Wed Jul  2 14:57:54 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 2 Jul 2025 14:57:54 GMT
Subject: [lworld] RFR: 8353182: [lworld] C2: Multiple IR test failures in
 compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569 [v2]
In-Reply-To: <QABj8IT7sf-1kyvdRxipkc1jqsuKbm4dkkswXqK2t5w=.ff928132-85b9-4ab0-b43d-6631fe0eea35@github.com>
References: <eobtitL6G48qjTgv4LKirqmosmqmjppCp5OSNNAcEBE=.5d30aa93-9226-476d-8576-896dea5468bd@github.com>
 <BhccvACSdWgcfz4xYgnpZZDJNwB3WhyiZJ3WuifucS0=.2925fa1c-f90b-43fe-b986-1bee573d74a0@github.com>
 <QABj8IT7sf-1kyvdRxipkc1jqsuKbm4dkkswXqK2t5w=.ff928132-85b9-4ab0-b43d-6631fe0eea35@github.com>
Message-ID: <jb6vyzeUY1GNfCsZGZRf9C7U5aEY2HKtuDHmS8PJuZM=.70b8033a-0195-4abc-a5c4-dbcb1b76835b@github.com>

On Wed, 2 Jul 2025 13:22:56 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Damon Fenacci 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 branch 'lworld' into JDK-8353182
>>  - JDK-8353182: [lworld] C2: Multiple IR test failures in compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569
>
> Thanks again Damon. Looks good to me!

Thanks for your review @TobiHartmann.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1497#issuecomment-3028185167

From duke at openjdk.org  Wed Jul  2 14:57:54 2025
From: duke at openjdk.org (duke)
Date: Wed, 2 Jul 2025 14:57:54 GMT
Subject: [lworld] RFR: 8353182: [lworld] C2: Multiple IR test failures in
 compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569 [v2]
In-Reply-To: <BhccvACSdWgcfz4xYgnpZZDJNwB3WhyiZJ3WuifucS0=.2925fa1c-f90b-43fe-b986-1bee573d74a0@github.com>
References: <eobtitL6G48qjTgv4LKirqmosmqmjppCp5OSNNAcEBE=.5d30aa93-9226-476d-8576-896dea5468bd@github.com>
 <BhccvACSdWgcfz4xYgnpZZDJNwB3WhyiZJ3WuifucS0=.2925fa1c-f90b-43fe-b986-1bee573d74a0@github.com>
Message-ID: <WzjUmnHsvRelhQej74wMo1sQRG1Z6mCismXUC3fK1Nw=.08aceae9-15df-4c86-9126-27a4ebd507e0@github.com>

On Wed, 2 Jul 2025 13:12:24 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> This is a very similar issue to [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420).
>> 
>> A few `TestZGCBarrierElision` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that ZGC barrier elision optimization does not elide necessary barriers and partially do so using `VarHandle::getAndSet` and checking that `GetAndSetP` nodes with barriers are created.
>> As found out in [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420), [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node.
>> 
>> Here as well, as the goal of the test is mainly to check for ZGC barrier presence, the sensible fix for now seems to be to modify the `TestZGCBarrierElision` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes.
>> 
>> Tests: Tier 1-3+
>
> Damon Fenacci 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 branch 'lworld' into JDK-8353182
>  - JDK-8353182: [lworld] C2: Multiple IR test failures in compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1497#issuecomment-3028192337

From matsaave at openjdk.org  Wed Jul  2 16:50:05 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 2 Jul 2025 16:50:05 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails with
 SIGSEGV
Message-ID: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>

`RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
`PENDING_EXCEPTION->klass()->name()->as_C_string()`

This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.

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

Commit messages:
 - Added more spacing
 - 8361082: [lworld] RewriteBytecodesInlineTest fails with SIGSEGV

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

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

From matsaave at openjdk.org  Wed Jul  2 16:56:04 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 2 Jul 2025 16:56:04 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v2]
In-Reply-To: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
Message-ID: <SzVV6yqXRWxs6DgAW6LdoCS6tjEWAtXD-56IqETGTzY=.83bd2789-d819-4d8c-832a-68a27e7eda2e@github.com>

> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
> 
> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Added comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1498/files
  - new: https://git.openjdk.org/valhalla/pull/1498/files/52348059..122d1178

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

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

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

From matsaave at openjdk.org  Wed Jul  2 18:21:07 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 2 Jul 2025 18:21:07 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v3]
In-Reply-To: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
Message-ID: <Zx9vZgon08kHyrccFE4KnL5nwVNGFLBWmsGWmSe9b0k=.8b1694be-30a4-4dc8-8c09-c67d5cbf51d1@github.com>

> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
> 
> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with three additional commits since the last revision:

 - Cleanup
 - Multilined another log message
 - Changed long log messages to multi-line strings

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1498/files
  - new: https://git.openjdk.org/valhalla/pull/1498/files/122d1178..a427fc28

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

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

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

From coleenp at openjdk.org  Wed Jul  2 19:18:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Jul 2025 19:18:51 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v3]
In-Reply-To: <Zx9vZgon08kHyrccFE4KnL5nwVNGFLBWmsGWmSe9b0k=.8b1694be-30a4-4dc8-8c09-c67d5cbf51d1@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <Zx9vZgon08kHyrccFE4KnL5nwVNGFLBWmsGWmSe9b0k=.8b1694be-30a4-4dc8-8c09-c67d5cbf51d1@github.com>
Message-ID: <E0W_RK09aaO_6po5aTdyUzQK94KN4ebgqJoaghBR_48=.8b67352a-4f47-4f4a-a469-9b399b7fdf42@github.com>

On Wed, 2 Jul 2025 18:21:07 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
>> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
>> 
>> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Cleanup
>  - Multilined another log message
>  - Changed long log messages to multi-line strings

I have a few comments - maybe some of it can be refactored and shared? Also thank you for reformatting the logging lines.

src/hotspot/share/classfile/systemDictionary.cpp line 1078:

> 1076: }
> 1077: 
> 1078: // Pre-load class referred to in non-static null-free instance field. These fields trigger MANDATORY loading

Add period at the end of the sentence.

src/hotspot/share/classfile/systemDictionary.cpp line 1109:

> 1107: 
> 1108:   assert(real_k != nullptr, "Sanity check");
> 1109:   if (real_k->access_flags().is_identity_class()) {

It looks like you could refactor the check for identity and abstract in to InstanceKlass::check_inline_field(TRAPS) and share the code with ClassFileParser. (?)

src/hotspot/share/classfile/systemDictionary.cpp line 1195:

> 1193: 
> 1194:       if (fs.is_null_free_inline_type()) {
> 1195:         bool check = preload_from_null_free_field(ik, class_loader, sig, field_index, CHECK_NULL);

This is a bit confusing that it both has a check for return and CHECK_NULL.  Add a comment that some preloading might fail but not fatally for the shared archive if the class changed in the app.

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

PR Review: https://git.openjdk.org/valhalla/pull/1498#pullrequestreview-2980341411
PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2180795881
PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2180801339
PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2180804792

From rriggs at openjdk.org  Wed Jul  2 19:47:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Jul 2025 19:47:04 GMT
Subject: [lworld] Integrated: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects
In-Reply-To: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
Message-ID: <m9qGGBdluVJYBLIMVz8uHy2R5rXIFAz1vQV-fPe1FZM=.1209d266-fb60-4597-a9fe-07ce301d54c4@github.com>

On Mon, 6 Jan 2025 20:05:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
> Simplified WeakHashMap javadoc updates for IdentityException. 
> Added note to System.identityHashCode to include value objects.
> Added to class javadoc for IdentityHashMap for value objects.

This pull request has now been integrated.

Changeset: 6541b8be
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6541b8be1d4c44245cdd62f85a7d7e943b084140
Stats:     267 lines in 12 files changed: 204 ins; 17 del; 46 mod

8346307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects

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

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

From rriggs at openjdk.org  Wed Jul  2 20:56:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Jul 2025 20:56:03 GMT
Subject: [lworld] RFR: 8361302:
Message-ID: <Zvp_biCABjw6Tvosl7JkiTUiqlpnr4uRugK3YALz83I=.d7384df9-26ab-4a29-bcc3-b9f673133a65@github.com>

The changes to Class.isValue() resulted in vm crashes. Reverting.

[lworld] Clarify identity vs value in Class, Object, and document limitations of value objects"

This reverts commit 6541b8be1d4c44245cdd62f85a7d7e943b084140.

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

Commit messages:
 - Revert "8346307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects"

Changes: https://git.openjdk.org/valhalla/pull/1499/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1499&range=00
  Stats: 265 lines in 12 files changed: 15 ins; 202 del; 48 mod
  Patch: https://git.openjdk.org/valhalla/pull/1499.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1499/head:pull/1499

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

From rriggs at openjdk.org  Wed Jul  2 21:04:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Jul 2025 21:04:45 GMT
Subject: [lworld] RFR: 8361302:
In-Reply-To: <Zvp_biCABjw6Tvosl7JkiTUiqlpnr4uRugK3YALz83I=.d7384df9-26ab-4a29-bcc3-b9f673133a65@github.com>
References: <Zvp_biCABjw6Tvosl7JkiTUiqlpnr4uRugK3YALz83I=.d7384df9-26ab-4a29-bcc3-b9f673133a65@github.com>
Message-ID: <MdLtC43Rgn7LArhQNdloo6IYujvrviILRAgEexhtWrQ=.dba927c1-69fe-4688-bf1f-9421b3705e85@github.com>

On Wed, 2 Jul 2025 20:45:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The changes to Class.isValue() resulted in vm crashes. Reverting.
> 
> [lworld] Clarify identity vs value in Class, Object, and document limitations of value objects"
> 
> This reverts commit 6541b8be1d4c44245cdd62f85a7d7e943b084140.

Revert to heal the CI.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1499#issuecomment-3029314682

From rriggs at openjdk.org  Wed Jul  2 21:04:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Jul 2025 21:04:46 GMT
Subject: [lworld] Integrated: 8361302:
In-Reply-To: <Zvp_biCABjw6Tvosl7JkiTUiqlpnr4uRugK3YALz83I=.d7384df9-26ab-4a29-bcc3-b9f673133a65@github.com>
References: <Zvp_biCABjw6Tvosl7JkiTUiqlpnr4uRugK3YALz83I=.d7384df9-26ab-4a29-bcc3-b9f673133a65@github.com>
Message-ID: <zd4zF3KY0ogzuW5cb2uCR7GSRPSnoywIV0BLWo64Wcw=.e37a3549-6e5f-485a-b020-dba528494ef6@github.com>

On Wed, 2 Jul 2025 20:45:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The changes to Class.isValue() resulted in vm crashes. Reverting.
> 
> [lworld] Clarify identity vs value in Class, Object, and document limitations of value objects"
> 
> This reverts commit 6541b8be1d4c44245cdd62f85a7d7e943b084140.

This pull request has now been integrated.

Changeset: bdfe15ad
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/bdfe15adad6264f2df92c5427017a993b40e699c
Stats:     265 lines in 12 files changed: 15 ins; 202 del; 48 mod

8361302:

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

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

From matsaave at openjdk.org  Wed Jul  2 21:04:57 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 2 Jul 2025 21:04:57 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v3]
In-Reply-To: <E0W_RK09aaO_6po5aTdyUzQK94KN4ebgqJoaghBR_48=.8b67352a-4f47-4f4a-a469-9b399b7fdf42@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <Zx9vZgon08kHyrccFE4KnL5nwVNGFLBWmsGWmSe9b0k=.8b1694be-30a4-4dc8-8c09-c67d5cbf51d1@github.com>
 <E0W_RK09aaO_6po5aTdyUzQK94KN4ebgqJoaghBR_48=.8b67352a-4f47-4f4a-a469-9b399b7fdf42@github.com>
Message-ID: <m9apuNnTvfztES-DH49Nd_H3MvVCKokoX7gJkanArgE=.d7ccc9ab-0c1e-49c0-b565-0422d71faadd@github.com>

On Wed, 2 Jul 2025 19:13:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Cleanup
>>  - Multilined another log message
>>  - Changed long log messages to multi-line strings
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1109:
> 
>> 1107: 
>> 1108:   assert(real_k != nullptr, "Sanity check");
>> 1109:   if (real_k->access_flags().is_identity_class()) {
> 
> It looks like you could refactor the check for identity and abstract in to InstanceKlass::check_inline_field(TRAPS) and share the code with ClassFileParser. (?)

This check is being done in Klass so I would need to add it there. I think a better name might be `Klass::check_null_restricted_field(TRAPS)` since these are mandatory conditions for a field to be null restricted. The checks may actually be unnecessary since the `@NullRestricted` annotation can only be used on a concrete value class.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2180966266

From vromero at openjdk.org  Wed Jul  2 22:05:31 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Jul 2025 22:05:31 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase
Message-ID: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>

Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase,

TIA

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

Commit messages:
 - updating tests
 - Merge branch 'JDK-8359370' of https://github.com/vicente-romero-oracle/valhalla into JDK-8359370
 - more simplifications
 - more simplifications
 - refact
 - refacts
 - more refactorings
 - more cleanups
 - adding some documentation
 - additional cleanups
 - ... and 5 more: https://git.openjdk.org/valhalla/compare/658a8d28...83b92556

Changes: https://git.openjdk.org/valhalla/pull/1490/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1490&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359370
  Stats: 457 lines in 20 files changed: 264 ins; 79 del; 114 mod
  Patch: https://git.openjdk.org/valhalla/pull/1490.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1490/head:pull/1490

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

From liach at openjdk.org  Wed Jul  2 22:05:31 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 22:05:31 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <seMspaslQ5kUJf_RDsDHND6IlS-XDO-jywCx2B4WA5o=.6f4838b3-17fe-4ff1-aaf1-0e6c6daed4fb@github.com>

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

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase,
> 
> TIA

Just curious, why is field proxies so late in the stages? Is it because strict fields cannot be used by lowered structures, etc.?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1490#issuecomment-2993653836

From vromero at openjdk.org  Wed Jul  2 22:05:31 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Jul 2025 22:05:31 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase
In-Reply-To: <seMspaslQ5kUJf_RDsDHND6IlS-XDO-jywCx2B4WA5o=.6f4838b3-17fe-4ff1-aaf1-0e6c6daed4fb@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
 <seMspaslQ5kUJf_RDsDHND6IlS-XDO-jywCx2B4WA5o=.6f4838b3-17fe-4ff1-aaf1-0e6c6daed4fb@github.com>
Message-ID: <ypoEPw9VhKAmPp5IIi0vnZpF0NrF1197bEeGsle3SIk=.dd02c6d2-fcf3-4d6d-9794-1abe728f8216@github.com>

On Sat, 21 Jun 2025 16:10:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> Just curious, why is field proxies so late in the stages? Is it because strict fields cannot be used by lowered structures, etc.?

sorry I missed your question, well what this phase is doing is kind of similar to what we do in Lower, actually I don't discard folding the code into lower in the future, this is probably one of the reasons it is so close to Lower. We certainly need it after Flow

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

PR Comment: https://git.openjdk.org/valhalla/pull/1490#issuecomment-3028992624

From vromero at openjdk.org  Wed Jul  2 22:05:33 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Jul 2025 22:05:33 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <NvF8i7dQ53nqwi2wodyoNKJHl1TWc8TgnRm3Ntydpl4=.0ea470e9-49ac-4af4-ae8c-0f93f14f49df@github.com>

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

> Before this fix only strict fields were readable in the prologue phase. The proposed fix should allow any instance fields of identity classes to be readable in the prologue phase,
> 
> TIA

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

> 18:         }
> 19: 
> 20:         public class Inner1a extends Inner1 {

moved the code above to new file EarlyAssignments2.java as now if fails in Flow not in Resolve, so it was not being reported by javac

test/langtools/tools/javac/SuperInit/SuperInitFails.java line 93:

> 91:     }
> 92: 
> 93:     public SuperInitFails(float[] x) {

moved to EarlyAssignments2, too

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1490#discussion_r2164747818
PR Review Comment: https://git.openjdk.org/valhalla/pull/1490#discussion_r2164748943

From dfenacci at openjdk.org  Thu Jul  3 05:21:54 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Thu, 3 Jul 2025 05:21:54 GMT
Subject: [lworld] Integrated: 8353182: [lworld] C2: Multiple IR test failures
 in compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569
In-Reply-To: <eobtitL6G48qjTgv4LKirqmosmqmjppCp5OSNNAcEBE=.5d30aa93-9226-476d-8576-896dea5468bd@github.com>
References: <eobtitL6G48qjTgv4LKirqmosmqmjppCp5OSNNAcEBE=.5d30aa93-9226-476d-8576-896dea5468bd@github.com>
Message-ID: <6QMYFjp_o2bT2ZWv3jpEUI52iJoFvsPIC7JJF-Gblec=.db562c27-bf01-45d2-963b-df5ea09a0140@github.com>

On Wed, 2 Jul 2025 12:56:47 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> This is a very similar issue to [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420).
> 
> A few `TestZGCBarrierElision` tests fail after [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569). These tests check that ZGC barrier elision optimization does not elide necessary barriers and partially do so using `VarHandle::getAndSet` and checking that `GetAndSetP` nodes with barriers are created.
> As found out in [JDK-8343420](https://bugs.openjdk.org/browse/JDK-8343420), [JDK-8351569](https://bugs.openjdk.org/browse/JDK-8351569) refactored `Unsafe::getAndSet` (which is used by `VarHandle::getAndSet`) to take value-classes into account, which implies that checks must be introduced to see if the target and argument objects are value-classes. This is done with a new overloaded `getAndSet` method that is now called instead of the old one. This method is not intrinsified (only inlined) and doesn't result in a `GetAndSet` node. It instead relies on the `compareAndSet` method (which gets intrinsified) and results in a `CompareAndSwap` node.
> 
> Here as well, as the goal of the test is mainly to check for ZGC barrier presence, the sensible fix for now seems to be to modify the `TestZGCBarrierElision` tests to make them check for `CompareAndSwap` instead of `GetAndSet` nodes.
> 
> Tests: Tier 1-3+

This pull request has now been integrated.

Changeset: ed2a03e0
Author:    Damon Fenacci <dfenacci at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ed2a03e0f3001f7c5540e187328da7b07d71a957
Stats:     24 lines in 1 file changed: 0 ins; 11 del; 13 mod

8353182: [lworld] C2: Multiple IR test failures in compiler/gcbarriers/TestZGCBarrierElision.java after JDK-8351569

Reviewed-by: thartmann

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

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

From coleenp at openjdk.org  Thu Jul  3 11:34:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Jul 2025 11:34:55 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v3]
In-Reply-To: <m9apuNnTvfztES-DH49Nd_H3MvVCKokoX7gJkanArgE=.d7ccc9ab-0c1e-49c0-b565-0422d71faadd@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <Zx9vZgon08kHyrccFE4KnL5nwVNGFLBWmsGWmSe9b0k=.8b1694be-30a4-4dc8-8c09-c67d5cbf51d1@github.com>
 <E0W_RK09aaO_6po5aTdyUzQK94KN4ebgqJoaghBR_48=.8b67352a-4f47-4f4a-a469-9b399b7fdf42@github.com>
 <m9apuNnTvfztES-DH49Nd_H3MvVCKokoX7gJkanArgE=.d7ccc9ab-0c1e-49c0-b565-0422d71faadd@github.com>
Message-ID: <IkRjfWNstzwkNTX2XysddatznYwI4fPRlPockMP9_Cc=.b50657e2-df7b-4c40-b477-93d4473a2447@github.com>

On Wed, 2 Jul 2025 21:02:04 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionary.cpp line 1109:
>> 
>>> 1107: 
>>> 1108:   assert(real_k != nullptr, "Sanity check");
>>> 1109:   if (real_k->access_flags().is_identity_class()) {
>> 
>> It looks like you could refactor the check for identity and abstract in to InstanceKlass::check_inline_field(TRAPS) and share the code with ClassFileParser. (?)
>
> This check is being done in Klass so I would need to add it there. I think a better name might be `Klass::check_null_restricted_field(TRAPS)` since these are mandatory conditions for a field to be null restricted. The checks may actually be unnecessary since the `@NullRestricted` annotation can only be used on a concrete value class.

It should be InstanceKlass not Klass though since Klass has no fields.  resolve_with_circularity_check does return an InstanceKlass so the return type should be changed to InstanceKlass.  The check_null_restricted_field name seems good though.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2182553605

From matsaave at openjdk.org  Thu Jul  3 14:49:09 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 3 Jul 2025 14:49:09 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v4]
In-Reply-To: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
Message-ID: <q81wfMsgTiTa3dVLmQU84UJwOFoPL9YSsh5yU0hsgqA=.688c53dc-f2f1-415e-97cf-588c370fb837@github.com>

> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
> 
> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Coleen comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1498/files
  - new: https://git.openjdk.org/valhalla/pull/1498/files/a427fc28..baa46b72

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

  Stats: 50 lines in 3 files changed: 25 ins; 18 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/1498.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1498/head:pull/1498

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

From matsaave at openjdk.org  Thu Jul  3 15:44:00 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 3 Jul 2025 15:44:00 GMT
Subject: [lworld] RFR: 8361218: [lworld] Remove LockingMode from test
In-Reply-To: <Zs3-wWwOpXHMUx8JLdkpQXxGb0DKpMvlMffM-TahMYc=.9615fc87-618c-4c8d-adcd-4ae03b9c6b81@github.com>
References: <Zs3-wWwOpXHMUx8JLdkpQXxGb0DKpMvlMffM-TahMYc=.9615fc87-618c-4c8d-adcd-4ae03b9c6b81@github.com>
Message-ID: <LDcY7h24IwW_PB4XOcFpI7f07Te4ADDO-twIYjYo79c=.4ffffc86-6990-4ab2-8699-8d33dcfbd2bd@github.com>

On Tue, 1 Jul 2025 19:55:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> See issue - the LockingMode flags will be removed in mainline, so adjusting this test.
> Tested with the test.

Looks good and seems trivial. Thanks!

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1495#pullrequestreview-2983704132

From coleenp at openjdk.org  Thu Jul  3 17:32:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Jul 2025 17:32:51 GMT
Subject: [lworld] RFR: 8361218: [lworld] Remove LockingMode from test
In-Reply-To: <Zs3-wWwOpXHMUx8JLdkpQXxGb0DKpMvlMffM-TahMYc=.9615fc87-618c-4c8d-adcd-4ae03b9c6b81@github.com>
References: <Zs3-wWwOpXHMUx8JLdkpQXxGb0DKpMvlMffM-TahMYc=.9615fc87-618c-4c8d-adcd-4ae03b9c6b81@github.com>
Message-ID: <Ma8EtndZftpGoi1NIkPyy7BgbvS5b8uHiv6rIxIxzt0=.32ce2ece-5405-4065-9e59-a4bcbb26df14@github.com>

On Tue, 1 Jul 2025 19:55:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> See issue - the LockingMode flags will be removed in mainline, so adjusting this test.
> Tested with the test.

Thanks Matias.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1495#issuecomment-3033025984

From coleenp at openjdk.org  Thu Jul  3 17:32:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Jul 2025 17:32:51 GMT
Subject: [lworld] Integrated: 8361218: [lworld] Remove LockingMode from test
In-Reply-To: <Zs3-wWwOpXHMUx8JLdkpQXxGb0DKpMvlMffM-TahMYc=.9615fc87-618c-4c8d-adcd-4ae03b9c6b81@github.com>
References: <Zs3-wWwOpXHMUx8JLdkpQXxGb0DKpMvlMffM-TahMYc=.9615fc87-618c-4c8d-adcd-4ae03b9c6b81@github.com>
Message-ID: <v1-HmjubmScqFXixT58xPJIHD1GIx6uLn7zWq_ENvyE=.c21b3aa2-e7b4-4cb8-b05e-b04557bf81c6@github.com>

On Tue, 1 Jul 2025 19:55:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> See issue - the LockingMode flags will be removed in mainline, so adjusting this test.
> Tested with the test.

This pull request has now been integrated.

Changeset: cbe19cdc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cbe19cdc750d68ae7868fee7ba4a9b111e4d0cfb
Stats:     18 lines in 1 file changed: 0 ins; 16 del; 2 mod

8361218: [lworld] Remove LockingMode from test

Reviewed-by: matsaave

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

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

From coleenp at openjdk.org  Thu Jul  3 17:37:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Jul 2025 17:37:02 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v4]
In-Reply-To: <q81wfMsgTiTa3dVLmQU84UJwOFoPL9YSsh5yU0hsgqA=.688c53dc-f2f1-415e-97cf-588c370fb837@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <q81wfMsgTiTa3dVLmQU84UJwOFoPL9YSsh5yU0hsgqA=.688c53dc-f2f1-415e-97cf-588c370fb837@github.com>
Message-ID: <8k_tZPBhmM1u7OV6W55KC0BtY6vFyJKMLd4I-Ctq7jk=.634836c5-2069-46b0-a0cc-5dbfd9d69c8f@github.com>

On Thu, 3 Jul 2025 14:49:09 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
>> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
>> 
>> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen comments

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

> 6187:           return; // Exception is still pending
> 6188:         }
> 6189:         assert(klass != nullptr, "Sanity check");

Can you call InstanceKlass::check_null_free_field from here too?

src/hotspot/share/oops/instanceKlass.cpp line 3594:

> 3592: }
> 3593: 
> 3594: void InstanceKlass::check_null_free_field(InstanceKlass* ik, TRAPS) {

Is ik not the same as 'this'?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2183355457
PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2183352357

From matsaave at openjdk.org  Thu Jul  3 18:52:52 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 3 Jul 2025 18:52:52 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v4]
In-Reply-To: <8k_tZPBhmM1u7OV6W55KC0BtY6vFyJKMLd4I-Ctq7jk=.634836c5-2069-46b0-a0cc-5dbfd9d69c8f@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <q81wfMsgTiTa3dVLmQU84UJwOFoPL9YSsh5yU0hsgqA=.688c53dc-f2f1-415e-97cf-588c370fb837@github.com>
 <8k_tZPBhmM1u7OV6W55KC0BtY6vFyJKMLd4I-Ctq7jk=.634836c5-2069-46b0-a0cc-5dbfd9d69c8f@github.com>
Message-ID: <7F6bjYyc-ACQDMtLVPRtatxptBG9WC13516Kic6ARYw=.9aa688b7-3305-471d-9688-e70212548e23@github.com>

On Thu, 3 Jul 2025 17:33:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Coleen comments
>
> src/hotspot/share/oops/instanceKlass.cpp line 3594:
> 
>> 3592: }
>> 3593: 
>> 3594: void InstanceKlass::check_null_free_field(InstanceKlass* ik, TRAPS) {
> 
> Is ik not the same as 'this'?

No, `ik` is the class being loaded in `load_shared_class` and `this` is the type of the null restricted field.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2183534518

From matsaave at openjdk.org  Thu Jul  3 18:56:54 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 3 Jul 2025 18:56:54 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v4]
In-Reply-To: <8k_tZPBhmM1u7OV6W55KC0BtY6vFyJKMLd4I-Ctq7jk=.634836c5-2069-46b0-a0cc-5dbfd9d69c8f@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <q81wfMsgTiTa3dVLmQU84UJwOFoPL9YSsh5yU0hsgqA=.688c53dc-f2f1-415e-97cf-588c370fb837@github.com>
 <8k_tZPBhmM1u7OV6W55KC0BtY6vFyJKMLd4I-Ctq7jk=.634836c5-2069-46b0-a0cc-5dbfd9d69c8f@github.com>
Message-ID: <gbBgN7sNpp5TzyaG5-mS105TLl-iNGbyxOGtYsthCDw=.7bbdd7f2-b331-4708-88b2-fa2ccfd12dd4@github.com>

On Thu, 3 Jul 2025 17:34:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Coleen comments
>
> src/hotspot/share/classfile/classFileParser.cpp line 6189:
> 
>> 6187:           return; // Exception is still pending
>> 6188:         }
>> 6189:         assert(klass != nullptr, "Sanity check");
> 
> Can you call InstanceKlass::check_null_free_field from here too?

I could but I would need to change the argument of `check_null_free_field` to `Symbol*` since the InstanceKlass isn't available here.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2183547176

From liach at openjdk.org  Thu Jul  3 19:34:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 19:34:24 GMT
Subject: [lworld] RFR: 8361369: [lworld] Treating primitives as isValue() leads
 to vm crash
Message-ID: <t0Y7nNJLepntZF5BLL7yevjymhFwOxyzJFVwCKbkrlU=.4bc97113-ef23-4f9e-832b-172ac843f8ed@github.com>

Need to update the checking logic. Culprit is the filter in valueTypeFields. Tested by running jshell.

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

Commit messages:
 - Fix layout value type detection

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

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

From matsaave at openjdk.org  Thu Jul  3 20:01:06 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 3 Jul 2025 20:01:06 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v5]
In-Reply-To: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
Message-ID: <VmJAxbCBCFjHpGa6QskraEOQwOWa9AcdwE59jtmXbnw=.3f1bf1ab-43d1-4476-a8f1-f77a49aa7b45@github.com>

> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
> 
> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Used new method in classfileparser

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1498/files
  - new: https://git.openjdk.org/valhalla/pull/1498/files/baa46b72..5f200d56

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

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

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

From fparain at openjdk.org  Thu Jul  3 20:17:47 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 3 Jul 2025 20:17:47 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v5]
In-Reply-To: <VmJAxbCBCFjHpGa6QskraEOQwOWa9AcdwE59jtmXbnw=.3f1bf1ab-43d1-4476-a8f1-f77a49aa7b45@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <VmJAxbCBCFjHpGa6QskraEOQwOWa9AcdwE59jtmXbnw=.3f1bf1ab-43d1-4476-a8f1-f77a49aa7b45@github.com>
Message-ID: <dTWaUiaooWntru1MbIz7ufOiZwWRYflQ1QIkqaGZpS4=.c515b8ef-d861-4ac2-82d8-713ee59c078b@github.com>

On Thu, 3 Jul 2025 20:01:06 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
>> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
>> 
>> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Used new method in classfileparser

src/hotspot/share/oops/instanceKlass.cpp line 3594:

> 3592: }
> 3593: 
> 3594: void InstanceKlass::check_null_free_field(Symbol* container_klass_name, TRAPS) {

This method is very misleading, it does nothing related to fields, nor being null-free. And the fact that its name refers to fields but the receiver is the field's type and the container is passed in argument is confusing too, because most methods work the other way around: the receiver is the container, and the arguments tell which fields the query is about.

I'd suggest a static method like that:
can_be_annotated_with_NullRestricted(InstanceKlass* type, Symbol* container_klass_name, TRAPS)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2183678279

From rriggs at openjdk.org  Thu Jul  3 20:34:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 3 Jul 2025 20:34:47 GMT
Subject: [lworld] RFR: 8361369: [lworld] Treating primitives as isValue()
 leads to vm crash
In-Reply-To: <t0Y7nNJLepntZF5BLL7yevjymhFwOxyzJFVwCKbkrlU=.4bc97113-ef23-4f9e-832b-172ac843f8ed@github.com>
References: <t0Y7nNJLepntZF5BLL7yevjymhFwOxyzJFVwCKbkrlU=.4bc97113-ef23-4f9e-832b-172ac843f8ed@github.com>
Message-ID: <mv7zX9DCYVmSjqRX8cM_w27DNeOuUgdXuowOfbOjfLE=.a7d38cf4-45e0-4ffe-aebf-e69e0559f571@github.com>

On Thu, 3 Jul 2025 19:29:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> Need to update the checking logic. Culprit is the filter in valueTypeFields. Tested by running jshell.

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1500#pullrequestreview-2984572948

From coleenp at openjdk.org  Thu Jul  3 20:37:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Jul 2025 20:37:47 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v5]
In-Reply-To: <dTWaUiaooWntru1MbIz7ufOiZwWRYflQ1QIkqaGZpS4=.c515b8ef-d861-4ac2-82d8-713ee59c078b@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <VmJAxbCBCFjHpGa6QskraEOQwOWa9AcdwE59jtmXbnw=.3f1bf1ab-43d1-4476-a8f1-f77a49aa7b45@github.com>
 <dTWaUiaooWntru1MbIz7ufOiZwWRYflQ1QIkqaGZpS4=.c515b8ef-d861-4ac2-82d8-713ee59c078b@github.com>
Message-ID: <rGDpoEO_QGF843UcgNd4yIErHmpcADnn1Lg8WpaZX2w=.7001216e-289b-4a0e-bd4c-e3ffa659e3f0@github.com>

On Thu, 3 Jul 2025 20:15:14 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Used new method in classfileparser
>
> src/hotspot/share/oops/instanceKlass.cpp line 3594:
> 
>> 3592: }
>> 3593: 
>> 3594: void InstanceKlass::check_null_free_field(Symbol* container_klass_name, TRAPS) {
> 
> This method is very misleading, it does nothing related to fields, nor being null-free. And the fact that its name refers to fields but the receiver is the field's type and the container is passed in argument is confusing too, because most methods work the other way around: the receiver is the container, and the arguments tell which fields the query is about.
> 
> I'd suggest a static method like that:
> can_be_annotated_with_NullRestricted(InstanceKlass* type, Symbol* container_klass_name, TRAPS)

How about InstanceKlass::check_can_be_null_free_field_type() ? Because it has TRAPS and doesn't return a bool.  And would be nice to not have to have type->access_flags() and type->is_abstract() etc.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2183705030

From liach at openjdk.org  Thu Jul  3 20:47:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 20:47:50 GMT
Subject: [lworld] RFR: 8361369: [lworld] Treating primitives as isValue()
 leads to vm crash
In-Reply-To: <t0Y7nNJLepntZF5BLL7yevjymhFwOxyzJFVwCKbkrlU=.4bc97113-ef23-4f9e-832b-172ac843f8ed@github.com>
References: <t0Y7nNJLepntZF5BLL7yevjymhFwOxyzJFVwCKbkrlU=.4bc97113-ef23-4f9e-832b-172ac843f8ed@github.com>
Message-ID: <WbqP0GpfDiFY9c2OKwb9HzzDJT7Uv9QMaQXRmDEyInM=.bf8a7075-142d-451b-85b7-3d010e5b71fa@github.com>

On Thu, 3 Jul 2025 19:29:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> Need to update the checking logic. Culprit is the filter in valueTypeFields. Tested by running jshell.

tier1, jdk tier2,3 failures in valuetearing and varhandles; but they are known to be failing intermittently. Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1500#issuecomment-3033585278

From liach at openjdk.org  Thu Jul  3 20:47:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 20:47:50 GMT
Subject: [lworld] Integrated: 8361369: [lworld] Treating primitives as
 isValue() leads to vm crash
In-Reply-To: <t0Y7nNJLepntZF5BLL7yevjymhFwOxyzJFVwCKbkrlU=.4bc97113-ef23-4f9e-832b-172ac843f8ed@github.com>
References: <t0Y7nNJLepntZF5BLL7yevjymhFwOxyzJFVwCKbkrlU=.4bc97113-ef23-4f9e-832b-172ac843f8ed@github.com>
Message-ID: <kgFjyIZii_q9zxs2hKeh6QnJM5jm7ajS3aYPEelNX54=.8cee595f-271a-4392-98a6-80dbe4dd66f9@github.com>

On Thu, 3 Jul 2025 19:29:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> Need to update the checking logic. Culprit is the filter in valueTypeFields. Tested by running jshell.

This pull request has now been integrated.

Changeset: 28819b22
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/28819b22518bc578aa561e92ed0e57a4f2a05d63
Stats:     12 lines in 2 files changed: 1 ins; 3 del; 8 mod

8361369: [lworld] Treating primitives as isValue() leads to vm crash

Reviewed-by: rriggs

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

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

From thartmann at openjdk.org  Fri Jul  4 08:06:31 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 4 Jul 2025 08:06:31 GMT
Subject: [lworld] RFR: 8361390: [lworld] Assert during C2 compilation because
 EA does not properly handle null-free arrays
Message-ID: <1-dwvHD6N9CectRYpyuc7p9Hn3U38RSndW_pAvuMLGs=.a0081ead-ee1b-4775-b96d-84c40e1f0a32@github.com>

While doing some stress testing by disabling pre-loading of value classes, I found more cases when EA does not properly handle null-free arrays. This issue is already tracked by [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865) and I simply modified the hacky bailout code in `LoadNode::Value` to cover the newly found cases for now. I added corresponding tests that also trigger this with preloading. The full fix will be done by [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865) (most likely I'll split that RFE into subtasks).

Thanks,
Tobias

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

Commit messages:
 - 8361390: [lworld] Assert during C2 compilation because EA does not properly handle null-free arrays

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

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

From thartmann at openjdk.org  Fri Jul  4 08:19:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 4 Jul 2025 08:19:51 GMT
Subject: [lworld] Integrated: 8361390: [lworld] Assert during C2 compilation
 because EA does not properly handle null-free arrays
In-Reply-To: <1-dwvHD6N9CectRYpyuc7p9Hn3U38RSndW_pAvuMLGs=.a0081ead-ee1b-4775-b96d-84c40e1f0a32@github.com>
References: <1-dwvHD6N9CectRYpyuc7p9Hn3U38RSndW_pAvuMLGs=.a0081ead-ee1b-4775-b96d-84c40e1f0a32@github.com>
Message-ID: <Lu3_bx_E9XAheBglmMWvB5d9CcKtMoCxFv7P4VkOSLM=.0cbf8ac2-82be-4249-8897-9c6d7db2dae2@github.com>

On Fri, 4 Jul 2025 07:52:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> While doing some stress testing by disabling pre-loading of value classes, I found more cases when EA does not properly handle null-free arrays. This issue is already tracked by [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865) and I simply modified the hacky bailout code in `LoadNode::Value` to cover the newly found cases for now. I added corresponding tests that also trigger this with preloading. The full fix will be done by [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865) (most likely I'll split that RFE into subtasks).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 313d34a3
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/313d34a35dd156ca04c008a0f7a4f8293948591d
Stats:     87 lines in 5 files changed: 76 ins; 1 del; 10 mod

8361390: [lworld] Assert during C2 compilation because EA does not properly handle null-free arrays

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

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

From mchevalier at openjdk.org  Fri Jul  4 18:25:35 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 4 Jul 2025 18:25:35 GMT
Subject: [lworld] RFR: 8361250: [lworld] use more IRNode regexes in valhalla IR
 tests
Message-ID: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>

InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.

The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.

So what now:
- `InlineTypeRegexes` => only value regexes.
- `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
- `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
- `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.

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

Commit messages:
 - Fix visibility
 - Forgot a space
 - Refactor inlinetypes/InlineTypeIRNode

Changes: https://git.openjdk.org/valhalla/pull/1503/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361250
  Stats: 754 lines in 14 files changed: 152 ins; 148 del; 454 mod
  Patch: https://git.openjdk.org/valhalla/pull/1503.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1503/head:pull/1503

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

From dfenacci at openjdk.org  Mon Jul  7 06:54:33 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 7 Jul 2025 06:54:33 GMT
Subject: [lworld] RFR: 8361166: [lworld] TestG1BarrierGeneration still fails
 after JDK-8343420
Message-ID: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>

The `TestG1BarrierGeneration::testArrayStore` and `TestG1BarrierGeneration::testArrayStoreTwice` tests are failing with `-XX:-TieredCompilation` because the compilation is inserting a `CastPP` node for the input of the `StoreP` node and this is restricting the type of the barrier to `notnull`. The test regex checks for exactly `pre post` (nothing after that) and thus fails.
This change fixes the test IR rules by restricting the current ones to `-XX:+TieredCompilation` and checking for `pre post notnull` for the `-XX:-TieredCompilation` case.

Tests: Tier 1-3+

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

Commit messages:
 - JDK-8361166: [lworld] TestG1BarrierGeneration still fails after JDK-8343420

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

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

From chagedorn at openjdk.org  Mon Jul  7 07:46:57 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 7 Jul 2025 07:46:57 GMT
Subject: [lworld] RFR: 8361166: [lworld] TestG1BarrierGeneration still
 fails after JDK-8343420
In-Reply-To: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
References: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
Message-ID: <qz-CcMp8kexW_WOrOjDR4AhDm_MYxeeuTpgMy0w-gTU=.066ac4d5-c385-4e6d-a1b5-8f2f60dd999b@github.com>

On Fri, 4 Jul 2025 14:40:37 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> The `TestG1BarrierGeneration::testArrayStore` and `TestG1BarrierGeneration::testArrayStoreTwice` tests are failing with `-XX:-TieredCompilation` because the compilation is inserting a `CastPP` node for the input of the `StoreP` node and this is restricting the type of the barrier to `notnull`. The test regex checks for exactly `pre post` (nothing after that) and thus fails.
> This change fixes the test IR rules by restricting the current ones to `-XX:+TieredCompilation` and checking for `pre post notnull` for the `-XX:-TieredCompilation` case.
> 
> Tests: Tier 1-3+

Thanks for working on this! Have you found out why the `CastPP` is inserted without tiered compilation but not with tiered compilation? Are we missing some profiling? In the latter case, you could also try to increase the warm-up iterations and see if that works instead.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1502#issuecomment-3043834007

From thartmann at openjdk.org  Mon Jul  7 09:03:07 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Jul 2025 09:03:07 GMT
Subject: [lworld] RFR: 8361250: [lworld] use more IRNode regexes in
 valhalla IR tests
In-Reply-To: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
References: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
Message-ID: <u8bsSwzz_bLYR2vn2f-XJRz76uEsO44O71piJbdvqMw=.58090668-7500-4ee8-b303-82d8321a3f03@github.com>

On Fri, 4 Jul 2025 16:36:36 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.
> 
> The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.
> 
> So what now:
> - `InlineTypeRegexes` => only value regexes.
> - `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
> - `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
> - `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.

This is a very nice cleanup. Thanks for working on this, Marc! Looks good, just a few comments.

test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 931:

> 929:     }
> 930: 
> 931:     public static void anyLoadOfNodes(String irNodePlaceholder, String loadee) {

Should `loadee` be `holder` or `fieldHolder`?

test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 1950:

> 1948:     }
> 1949: 
> 1950:     public static void anyStoreOfNodes(String irNodePlaceholder, String storee) {

Should `storee` be `holder` or `fieldHolder`? Same below.

test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 2918:

> 2916: 
> 2917:     private static void nonFlatStoreOfNodes(String irNodePlaceholder, String irNodeRegex, String storee) {
> 2918:         String regex = START + irNodeRegex + MID + "@((stable:)?\\w+/)*" + storee + STORE_OF_CLASS_POSTFIX;

The only difference to `storeOfNodes` seems to be the `stable:` part but that is not specific to flat stores, right?

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1503#pullrequestreview-2992840207
PR Review Comment: https://git.openjdk.org/valhalla/pull/1503#discussion_r2189419868
PR Review Comment: https://git.openjdk.org/valhalla/pull/1503#discussion_r2189420985
PR Review Comment: https://git.openjdk.org/valhalla/pull/1503#discussion_r2189425709

From dfenacci at openjdk.org  Mon Jul  7 09:30:19 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 7 Jul 2025 09:30:19 GMT
Subject: [lworld] RFR: 8361166: [lworld] TestG1BarrierGeneration still
 fails after JDK-8343420 [v2]
In-Reply-To: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
References: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
Message-ID: <0dVT-52AdHUgEGjc8jmS-vkt7ZTLWdvkCC9SlPXt2Mw=.e7c65774-292f-452b-9c06-f6a62ae67fd9@github.com>

> The `TestG1BarrierGeneration::testArrayStore` and `TestG1BarrierGeneration::testArrayStoreTwice` tests are failing with `-XX:-TieredCompilation` because the compilation is inserting a `CastPP` node for the input of the `StoreP` node and this is restricting the type of the barrier to `notnull`. The test regex checks for exactly `pre post` (nothing after that) and thus fails.
> This change fixes the test IR rules by restricting the current ones to `-XX:+TieredCompilation` and checking for `pre post notnull` for the `-XX:-TieredCompilation` case.
> 
> Tests: Tier 1-3+

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

  JDK-8361166: increase warmup instead of trating -TieredCompilation differently

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1502/files
  - new: https://git.openjdk.org/valhalla/pull/1502/files/25d00b40..a4617bde

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

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

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

From dfenacci at openjdk.org  Mon Jul  7 10:31:55 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 7 Jul 2025 10:31:55 GMT
Subject: [lworld] RFR: 8361166: [lworld] TestG1BarrierGeneration still
 fails after JDK-8343420
In-Reply-To: <qz-CcMp8kexW_WOrOjDR4AhDm_MYxeeuTpgMy0w-gTU=.066ac4d5-c385-4e6d-a1b5-8f2f60dd999b@github.com>
References: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
 <qz-CcMp8kexW_WOrOjDR4AhDm_MYxeeuTpgMy0w-gTU=.066ac4d5-c385-4e6d-a1b5-8f2f60dd999b@github.com>
Message-ID: <WXZzC2BIYRpOeDqv-BeWeclZfyXJJWo2dJnA3rw8CRQ=.80dc61cf-c3ff-4060-87a1-39595c7a4781@github.com>

On Mon, 7 Jul 2025 07:44:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Have you found out why the `CastPP` is inserted without tiered compilation but not with tiered compilation? Are we missing some profiling?

Yes, this seems to be the reason.

> In the latter case, you could also try to increase the warm-up iterations and see if that works instead.

Of course! Much nicer solution. Thanks @chhagedorn.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1502#issuecomment-3044372233

From chagedorn at openjdk.org  Mon Jul  7 11:57:52 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 7 Jul 2025 11:57:52 GMT
Subject: [lworld] RFR: 8361166: [lworld] TestG1BarrierGeneration still
 fails after JDK-8343420 [v2]
In-Reply-To: <0dVT-52AdHUgEGjc8jmS-vkt7ZTLWdvkCC9SlPXt2Mw=.e7c65774-292f-452b-9c06-f6a62ae67fd9@github.com>
References: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
 <0dVT-52AdHUgEGjc8jmS-vkt7ZTLWdvkCC9SlPXt2Mw=.e7c65774-292f-452b-9c06-f6a62ae67fd9@github.com>
Message-ID: <ygMlJN_ZDB6Dwq0tZ4F5NDEStJG5ZcCyRk0wMTWPZB8=.33f6c90f-c023-4f12-b34a-2834264fe2ea@github.com>

On Mon, 7 Jul 2025 09:30:19 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> The `TestG1BarrierGeneration::testArrayStore` and `TestG1BarrierGeneration::testArrayStoreTwice` tests are failing with `-XX:-TieredCompilation` because the compilation is inserting a `CastPP` node for the input of the `StoreP` node (due to missing profiling info) and this is restricting the type of the barrier to `notnull`. The test regex checks for exactly `pre post` (nothing after that) and thus fails.
>> This change fixes the test by increasing the warmup iterations for the failing tests.
>> 
>> Tests: Tier 1-3+
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8361166: increase warmup instead of trating -TieredCompilation differently

That's great and looks simpler, thanks!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1502#pullrequestreview-2993496245

From matsaave at openjdk.org  Mon Jul  7 21:32:07 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 7 Jul 2025 21:32:07 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v6]
In-Reply-To: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
Message-ID: <MDQbWQgjUx06Q1rB_wIBXGr2ZFkH97Mpb5J8jf6C8qA=.e8e22c4b-7e3a-4c06-b065-a53697a3f383@github.com>

> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
> 
> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Fred comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1498/files
  - new: https://git.openjdk.org/valhalla/pull/1498/files/5f200d56..4fd130b4

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

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

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

From liach at openjdk.org  Mon Jul  7 22:49:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Jul 2025 22:49:10 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue() leads
 to failed assert
Message-ID: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>

Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.

I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.

Testing: tier 1-3, seems to have no new failures

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

Commit messages:
 - More fixes
 - 8361496: [lworld] Treating interfaces as isValue() leads to failed assert

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

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

From liach at openjdk.org  Tue Jul  8 00:41:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 00:41:57 GMT
Subject: [lworld] RFR: 8360653: [lworld] LayoutIterationTest.java fails with
 -XX:ForceNonTearable=*
Message-ID: <uSZPYtwpQQW2sQH0w69cAsJIZl3z0AaG4Abr2nURGpc=.1d983bb0-6d8c-4200-acdb-cf9a2a440897@github.com>

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

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

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

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

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

From rriggs at openjdk.org  Tue Jul  8 02:54:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Jul 2025 02:54:46 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert
In-Reply-To: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
Message-ID: <hzK8E3rx8MC0LXkHJsFNwp6x65B3xe7JPbnWk-glJc8=.2c5c3ccf-37f8-47d4-af39-4dc042c830fc@github.com>

On Mon, 7 Jul 2025 22:44:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
> 
> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
> 
> Testing: tier 1-3, seems to have no new failures

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

> 641:             return false;
> 642:         }
> 643:         return !isIdentity();

Copy the lines from PR#1499.
Nothing is value unless preview is enabled.

Suggestion:

        return PreviewFeatures.isEnabled() ? !isIdentity() : false;

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2191371327

From rriggs at openjdk.org  Tue Jul  8 03:01:49 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Jul 2025 03:01:49 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert
In-Reply-To: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
Message-ID: <yjUPfzlWG0bkBZSHvVjcYo9NZgHJT9ZjRlLPm_9uF5w=.007a06f9-22e1-41f6-822c-d88df9a26623@github.com>

On Mon, 7 Jul 2025 22:44:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
> 
> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
> 
> Testing: tier 1-3, seems to have no new failures

test/jdk/valhalla/valuetypes/ValueClassTest.java line 43:

> 41: class ValueClassTest {
> 42:     @Test
> 43:     void testIsValueObjectCompatible() {

Should this test be run both with and without --enable-preview?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2191376177

From liach at openjdk.org  Tue Jul  8 03:14:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 03:14:53 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert
In-Reply-To: <hzK8E3rx8MC0LXkHJsFNwp6x65B3xe7JPbnWk-glJc8=.2c5c3ccf-37f8-47d4-af39-4dc042c830fc@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <hzK8E3rx8MC0LXkHJsFNwp6x65B3xe7JPbnWk-glJc8=.2c5c3ccf-37f8-47d4-af39-4dc042c830fc@github.com>
Message-ID: <FoJULAIGlH2ovgVIrYszXa8Nm8IEd2G426LjnxcBb4w=.caeb0e80-38ec-468f-bc59-057863df73d8@github.com>

On Tue, 8 Jul 2025 02:52:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
>> 
>> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
>> 
>> Testing: tier 1-3, seems to have no new failures
>
> src/java.base/share/classes/java/lang/Class.java line 643:
> 
>> 641:             return false;
>> 642:         }
>> 643:         return !isIdentity();
> 
> Copy the lines from PR#1499.
> Nothing is value unless preview is enabled.
> 
> Suggestion:
> 
>         return PreviewFeatures.isEnabled() ? !isIdentity() : false;

This preview switch is retained right above the first deletion in this small piece of diff.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2191386889

From dfenacci at openjdk.org  Tue Jul  8 13:40:01 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 8 Jul 2025 13:40:01 GMT
Subject: [lworld] RFR: 8361166: [lworld] TestG1BarrierGeneration still
 fails after JDK-8343420
In-Reply-To: <qz-CcMp8kexW_WOrOjDR4AhDm_MYxeeuTpgMy0w-gTU=.066ac4d5-c385-4e6d-a1b5-8f2f60dd999b@github.com>
References: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
 <qz-CcMp8kexW_WOrOjDR4AhDm_MYxeeuTpgMy0w-gTU=.066ac4d5-c385-4e6d-a1b5-8f2f60dd999b@github.com>
Message-ID: <sk0FDWIvXWLqstZEkvxsh1RrPPTI-NRoyvbhgVOotQo=.03df6b65-b94d-4ebb-a446-7a4fe59ff643@github.com>

On Mon, 7 Jul 2025 07:44:04 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The `TestG1BarrierGeneration::testArrayStore` and `TestG1BarrierGeneration::testArrayStoreTwice` tests are failing with `-XX:-TieredCompilation` because the compilation is inserting a `CastPP` node for the input of the `StoreP` node (due to missing profiling info) and this is restricting the type of the barrier to `notnull`. The test regex checks for exactly `pre post` (nothing after that) and thus fails.
>> This change fixes the test by increasing the warmup iterations for the failing tests.
>> 
>> Tests: Tier 1-3+
>
> Thanks for working on this! Have you found out why the `CastPP` is inserted without tiered compilation but not with tiered compilation? Are we missing some profiling? In the latter case, you could also try to increase the warm-up iterations and see if that works instead.

Thanks for your review @chhagedorn.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1502#issuecomment-3049002459

From duke at openjdk.org  Tue Jul  8 13:40:02 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Jul 2025 13:40:02 GMT
Subject: [lworld] RFR: 8361166: [lworld] TestG1BarrierGeneration still
 fails after JDK-8343420 [v2]
In-Reply-To: <0dVT-52AdHUgEGjc8jmS-vkt7ZTLWdvkCC9SlPXt2Mw=.e7c65774-292f-452b-9c06-f6a62ae67fd9@github.com>
References: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
 <0dVT-52AdHUgEGjc8jmS-vkt7ZTLWdvkCC9SlPXt2Mw=.e7c65774-292f-452b-9c06-f6a62ae67fd9@github.com>
Message-ID: <lIAdEoEhfm4o_AuwB99TFtgDQNIGyJkNqPxJ8LN4zpU=.9a8d4e5a-1cc5-473a-888b-0f0c4fb94fa4@github.com>

On Mon, 7 Jul 2025 09:30:19 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> The `TestG1BarrierGeneration::testArrayStore` and `TestG1BarrierGeneration::testArrayStoreTwice` tests are failing with `-XX:-TieredCompilation` because the compilation is inserting a `CastPP` node for the input of the `StoreP` node (due to missing profiling info) and this is restricting the type of the barrier to `notnull`. The test regex checks for exactly `pre post` (nothing after that) and thus fails.
>> This change fixes the test by increasing the warmup iterations for the failing tests.
>> 
>> Tests: Tier 1-3+
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8361166: increase warmup instead of trating -TieredCompilation differently

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1502#issuecomment-3049007920

From liach at openjdk.org  Tue Jul  8 14:19:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 14:19:54 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert
In-Reply-To: <yjUPfzlWG0bkBZSHvVjcYo9NZgHJT9ZjRlLPm_9uF5w=.007a06f9-22e1-41f6-822c-d88df9a26623@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <yjUPfzlWG0bkBZSHvVjcYo9NZgHJT9ZjRlLPm_9uF5w=.007a06f9-22e1-41f6-822c-d88df9a26623@github.com>
Message-ID: <TRgGfN3gStXQQ_b95M_2I31UCQzgCGOEde_i_4e8Qy4=.19d1879f-f67e-491a-b8f5-77b1f52ea218@github.com>

On Tue, 8 Jul 2025 02:58:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
>> 
>> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
>> 
>> Testing: tier 1-3, seems to have no new failures
>
> test/jdk/valhalla/valuetypes/ValueClassTest.java line 43:
> 
>> 41: class ValueClassTest {
>> 42:     @Test
>> 43:     void testIsValueObjectCompatible() {
> 
> Should this test be run both with and without --enable-preview?

Like replace all `assertTrue(` with `assertEquals(PreviewFeatures.isEnabled(), `? That sounds reasonable.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2192659884

From liach at openjdk.org  Tue Jul  8 14:34:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 14:34:50 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v2]
In-Reply-To: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
Message-ID: <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>

> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
> 
> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
> 
> Testing: tier 1-3, seems to have no new failures

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Test both preview and non-preview for ValueClassTest

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1504/files
  - new: https://git.openjdk.org/valhalla/pull/1504/files/d9d4668f..425ad16d

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

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

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

From dfenacci at openjdk.org  Tue Jul  8 15:08:54 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Tue, 8 Jul 2025 15:08:54 GMT
Subject: [lworld] Integrated: 8361166: [lworld] TestG1BarrierGeneration still
 fails after JDK-8343420
In-Reply-To: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
References: <XPSY-s531kinJWa_SDcFcZeL6LQce1YFaZzwM2-jAi8=.df4e8af6-6bc3-45bd-9bab-2bad751ea9f4@github.com>
Message-ID: <7AZtXCM48u5zfNRysUaNrAD40zkQdcbxRRK8XFWUrIE=.bc2eb530-ed28-495b-b9bc-2bf1adb9b3c0@github.com>

On Fri, 4 Jul 2025 14:40:37 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> The `TestG1BarrierGeneration::testArrayStore` and `TestG1BarrierGeneration::testArrayStoreTwice` tests are failing with `-XX:-TieredCompilation` because the compilation is inserting a `CastPP` node for the input of the `StoreP` node (due to missing profiling info) and this is restricting the type of the barrier to `notnull`. The test regex checks for exactly `pre post` (nothing after that) and thus fails.
> This change fixes the test by increasing the warmup iterations for the failing tests.
> 
> Tests: Tier 1-3+

This pull request has now been integrated.

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

8361166: [lworld] TestG1BarrierGeneration still fails after JDK-8343420

Reviewed-by: chagedorn

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

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

From mchevalier at openjdk.org  Wed Jul  9 13:29:11 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Jul 2025 13:29:11 GMT
Subject: [lworld] RFR: 8361250: [lworld] use more IRNode regexes in
 valhalla IR tests [v2]
In-Reply-To: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
References: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
Message-ID: <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>

> InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.
> 
> The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.
> 
> So what now:
> - `InlineTypeRegexes` => only value regexes.
> - `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
> - `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
> - `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.

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

  Address comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1503/files
  - new: https://git.openjdk.org/valhalla/pull/1503/files/90dfdf16..6dc2405e

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

  Stats: 48 lines in 6 files changed: 13 ins; 20 del; 15 mod
  Patch: https://git.openjdk.org/valhalla/pull/1503.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1503/head:pull/1503

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

From mchevalier at openjdk.org  Wed Jul  9 13:33:52 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Jul 2025 13:33:52 GMT
Subject: [lworld] RFR: 8361250: [lworld] use more IRNode regexes in
 valhalla IR tests [v2]
In-Reply-To: <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
References: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
 <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
Message-ID: <oLinTu1EciTNa5YJdbBRejrwnHaACQxf7TWwAshfMpM=.6a9cdf33-9425-42a2-a56f-3a1d7c27d218@github.com>

On Wed, 9 Jul 2025 13:29:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.
>> 
>> The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.
>> 
>> So what now:
>> - `InlineTypeRegexes` => only value regexes.
>> - `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
>> - `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
>> - `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Address the various comments, found that some tests was passing by accident (failOn on a regex that would never match), improve load/store regexps, fix the tests.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1503#issuecomment-3052690035

From thartmann at openjdk.org  Wed Jul  9 14:26:48 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 9 Jul 2025 14:26:48 GMT
Subject: [lworld] RFR: 8361250: [lworld] use more IRNode regexes in
 valhalla IR tests [v2]
In-Reply-To: <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
References: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
 <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
Message-ID: <cqDcq-OK-wnwn5W3yA6aGYqjEpuFartUEGVuVpOJkjM=.ca83a42f-ecbc-4add-b3ea-a5d2af56d62c@github.com>

On Wed, 9 Jul 2025 13:29:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.
>> 
>> The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.
>> 
>> So what now:
>> - `InlineTypeRegexes` => only value regexes.
>> - `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
>> - `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
>> - `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Good catch, I assume you'll upstream the Valhalla independent fix with [JDK-8361492](https://bugs.openjdk.org/browse/JDK-8361492)?

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1503#pullrequestreview-3001789266

From coleenp at openjdk.org  Wed Jul  9 16:03:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Jul 2025 16:03:55 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v6]
In-Reply-To: <MDQbWQgjUx06Q1rB_wIBXGr2ZFkH97Mpb5J8jf6C8qA=.e8e22c4b-7e3a-4c06-b065-a53697a3f383@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <MDQbWQgjUx06Q1rB_wIBXGr2ZFkH97Mpb5J8jf6C8qA=.e8e22c4b-7e3a-4c06-b065-a53697a3f383@github.com>
Message-ID: <vlDdi6-b0r-gOYYukp4cLTIJTAfIVUharOcNYAcCwVs=.12123a36-765b-4f51-ab09-5d8c2953e4df@github.com>

On Mon, 7 Jul 2025 21:32:07 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
>> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
>> 
>> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fred comments

I still have a couple of minor comments.

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

> 6173:                     err_msg("Class %s cannot have a null-free non-static field of its own type", _class_name->as_C_string()));
> 6174:         }
> 6175:         log_info(class, preload)("Preloading class %s during loading of class %s. \

I don't think the backslash is the right thing to do.  The C++ compiler will concatenate strings like "one " " two" so you should do that.

src/hotspot/share/oops/instanceKlass.cpp line 3594:

> 3592: }
> 3593: 
> 3594: void InstanceKlass::can_be_annotated_with_NullRestricted(InstanceKlass* type, Symbol* container_klass_name, TRAPS) {

The name "can_be" implies that it'll return a bool  Maybe a better name would be check_can_be_null_restricted(),

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

PR Review: https://git.openjdk.org/valhalla/pull/1498#pullrequestreview-3002109108
PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2195377885
PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2195395436

From coleenp at openjdk.org  Wed Jul  9 16:03:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Jul 2025 16:03:55 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v3]
In-Reply-To: <E0W_RK09aaO_6po5aTdyUzQK94KN4ebgqJoaghBR_48=.8b67352a-4f47-4f4a-a469-9b399b7fdf42@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <Zx9vZgon08kHyrccFE4KnL5nwVNGFLBWmsGWmSe9b0k=.8b1694be-30a4-4dc8-8c09-c67d5cbf51d1@github.com>
 <E0W_RK09aaO_6po5aTdyUzQK94KN4ebgqJoaghBR_48=.8b67352a-4f47-4f4a-a469-9b399b7fdf42@github.com>
Message-ID: <JEIz5SFdwZ9AUkgW2tcXd0qMVD2-D11oG8zpva21sYc=.68758bb7-9b6f-4f20-9597-970fb7de6a38@github.com>

On Wed, 2 Jul 2025 19:15:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Cleanup
>>  - Multilined another log message
>>  - Changed long log messages to multi-line strings
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1195:
> 
>> 1193: 
>> 1194:       if (fs.is_null_free_inline_type()) {
>> 1195:         bool check = preload_from_null_free_field(ik, class_loader, sig, field_index, CHECK_NULL);
> 
> This is a bit confusing that it both has a check for return and CHECK_NULL.  Add a comment that some preloading might fail but not fatally for the shared archive if the class changed in the app.

Can you add comment like:

// A false return means that the class didn't load for other reasons than an exception.

Something like that?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1498#discussion_r2195389138

From matsaave at openjdk.org  Wed Jul  9 18:24:32 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 9 Jul 2025 18:24:32 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v7]
In-Reply-To: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
Message-ID: <hZ8gmlOKCRCB4Ykx3LjTHFwASjtc-q6CjOUAV6IN3X0=.e011a15f-9f4b-4a64-b874-654c697dc51b@github.com>

> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
> 
> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Coleen comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1498/files
  - new: https://git.openjdk.org/valhalla/pull/1498/files/4fd130b4..146bda17

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

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

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

From matsaave at openjdk.org  Wed Jul  9 18:34:03 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 9 Jul 2025 18:34:03 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v8]
In-Reply-To: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
Message-ID: <d_FGC9p2AAcmF702ZkJcdZcPrt4iZWcTlq_C5BVezmU=.4e785ab9-9d0a-4ca5-abe2-aa6528101dde@github.com>

> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
> 
> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. 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 pull request now contains 12 commits:

 - Remove test from problemlist
 - Merge branch 'lworld' into loadable_descriptors_crash_8361082
 - Coleen comments
 - Fred comments
 - Used new method in classfileparser
 - Coleen comments
 - Cleanup
 - Multilined another log message
 - Changed long log messages to multi-line strings
 - Added comments
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/64ba13bc...bdb81d0f

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

Changes: https://git.openjdk.org/valhalla/pull/1498/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1498&range=07
  Stats: 178 lines in 6 files changed: 116 ins; 43 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1498.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1498/head:pull/1498

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

From coleenp at openjdk.org  Wed Jul  9 18:44:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Jul 2025 18:44:52 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v8]
In-Reply-To: <d_FGC9p2AAcmF702ZkJcdZcPrt4iZWcTlq_C5BVezmU=.4e785ab9-9d0a-4ca5-abe2-aa6528101dde@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <d_FGC9p2AAcmF702ZkJcdZcPrt4iZWcTlq_C5BVezmU=.4e785ab9-9d0a-4ca5-abe2-aa6528101dde@github.com>
Message-ID: <NBazRPYp0cmcRSjtYjzYmCSKH3OAiLjIzpRyUCpCrK0=.41e5a87f-41ab-4dad-b705-5b2d568b55f3@github.com>

On Wed, 9 Jul 2025 18:34:03 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
>> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
>> 
>> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. 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 pull request now contains 12 commits:
> 
>  - Remove test from problemlist
>  - Merge branch 'lworld' into loadable_descriptors_crash_8361082
>  - Coleen comments
>  - Fred comments
>  - Used new method in classfileparser
>  - Coleen comments
>  - Cleanup
>  - Multilined another log message
>  - Changed long log messages to multi-line strings
>  - Added comments
>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/64ba13bc...bdb81d0f

Looks good!

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1498#pullrequestreview-3002692531

From mchevalier at openjdk.org  Wed Jul  9 21:49:59 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 9 Jul 2025 21:49:59 GMT
Subject: [lworld] RFR: 8361250: [lworld] use more IRNode regexes in
 valhalla IR tests [v2]
In-Reply-To: <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
References: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
 <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
Message-ID: <URt82fS01oPk9w4P9L-cIcLV60miGrkYezDLv3_comk=.fbf4901a-b158-4946-b691-faae9f110df8@github.com>

On Wed, 9 Jul 2025 13:29:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.
>> 
>> The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.
>> 
>> So what now:
>> - `InlineTypeRegexes` => only value regexes.
>> - `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
>> - `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
>> - `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

That is the plan, indeed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1503#issuecomment-3054176502

From mchevalier at openjdk.org  Thu Jul 10 07:31:54 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 10 Jul 2025 07:31:54 GMT
Subject: [lworld] RFR: 8361250: [lworld] use more IRNode regexes in
 valhalla IR tests [v2]
In-Reply-To: <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
References: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
 <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
Message-ID: <dyxBhS35bBZ1G5eH3w6Qd8Z0lAWABNSL-2Ycdsk6d_M=.569eb602-8134-4d82-8880-c310a79e7d9f@github.com>

On Wed, 9 Jul 2025 13:29:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.
>> 
>> The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.
>> 
>> So what now:
>> - `InlineTypeRegexes` => only value regexes.
>> - `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
>> - `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
>> - `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Thanks @TobiHartmann!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1503#issuecomment-3056051303

From duke at openjdk.org  Thu Jul 10 07:31:54 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 07:31:54 GMT
Subject: [lworld] RFR: 8361250: [lworld] use more IRNode regexes in
 valhalla IR tests [v2]
In-Reply-To: <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
References: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
 <OHJfgHljIlqXho8U6t4bCEmzJ2LpKTRph6D7oeMoJ6s=.618a2a99-dde0-4f67-8e01-705f6ece701d@github.com>
Message-ID: <b0FUJXF6eeUfIvCbczXPi1ebky__r4ferT4tqJP_RT0=.f350c849-6b8f-4de9-88b7-70dc0b6c7678@github.com>

On Wed, 9 Jul 2025 13:29:11 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.
>> 
>> The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.
>> 
>> So what now:
>> - `InlineTypeRegexes` => only value regexes.
>> - `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
>> - `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
>> - `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1503#issuecomment-3056054657

From mchevalier at openjdk.org  Thu Jul 10 11:38:53 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 10 Jul 2025 11:38:53 GMT
Subject: [lworld] Integrated: 8361250: [lworld] use more IRNode regexes in
 valhalla IR tests
In-Reply-To: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
References: <ijQVyeL1Evr7FOl9Pp-DJ1g5DKQTjIaXUlvbcBU-vWc=.d402b9cf-00f1-4d1d-9734-32c1f3f3d626@github.com>
Message-ID: <xiuTT5A7ZWRCWs8Cv7QWgx8100y8Y-DD_kOIDrEKtfA=.07692048-a1c5-4b17-8466-512fb3cde982@github.com>

On Fri, 4 Jul 2025 16:36:36 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> InlineTypeIRNode is Valhalla-specific and somewhat... antique. I've run into an issue where the old-timey regex for allocation didn't do the job. So, rather than reproducing the fix of [JDK-8314999](https://bugs.openjdk.org/browse/JDK-8314999) again, let's simply use `IRNode`'s regex for Valhalla as well.
> 
> The general idea: let's not define node regex specifically for Valhalla, but only for values. I've also introduced regexes for combinations we do all the time: for instance rather than having `ALLOC_OF, ANY_KLASS`, I made a `ALLOC_OF_ANY_KLASS`.
> 
> So what now:
> - `InlineTypeRegexes` => only value regexes.
> - `IRNode` => adapted to allow to define specialisation for `ALLOC_OF`, `ALLOC_ARRAY_OF`, `LOAD_OF_CLASS`, `STORE_OF_CLASS`, `STATIC_CALL_OF_METHOD` for specific classes/functions.
> - `InlineTypeIRNode` => define specialisations using the regexes defined in `InlineTypeRegexes`, nothing more!
> - `compiler/valhalla/inlinetypes/Test*` => use `IRNode` and `InlineTypeIRNode`.

This pull request has now been integrated.

Changeset: 680efc43
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/680efc43f77e62695f0a4c5750bc3645697ae96c
Stats:     759 lines in 15 files changed: 150 ins; 153 del; 456 mod

8361250: [lworld] use more IRNode regexes in valhalla IR tests

Reviewed-by: thartmann

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

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

From fparain at openjdk.org  Thu Jul 10 13:56:53 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 10 Jul 2025 13:56:53 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v8]
In-Reply-To: <d_FGC9p2AAcmF702ZkJcdZcPrt4iZWcTlq_C5BVezmU=.4e785ab9-9d0a-4ca5-abe2-aa6528101dde@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <d_FGC9p2AAcmF702ZkJcdZcPrt4iZWcTlq_C5BVezmU=.4e785ab9-9d0a-4ca5-abe2-aa6528101dde@github.com>
Message-ID: <F4Cwm5lDP8ZNnMXNsoLO2eFM2K5XHWDAVCAUF0DF0AY=.810abaf1-37a2-483c-bcbe-c4cd47af4ab5@github.com>

On Wed, 9 Jul 2025 18:34:03 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
>> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
>> 
>> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. 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 pull request now contains 12 commits:
> 
>  - Remove test from problemlist
>  - Merge branch 'lworld' into loadable_descriptors_crash_8361082
>  - Coleen comments
>  - Fred comments
>  - Used new method in classfileparser
>  - Coleen comments
>  - Cleanup
>  - Multilined another log message
>  - Changed long log messages to multi-line strings
>  - Added comments
>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/64ba13bc...bdb81d0f

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1498#pullrequestreview-3005810048

From matsaave at openjdk.org  Thu Jul 10 14:06:54 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 10 Jul 2025 14:06:54 GMT
Subject: [lworld] Integrated: 8361082: [lworld] RewriteBytecodesInlineTest
 fails with SIGSEGV
In-Reply-To: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
Message-ID: <cSZANS5V-VQRjNBnxhJ0e0jhPCUdvqTecWeI3KPag6c=.8e72e351-92e7-45d1-bf1c-ce814da9d987@github.com>

On Wed, 2 Jul 2025 16:45:54 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> `RewriteBytecodesInlineTest` fails after # due to a new log message printing the pending exception name even though there may not be a pending exception:
> `PENDING_EXCEPTION->klass()->name()->as_C_string()`
> 
> This patch refactors the loadable descriptor handling used in `SystemDictionary::load_shared_class` to better illustrate how the loadable descriptors property is handled and it corrects the log messages to be consistent with the messages used in the class file parser. Verified with tier 1-5 tests.

This pull request has now been integrated.

Changeset: 7e4c1bc1
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7e4c1bc1753bcd9655214eca32c391d28af43267
Stats:     178 lines in 6 files changed: 116 ins; 43 del; 19 mod

8361082: [lworld] RewriteBytecodesInlineTest fails with SIGSEGV

Reviewed-by: coleenp, fparain

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

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

From matsaave at openjdk.org  Thu Jul 10 14:06:54 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 10 Jul 2025 14:06:54 GMT
Subject: [lworld] RFR: 8361082: [lworld] RewriteBytecodesInlineTest fails
 with SIGSEGV [v8]
In-Reply-To: <NBazRPYp0cmcRSjtYjzYmCSKH3OAiLjIzpRyUCpCrK0=.41e5a87f-41ab-4dad-b705-5b2d568b55f3@github.com>
References: <al5uny78hqFZRZjSU25SZzX68ChPoPCdTWWZNu5v_UU=.9c8f6771-7a93-4a0e-8d3d-a26ed6d69e21@github.com>
 <d_FGC9p2AAcmF702ZkJcdZcPrt4iZWcTlq_C5BVezmU=.4e785ab9-9d0a-4ca5-abe2-aa6528101dde@github.com>
 <NBazRPYp0cmcRSjtYjzYmCSKH3OAiLjIzpRyUCpCrK0=.41e5a87f-41ab-4dad-b705-5b2d568b55f3@github.com>
Message-ID: <suW8zFe8-lh-vEYnUrsaldVYaAZPnltYcF-GD7FDZM0=.159c91e5-c8f2-4b0b-b5ca-16e08b63b0c9@github.com>

On Wed, 9 Jul 2025 18:42:34 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 pull request now contains 12 commits:
>> 
>>  - Remove test from problemlist
>>  - Merge branch 'lworld' into loadable_descriptors_crash_8361082
>>  - Coleen comments
>>  - Fred comments
>>  - Used new method in classfileparser
>>  - Coleen comments
>>  - Cleanup
>>  - Multilined another log message
>>  - Changed long log messages to multi-line strings
>>  - Added comments
>>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/64ba13bc...bdb81d0f
>
> Looks good!

Thanks for the reviews @coleenp and @fparain!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1498#issuecomment-3057601953

From vromero at openjdk.org  Fri Jul 11 20:59:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Jul 2025 20:59:38 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v2]
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <qCyhrdoFN2vqR-c6XDaByeUpyjnaN22E6Ffn60ZptHo=.82b528a3-1f17-4318-9b79-b3d6c9d59fdd@github.com>

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

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

  adding comments, etc

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1490/files
  - new: https://git.openjdk.org/valhalla/pull/1490/files/83b92556..95fb2a80

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

  Stats: 71 lines in 3 files changed: 39 ins; 25 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/1490.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1490/head:pull/1490

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

From mchevalier at openjdk.org  Mon Jul 14 12:02:10 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 14 Jul 2025 12:02:10 GMT
Subject: [lworld] RFR: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails
Message-ID: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>

The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:

AFTER: ITER_GVN_AFTER_ELIMINATION
  0  Root  === 0 21  [[ 0 1 3 ]]
  3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
  5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
  6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
  7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
  8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
  9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
 21  Return  === 5 6 7 8 9  [[ 0 ]]

which is not surprising given this method has an empty body.

What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).

So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.

So the fix is just as simple as not trying to find a failure for this phase.

I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.

Thanks,
Marc

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

Commit messages:
 - Don't expect ITER_GVN_AFTER_ELIMINATION from NoCompilationOutput.badPhase2

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

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

From qamai at openjdk.org  Mon Jul 14 12:34:06 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 14 Jul 2025 12:34:06 GMT
Subject: [lworld] RFR: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails
In-Reply-To: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
References: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
Message-ID: <Q5OQnP5Gjo_SVNgGUlDMgJTNBZ1v7yoohlPrTRCjMpI=.7fca2674-d601-4d8e-8472-13787c3a1e97@github.com>

On Mon, 14 Jul 2025 11:55:06 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:
> 
> AFTER: ITER_GVN_AFTER_ELIMINATION
>   0  Root  === 0 21  [[ 0 1 3 ]]
>   3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
>   5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>  21  Return  === 5 6 7 8 9  [[ 0 ]]
> 
> which is not surprising given this method has an empty body.
> 
> What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).
> 
> So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
> https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
> And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.
> 
> So the fix is just as simple as not trying to find a failure for this phase.
> 
> I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.
> 
> Thanks,
> Marc

Can you guard the unconditional macro elimination with a condition that there are some macro nodes instead?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1508#issuecomment-3069314271

From mchevalier at openjdk.org  Mon Jul 14 12:38:56 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 14 Jul 2025 12:38:56 GMT
Subject: [lworld] RFR: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails
In-Reply-To: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
References: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
Message-ID: <SqXdgnDnPN0_r_Hxa3SEa803EctjGjwbP4FZHyJ93G0=.ede18b67-9304-44dd-a79e-da8efa2b2c52@github.com>

On Mon, 14 Jul 2025 11:55:06 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:
> 
> AFTER: ITER_GVN_AFTER_ELIMINATION
>   0  Root  === 0 21  [[ 0 1 3 ]]
>   3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
>   5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>  21  Return  === 5 6 7 8 9  [[ 0 ]]
> 
> which is not surprising given this method has an empty body.
> 
> What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).
> 
> So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
> https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
> And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.
> 
> So the fix is just as simple as not trying to find a failure for this phase.
> 
> I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.
> 
> Thanks,
> Marc

Sure!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1508#issuecomment-3069340148

From liach at openjdk.org  Mon Jul 14 15:13:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 15:13:04 GMT
Subject: [lworld] RFR: Include verification for strict fields in ClassFile API
Message-ID: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>

The lack of classfile verifier recognition of strict fields is the only part of class file API support left for strict fields.

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

Commit messages:
 - Include strict field stuff in classfile verifier
 - 8361526: Synchronize ClassFile API verifier with hotspot

Changes: https://git.openjdk.org/valhalla/pull/1506/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1506&range=00
  Stats: 492 lines in 14 files changed: 328 ins; 27 del; 137 mod
  Patch: https://git.openjdk.org/valhalla/pull/1506.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1506/head:pull/1506

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

From liach at openjdk.org  Mon Jul 14 15:17:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 15:17:00 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v2]
In-Reply-To: <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
Message-ID: <S69AxXcT7469OR0NdZb0z47k3VRsOD5pisgnjXyW7mo=.69bca568-d29b-418e-a4e1-7bd00203e9b5@github.com>

On Tue, 8 Jul 2025 14:34:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
>> 
>> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
>> 
>> Testing: tier 1-3, seems to have no new failures
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test both preview and non-preview for ValueClassTest

I have updated the test to test both preview and non-preview behaviors. May I get another review?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1504#issuecomment-3069974989

From vromero at openjdk.org  Mon Jul 14 17:04:48 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 14 Jul 2025 17:04:48 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v3]
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <Br-19nAd6oGyeRhgx2JQJDmtiljexf8OrgmsOrFrLsg=.3ddbd791-bc54-45f4-9a17-13501f043258@github.com>

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

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

  do not generate proxies for mutable fields

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1490/files
  - new: https://git.openjdk.org/valhalla/pull/1490/files/95fb2a80..9a172ea4

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

  Stats: 69 lines in 4 files changed: 23 ins; 40 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1490.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1490/head:pull/1490

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

From rriggs at openjdk.org  Mon Jul 14 17:44:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Jul 2025 17:44:50 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v2]
In-Reply-To: <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
Message-ID: <K_ifbEsUbW3ElFBF_Q1CgcabEZKegPgottA3h-MOP_Y=.08b4e964-8e52-4be9-9ba0-6fb2cd6f6ad0@github.com>

On Tue, 8 Jul 2025 14:34:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
>> 
>> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
>> 
>> Testing: tier 1-3, seems to have no new failures
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test both preview and non-preview for ValueClassTest

src/java.base/share/classes/jdk/internal/value/ValueClass.java line 45:

> 43:     /// This excludes primitives and includes Object.
> 44:     public static boolean isValueObjectCompatible(Class<?> fieldType) {
> 45:         return PreviewFeatures.isEnabled() && !fieldType.isPrimitive() && (!fieldType.isIdentity() || fieldType == Object.class);

The `fieldType == Object.class` would always be true regardless of enable-preview.
That does not seem to be accurate and might be mis-interpreted by a caller.

src/java.base/share/classes/jdk/internal/value/ValueClass.java line 50:

> 48:     /// {@return whether an object of this exact class is a value object}
> 49:     /// This excludes abstract value classes and primitives.
> 50:     public static boolean isValueObjectInstance(Class<?> clazz) {

The method name is a bit misleading, it seems to ask if the parameter is an instance, but it is a class.
Perhaps `isConcreteValueObject()` or `isConcreteValueClass()`.

test/jdk/valhalla/valuetypes/ValueClassTest.java line 60:

> 58:         assertFalse(isValueObjectCompatible(ArrayList[].class), "array class");
> 59:         assertFalse(isValueObjectCompatible(String[].class), "array class");
> 60:         assertFalse(isValueObjectCompatible(Comparable[].class), "array class");

If these ever fail, the error messages are not going to be very information  like`expected tru, actual = false Object`;
no mention of preview mode being tested or the method under test.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2205474466
PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2205467836
PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2205460154

From vromero at openjdk.org  Mon Jul 14 21:16:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 14 Jul 2025 21:16:51 GMT
Subject: [lworld] RFR: 8362181: [lworld] Include verification for strict
 fields in ClassFile API
In-Reply-To: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
References: <1m2vQXzXlB-TFt7yS4KfmuM1V1Bzyy8hMxlCG3xVAs8=.959e319f-002f-4c7f-b2cf-1102ed3bb37f@github.com>
Message-ID: <7LOHGCuiji4yqXxdM-TKbntxmERUjbs8UbjpSy8rBYQ=.31a1ae42-0a43-4cb6-a280-70be8c523b8b@github.com>

On Wed, 9 Jul 2025 16:36:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> The lack of classfile verifier recognition of strict fields is the only part of class file API support left for strict fields.

looks sensible

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1506#pullrequestreview-3017863988

From liach at openjdk.org  Mon Jul 14 21:17:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 21:17:51 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v2]
In-Reply-To: <K_ifbEsUbW3ElFBF_Q1CgcabEZKegPgottA3h-MOP_Y=.08b4e964-8e52-4be9-9ba0-6fb2cd6f6ad0@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
 <K_ifbEsUbW3ElFBF_Q1CgcabEZKegPgottA3h-MOP_Y=.08b4e964-8e52-4be9-9ba0-6fb2cd6f6ad0@github.com>
Message-ID: <pbWFY20upUkEFjnJI0mp9j4F4nRjfXgIu61Kd0DMNiU=.d4a52427-ea14-4390-91d8-970387b0b0b6@github.com>

On Mon, 14 Jul 2025 17:34:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test both preview and non-preview for ValueClassTest
>
> test/jdk/valhalla/valuetypes/ValueClassTest.java line 60:
> 
>> 58:         assertFalse(isValueObjectCompatible(ArrayList[].class), "array class");
>> 59:         assertFalse(isValueObjectCompatible(String[].class), "array class");
>> 60:         assertFalse(isValueObjectCompatible(Comparable[].class), "array class");
> 
> If these ever fail, the error messages are not going to be very information  like`expected tru, actual = false Object`;
> no mention of preview mode being tested or the method under test.

Junit composes the exception message with the expected, actual values and the string provided, also there is the line number.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2205843902

From mchevalier at openjdk.org  Tue Jul 15 09:16:35 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 15 Jul 2025 09:16:35 GMT
Subject: [lworld] RFR: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails [v2]
In-Reply-To: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
References: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
Message-ID: <qILAEpgt1yU4XAcPLS_5uLZ7RdCcIjaXTDCk8WQJtYk=.2f86d5b5-f5a0-44c6-85d4-e874dcce5e90@github.com>

> The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:
> 
> AFTER: ITER_GVN_AFTER_ELIMINATION
>   0  Root  === 0 21  [[ 0 1 3 ]]
>   3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
>   5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>  21  Return  === 5 6 7 8 9  [[ 0 ]]
> 
> which is not surprising given this method has an empty body.
> 
> What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).
> 
> So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
> https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
> And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.
> 
> So the fix is just as simple as not trying to find a failure for this phase.
> 
> I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.
> 
> ===
> 
> After review comment, let's change solution: the diagnostic is still valid, but instead, let's run macro expansion only when there are macro nodes. In our case, that means not to run it. The test needs no more fixing.
> 
> Thanks,
> Marc

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

  Run macro elimination only when there are macro nodes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1508/files
  - new: https://git.openjdk.org/valhalla/pull/1508/files/022f8a1a..e4e11913

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

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

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

From mchevalier at openjdk.org  Tue Jul 15 09:16:36 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 15 Jul 2025 09:16:36 GMT
Subject: [lworld] RFR: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails
In-Reply-To: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
References: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
Message-ID: <OhZDyWsSBi6l_O0LpeJfmjIoh5gFWB7bSNZCQyu8-bI=.f3c0a39c-0668-448a-8f6a-c92c2b64a3bf@github.com>

On Mon, 14 Jul 2025 11:55:06 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:
> 
> AFTER: ITER_GVN_AFTER_ELIMINATION
>   0  Root  === 0 21  [[ 0 1 3 ]]
>   3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
>   5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>  21  Return  === 5 6 7 8 9  [[ 0 ]]
> 
> which is not surprising given this method has an empty body.
> 
> What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).
> 
> So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
> https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
> And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.
> 
> So the fix is just as simple as not trying to find a failure for this phase.
> 
> I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.
> 
> ===
> 
> After review comment, let's change solution: the diagnostic is still valid, but instead, let's run macro expansion only when there are macro nodes. In our case, that means not to run it. The test needs no more fixing.
> 
> Thanks,
> Marc

The second new `if` is not required for the test to pass, but it seems more consistent to have it as well.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1508#issuecomment-3072829796

From qamai at openjdk.org  Tue Jul 15 09:22:47 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 15 Jul 2025 09:22:47 GMT
Subject: [lworld] RFR: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails [v2]
In-Reply-To: <qILAEpgt1yU4XAcPLS_5uLZ7RdCcIjaXTDCk8WQJtYk=.2f86d5b5-f5a0-44c6-85d4-e874dcce5e90@github.com>
References: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
 <qILAEpgt1yU4XAcPLS_5uLZ7RdCcIjaXTDCk8WQJtYk=.2f86d5b5-f5a0-44c6-85d4-e874dcce5e90@github.com>
Message-ID: <qtW8ukx3HmAgQr4JK1uZYCdnRyiNcXPnr1EEY-H8CuY=.aec5ae2b-c78f-4061-9352-e93233ac402a@github.com>

On Tue, 15 Jul 2025 09:16:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:
>> 
>> AFTER: ITER_GVN_AFTER_ELIMINATION
>>   0  Root  === 0 21  [[ 0 1 3 ]]
>>   3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
>>   5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>  21  Return  === 5 6 7 8 9  [[ 0 ]]
>> 
>> which is not surprising given this method has an empty body.
>> 
>> What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).
>> 
>> So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
>> https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
>> And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.
>> 
>> So the fix is just as simple as not trying to find a failure for this phase.
>> 
>> I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.
>> 
>> ===
>> 
>> After review comment, let's change solution: the diagnostic is still valid, but instead, let's run macro expansion only when there are macro nodes. In our case, that means not to run it. The test needs no more fixing.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Run macro elimination only when there are macro nodes

Marked as reviewed by qamai (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1508#pullrequestreview-3019491963

From thartmann at openjdk.org  Tue Jul 15 11:31:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 15 Jul 2025 11:31:52 GMT
Subject: [lworld] RFR: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails [v2]
In-Reply-To: <qILAEpgt1yU4XAcPLS_5uLZ7RdCcIjaXTDCk8WQJtYk=.2f86d5b5-f5a0-44c6-85d4-e874dcce5e90@github.com>
References: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
 <qILAEpgt1yU4XAcPLS_5uLZ7RdCcIjaXTDCk8WQJtYk=.2f86d5b5-f5a0-44c6-85d4-e874dcce5e90@github.com>
Message-ID: <HSJoOyOH-WQG3Q-5wsR6aT_qCWFeqtE2-VStXSi6_jA=.36123a9c-03d8-4d82-9fdf-47c50cfd574f@github.com>

On Tue, 15 Jul 2025 09:16:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:
>> 
>> AFTER: ITER_GVN_AFTER_ELIMINATION
>>   0  Root  === 0 21  [[ 0 1 3 ]]
>>   3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
>>   5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>  21  Return  === 5 6 7 8 9  [[ 0 ]]
>> 
>> which is not surprising given this method has an empty body.
>> 
>> What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).
>> 
>> So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
>> https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
>> And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.
>> 
>> So the fix is just as simple as not trying to find a failure for this phase.
>> 
>> I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.
>> 
>> ===
>> 
>> After review comment, let's change solution: the diagnostic is still valid, but instead, let's run macro expansion only when there are macro nodes. In our case, that means not to run it. The test needs no more fixing.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Run macro elimination only when there are macro nodes

Looks good to me too.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1508#pullrequestreview-3019897812

From mchevalier at openjdk.org  Tue Jul 15 11:36:59 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 15 Jul 2025 11:36:59 GMT
Subject: [lworld] RFR: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails [v2]
In-Reply-To: <qILAEpgt1yU4XAcPLS_5uLZ7RdCcIjaXTDCk8WQJtYk=.2f86d5b5-f5a0-44c6-85d4-e874dcce5e90@github.com>
References: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
 <qILAEpgt1yU4XAcPLS_5uLZ7RdCcIjaXTDCk8WQJtYk=.2f86d5b5-f5a0-44c6-85d4-e874dcce5e90@github.com>
Message-ID: <WZVMI6bQDJoykbLsuDPpgzb8fqUED5eZlRr13E3W9P4=.ed75dc5b-785b-43da-b7a7-4c25043e511d@github.com>

On Tue, 15 Jul 2025 09:16:35 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:
>> 
>> AFTER: ITER_GVN_AFTER_ELIMINATION
>>   0  Root  === 0 21  [[ 0 1 3 ]]
>>   3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
>>   5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>   9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>>  21  Return  === 5 6 7 8 9  [[ 0 ]]
>> 
>> which is not surprising given this method has an empty body.
>> 
>> What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).
>> 
>> So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
>> https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
>> And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.
>> 
>> So the fix is just as simple as not trying to find a failure for this phase.
>> 
>> I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.
>> 
>> ===
>> 
>> After review comment, let's change solution: the diagnostic is still valid, but instead, let's run macro expansion only when there are macro nodes. In our case, that means not to run it. The test needs no more fixing.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Run macro elimination only when there are macro nodes

Thanks @merykitty and @TobiHartmann!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1508#issuecomment-3073249955

From mchevalier at openjdk.org  Tue Jul 15 11:36:59 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 15 Jul 2025 11:36:59 GMT
Subject: [lworld] Integrated: 8361465: [lworld]
 testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails
In-Reply-To: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
References: <uE21fKE3O5F9Cq6xk6EY7lsRc2teTnonBGyA-6mePrw=.eb81a6f4-6375-4240-ba4a-7119e9b0851d@github.com>
Message-ID: <zVxugPi2YW5-S6h9DR8AdH61dgBTPd1FjJVxgikrU2Q=.0db10ecf-6de9-40d5-8572-c12505552cb5@github.com>

On Mon, 14 Jul 2025 11:55:06 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> The constraint `failOn = IRNode.STORE` on `NoCompilationOutput.badPhase2` in `test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java` does not fail for the phase `ITER_GVN_AFTER_ELIMINATION`:
> 
> AFTER: ITER_GVN_AFTER_ELIMINATION
>   0  Root  === 0 21  [[ 0 1 3 ]]
>   3  Start  === 3 0  [[ 3 5 6 7 8 9 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:ir_framework/tests/NoCompilationOutput:NotNull *}
>   5  Parm  === 3  [[ 21 ]] Control !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   6  Parm  === 3  [[ 21 ]] I_O !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   7  Parm  === 3  [[ 21 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   8  Parm  === 3  [[ 21 ]] FramePtr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>   9  Parm  === 3  [[ 21 ]] ReturnAdr !jvms: NoCompilationOutput::badPhase2 @ bci:-1 (line 353)
>  21  Return  === 5 6 7 8 9  [[ 0 ]]
> 
> which is not surprising given this method has an empty body.
> 
> What is surprising is that `ITER_GVN_AFTER_ELIMINATION` gives some output, which is what the test is about (cf. `@ExpectedFailure(ruleId = 1, hasCompilation = false,`).
> 
> So, if we just remove this phase in the test, we are good... as long as it's legitimate to do so. And I think it is: #1447 added some macro expansions (including an IGVN round with phase `PHASE_ITER_GVN_AFTER_ELIMINATION`) to `Compile::Optimize` just before the escape analysis, one of those being unconditional:
> https://github.com/openjdk/valhalla/blob/7e4c1bc1753bcd9655214eca32c391d28af43267/src/hotspot/share/opto/compile.cpp#L2858-L2867
> And this code being Valhalla-specific, that explains why our test is failing only on Valhalla.
> 
> So the fix is just as simple as not trying to find a failure for this phase.
> 
> I think it's very fine because this test is more about testing IR framework features than making sure this particular phase is missing on this method.
> 
> ===
> 
> After review comment, let's change solution: the diagnostic is still valid, but instead, let's run macro expansion only when there are macro nodes. In our case, that means not to run it. The test needs no more fixing.
> 
> Thanks,
> Marc

This pull request has now been integrated.

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

8361465: [lworld] testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java fails

Reviewed-by: qamai, thartmann

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

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

From liach at openjdk.org  Tue Jul 15 13:41:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Jul 2025 13:41:54 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v2]
In-Reply-To: <K_ifbEsUbW3ElFBF_Q1CgcabEZKegPgottA3h-MOP_Y=.08b4e964-8e52-4be9-9ba0-6fb2cd6f6ad0@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
 <K_ifbEsUbW3ElFBF_Q1CgcabEZKegPgottA3h-MOP_Y=.08b4e964-8e52-4be9-9ba0-6fb2cd6f6ad0@github.com>
Message-ID: <sPuDNY8Wf03BBlUqQQqL7Bi5388OrlbRy7NqiNTN2-U=.ffe3956f-408f-4639-aee4-4d206fe37987@github.com>

On Mon, 14 Jul 2025 17:42:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test both preview and non-preview for ValueClassTest
>
> src/java.base/share/classes/jdk/internal/value/ValueClass.java line 45:
> 
>> 43:     /// This excludes primitives and includes Object.
>> 44:     public static boolean isValueObjectCompatible(Class<?> fieldType) {
>> 45:         return PreviewFeatures.isEnabled() && !fieldType.isPrimitive() && (!fieldType.isIdentity() || fieldType == Object.class);
> 
> The `fieldType == Object.class` would always be true regardless of enable-preview.
> That does not seem to be accurate and might be mis-interpreted by a caller.

?? I enclosed that check in a pair of parentheses so its `||` is checked before any of the `&&`, don't think this returns `true` for `Object.class` without preview enabled.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2207509678

From rriggs at openjdk.org  Tue Jul 15 14:55:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Jul 2025 14:55:55 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v2]
In-Reply-To: <pbWFY20upUkEFjnJI0mp9j4F4nRjfXgIu61Kd0DMNiU=.d4a52427-ea14-4390-91d8-970387b0b0b6@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
 <K_ifbEsUbW3ElFBF_Q1CgcabEZKegPgottA3h-MOP_Y=.08b4e964-8e52-4be9-9ba0-6fb2cd6f6ad0@github.com>
 <pbWFY20upUkEFjnJI0mp9j4F4nRjfXgIu61Kd0DMNiU=.d4a52427-ea14-4390-91d8-970387b0b0b6@github.com>
Message-ID: <8fTnJERumMOf8KrZwRtu--bSqZi2awwh5t3P5nBpbbE=.9e13fc7f-7c91-419a-ad6b-04dbbfbb974f@github.com>

On Mon, 14 Jul 2025 21:15:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/jdk/valhalla/valuetypes/ValueClassTest.java line 60:
>> 
>>> 58:         assertFalse(isValueObjectCompatible(ArrayList[].class), "array class");
>>> 59:         assertFalse(isValueObjectCompatible(String[].class), "array class");
>>> 60:         assertFalse(isValueObjectCompatible(Comparable[].class), "array class");
>> 
>> If these ever fail, the error messages are not going to be very information  like`expected tru, actual = false Object`;
>> no mention of preview mode being tested or the method under test.
>
> Junit composes the exception message with the expected, actual values and the string provided, also there is the line number.

True, but seeing true and false by themselves doesn't communicate anything about the failure and you have to go look at the source and the line number and decode what assertEquals is comparing.
It may not be worth much effort but the message could be more informative.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2207738248

From vromero at openjdk.org  Tue Jul 15 15:15:20 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 15 Jul 2025 15:15:20 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v4]
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <cm5YdRBl0g-HYvT05EY-D5dFaRn640AtCPNRJKgooPE=.391259f3-2fac-4534-b15a-d47c04e85a69@github.com>

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

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

  updating golden file

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1490/files
  - new: https://git.openjdk.org/valhalla/pull/1490/files/9a172ea4..f3f2913a

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

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

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

From vromero at openjdk.org  Tue Jul 15 16:20:48 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 15 Jul 2025 16:20:48 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v5]
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <dAtXXydNpVjKiMnFnpMyzUr15BsfQQvL3s9r4hHbEZQ=.09977da5-b183-4346-a16d-30d2c5af1c6f@github.com>

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

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

  adding @enablePreview to some tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1490/files
  - new: https://git.openjdk.org/valhalla/pull/1490/files/f3f2913a..475dc710

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

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

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

From liach at openjdk.org  Tue Jul 15 22:21:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Jul 2025 22:21:55 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v2]
In-Reply-To: <sPuDNY8Wf03BBlUqQQqL7Bi5388OrlbRy7NqiNTN2-U=.ffe3956f-408f-4639-aee4-4d206fe37987@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
 <K_ifbEsUbW3ElFBF_Q1CgcabEZKegPgottA3h-MOP_Y=.08b4e964-8e52-4be9-9ba0-6fb2cd6f6ad0@github.com>
 <sPuDNY8Wf03BBlUqQQqL7Bi5388OrlbRy7NqiNTN2-U=.ffe3956f-408f-4639-aee4-4d206fe37987@github.com>
Message-ID: <tqSzCGKKvX9Wv3JWEBxP05t6E1o_8PiJ21QJF6iszbw=.0d758e3c-050d-4963-bb86-24a504077d06@github.com>

On Tue, 15 Jul 2025 13:39:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/value/ValueClass.java line 45:
>> 
>>> 43:     /// This excludes primitives and includes Object.
>>> 44:     public static boolean isValueObjectCompatible(Class<?> fieldType) {
>>> 45:         return PreviewFeatures.isEnabled() && !fieldType.isPrimitive() && (!fieldType.isIdentity() || fieldType == Object.class);
>> 
>> The `fieldType == Object.class` would always be true regardless of enable-preview.
>> That does not seem to be accurate and might be mis-interpreted by a caller.
>
> ?? I enclosed that check in a pair of parentheses so its `||` is checked before any of the `&&`, don't think this returns `true` for `Object.class` without preview enabled.

I will wrap the lines here so it's easier to see the logical precedence.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2208820332

From liach at openjdk.org  Tue Jul 15 22:32:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Jul 2025 22:32:03 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v2]
In-Reply-To: <8fTnJERumMOf8KrZwRtu--bSqZi2awwh5t3P5nBpbbE=.9e13fc7f-7c91-419a-ad6b-04dbbfbb974f@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <9DV07_zx1eSWmHXJiAFtFhjaLMCxhjhbViWxlO_RXJc=.ddecd5f5-a1a9-4951-91fa-9adf75e05660@github.com>
 <K_ifbEsUbW3ElFBF_Q1CgcabEZKegPgottA3h-MOP_Y=.08b4e964-8e52-4be9-9ba0-6fb2cd6f6ad0@github.com>
 <pbWFY20upUkEFjnJI0mp9j4F4nRjfXgIu61Kd0DMNiU=.d4a52427-ea14-4390-91d8-970387b0b0b6@github.com>
 <8fTnJERumMOf8KrZwRtu--bSqZi2awwh5t3P5nBpbbE=.9e13fc7f-7c91-419a-ad6b-04dbbfbb974f@github.com>
Message-ID: <OstI678708uXhdanV64beC_sZOnb783_gVsrPsZ5CSA=.75aa469c-c201-48d0-b457-1b619a9619cc@github.com>

On Tue, 15 Jul 2025 14:52:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Junit composes the exception message with the expected, actual values and the string provided, also there is the line number.
>
> True, but seeing true and false by themselves doesn't communicate anything about the failure and you have to go look at the source and the line number and decode what assertEquals is comparing.
> It may not be worth much effort but the message could be more informative.

I think the exception message is acceptable: I tweaked `isValueObjectCompatible` to erroneousely return `true` for `Integer[].class`, and this is the message:


STARTED    ValueClassTest::testIsValueObjectCompatible 'testIsValueObjectCompatible()'
org.opentest4j.AssertionFailedError: array class ==> expected: <false> but was: <true>
        at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
        at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
        at org.junit.jupiter.api.AssertFalse.failNotFalse(AssertFalse.java:63)
        at org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:36)
        at org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:239)
        at ValueClassTest.testIsValueObjectCompatible(ValueClassTest.java:56)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
FAILED     ValueClassTest::testIsValueObjectCompatible 'testIsValueObjectCompatible()' [16ms]

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1504#discussion_r2208832755

From liach at openjdk.org  Tue Jul 15 22:41:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Jul 2025 22:41:44 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v3]
In-Reply-To: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
Message-ID: <Sw7PMk-IFQbMJN00EiKoJ0BsthEqBrFrHJYzZf9929Y=.1e418aaf-867c-4181-8ba3-95546c7d7f2d@github.com>

> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
> 
> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
> 
> Testing: tier 1-3, seems to have no new failures

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Rename, facelift test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1504/files
  - new: https://git.openjdk.org/valhalla/pull/1504/files/425ad16d..e49d87d8

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

  Stats: 65 lines in 6 files changed: 15 ins; 4 del; 46 mod
  Patch: https://git.openjdk.org/valhalla/pull/1504.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1504/head:pull/1504

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

From rriggs at openjdk.org  Wed Jul 16 15:04:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Jul 2025 15:04:03 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v3]
In-Reply-To: <Sw7PMk-IFQbMJN00EiKoJ0BsthEqBrFrHJYzZf9929Y=.1e418aaf-867c-4181-8ba3-95546c7d7f2d@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <Sw7PMk-IFQbMJN00EiKoJ0BsthEqBrFrHJYzZf9929Y=.1e418aaf-867c-4181-8ba3-95546c7d7f2d@github.com>
Message-ID: <FpBsKEHnp2IZ_HrkyAGynThiCI8XNCOxwtTakTMiX4I=.a987f567-8f0f-4a01-8d2d-dc57c113af81@github.com>

On Tue, 15 Jul 2025 22:41:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
>> 
>> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
>> 
>> Testing: tier 1-3, seems to have no new failures
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename, facelift test

Looks good thanks for the readability improvements.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1504#pullrequestreview-3025459794

From vromero at openjdk.org  Wed Jul 16 16:51:14 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Jul 2025 16:51:14 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v6]
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <u12rds6893wriDvoI18Bsga8kCVQzpBi0EwKgDd6tgg=.401edb58-8612-4f2f-88d6-26b14fd627c6@github.com>

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

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/1490/files
  - new: https://git.openjdk.org/valhalla/pull/1490/files/475dc710..4f0959c9

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

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

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

From vromero at openjdk.org  Wed Jul 16 19:52:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Jul 2025 19:52:55 GMT
Subject: Integrated: Merge lworld
Message-ID: <bZuz-cWeyfxDwkUmL_Vn1VjVPEqpFVR9od3kTNKClw0=.905cea68-4594-4af6-b321-82d75b8dc456@github.com>

Merge branch 'lworld' into lw5_merge_lworld
# Conflicts:
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java

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

Commit messages:
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
 - Merge branch 'lworld' into lw5_merge_lworld
 - Merge lworld
 - 8347754: [lw5] fix the order of nullness markers in signatures
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - ... and 59 more: https://git.openjdk.org/valhalla/compare/293e16d2...94aa3dbe

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

Changes: https://git.openjdk.org/valhalla/pull/1510/files
  Stats: 6801 lines in 101 files changed: 6675 ins; 5 del; 121 mod
  Patch: https://git.openjdk.org/valhalla/pull/1510.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1510/head:pull/1510

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

From vromero at openjdk.org  Wed Jul 16 19:52:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Jul 2025 19:52:55 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <bZuz-cWeyfxDwkUmL_Vn1VjVPEqpFVR9od3kTNKClw0=.905cea68-4594-4af6-b321-82d75b8dc456@github.com>
References: <bZuz-cWeyfxDwkUmL_Vn1VjVPEqpFVR9od3kTNKClw0=.905cea68-4594-4af6-b321-82d75b8dc456@github.com>
Message-ID: <DLX8jBk54ztVgcF5JAmSI68FgaUIAqWgXdN3ut6TIgk=.28f87d65-a83d-4f45-9734-85f9a9b23fd6@github.com>

On Wed, 16 Jul 2025 17:55:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2556:

> 2554:                 boolean isConstructorPrev = isConstructor;
> 2555:                 boolean isCompactOrGeneratedRecordConstructorPrev = isCompactOrGeneratedRecordConstructor;
> 2556: 		JCMethodDecl currentMethodPrev = currentMethod;

Suggestion:

                JCMethodDecl currentMethodPrev = currentMethod;

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2632:

> 2630:                     isConstructor = isConstructorPrev;
> 2631:                     isCompactOrGeneratedRecordConstructor = isCompactOrGeneratedRecordConstructorPrev;
> 2632: 		    currentMethod = currentMethodPrev;

Suggestion:

                    currentMethod = currentMethodPrev;

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1510#discussion_r2211395568
PR Review Comment: https://git.openjdk.org/valhalla/pull/1510#discussion_r2211402082

From vromero at openjdk.org  Wed Jul 16 19:52:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Jul 2025 19:52:56 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <bZuz-cWeyfxDwkUmL_Vn1VjVPEqpFVR9od3kTNKClw0=.905cea68-4594-4af6-b321-82d75b8dc456@github.com>
References: <bZuz-cWeyfxDwkUmL_Vn1VjVPEqpFVR9od3kTNKClw0=.905cea68-4594-4af6-b321-82d75b8dc456@github.com>
Message-ID: <9WU5JAe6LoQ00eqwlGcPLSPoAXDJWd0sqWi7WLiyIl4=.033e3d3a-7e0e-49c3-8e35-c329b73ac916@github.com>

On Wed, 16 Jul 2025 17:55:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java

This pull request has now been integrated.

Changeset: a4d73ce4
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a4d73ce43c7331ce104c80df74925b9f40f4538f
Stats:     6427 lines in 123 files changed: 4588 ins; 936 del; 903 mod

Merge lworld

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

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

From mchevalier at openjdk.org  Thu Jul 17 12:15:48 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 17 Jul 2025 12:15:48 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order
Message-ID: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>

It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.

But maybe, a bit of archeology:
- Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.

- Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
static int sort_field_by_offset(ciField** a, ciField** b)` and
  ```cpp
  // Now sort them by offset, 
  // (In principle, they could mix with superclass fields.)
  fields->sort(sort_field_by_offset);
  ```
  from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.

- Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstanceKlass::compute_nonstatic_fields` has to agree with deoptimization code. In Valhalla, the calling convention has to agree with the layout wrt field ordering. Basically, it makes a big chain of things that needs to agree on the order of fields.

- Valhalla: [JDK-8354366: [lworld] VirtualObjectDebugInfoTest fails after merging jdk-25+16](https://bugs.openjdk.org/browse/JDK-8354366) partially reverts [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892) by reintroducing sorting. This allowed to un-ProblemList `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java`, but made `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java` fail because now, and that's where I start.

Overall, it's a clash in the order of fields. First question is naturally: does the order really has to agree, or do we put some interfaces, pipes and curtains to adapt between potentially different order? I think we should keep a consistent order, as much as possible. It makes everything simpler, possibly more efficient as we don't have to search if we want to work on two lists... Efforts were made in mainline to keep the order consistent, let's not break that.

Second question is which order. Here, same, I'll invoke mainline that decided to go with stream order. It has also the benefit not to require sorting: get the field stream, ready to use. Lighter, easier, more efficient...

Let's define more precisely the order in which the fields should show up. Given a class `Derived`, that extends the class `Base`.
1. superclass first: for any transitive field `b` of `Base`, and any proper field `d` of `Derived`, `b` should appear before `d`,
2. consistent ordering: the list of (transitive) fields of `Base` must be a subsequence of the list of (transitive) fields of `Derived`. In other words, the order of the fields of `Base` in the list of fields of `Base` is the same as the order of the fields of `Base` in the list of fields of `Derived`.
3. proper field ordering: the proper fields of `Derived`, must appear in the order provided by `JavaFieldStream` (which happens to be the declaration order, but is not guaranteed).

This is enough to define the list of declared fields. It implies in particular that the fields of the super class form a prefix of the whole list of declared fields. It makes possible to isolate the proper fields by removing this prefix (and it's done somewhere). It also is cheap to compute as we can just push fields in the order the stream gives, starting with a recursive call to traverse the supertype's fields.

If we are interested in the list of actual fields, as present in the layout, we simply insert the fields of each flatten field instead of them. The null marker of each field, if it exists, appears immediately after.

Which changes need to be made? Mostly removing sorting
- remove sorting in `ciInstanceKlass::compute_nonstatic_fields_impl`.
- remove member variable `float _sort_offset` from `SigEntry` but add `bool _null_marker` for printing in `nmethod::print_nmethod_labels`.
- remove sorting from `InlineKlass::collect_fields`, but also, change the iterator: use the new `TopDownHierarchicalFieldStreamBase` that will travese the super classes first.
- remove sorting from `get_reassigned_fields`, seems to be a merge accident? The code around comes from [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) without the sort, but [#1429](https://github.com/openjdk/valhalla/pull/1429) introduced sorting.
- revert [JDK-8354366: [lworld] VirtualObjectDebugInfoTest fails after merging jdk-25+16](https://bugs.openjdk.org/browse/JDK-8354366), bringing back the changes of [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892).

Bonus:
- Added a printer for `VirtualObjectDebugInfoTest$TestClass` because the test failure message being "this `TestClass` is not equal to this other `TestClass`" is not so helpful.
- Added a flag to print fields collected in `InlineKlass::initialize_calling_convention`. It seems it was deemed useful but missing, and not only by me right now! The flag is called `PrintInlineKlassFields` and takes a comma-separated list of class name patterns to print. Feel free to suggest a better name.
- I've tried to print fields in `ciInstanceKlass::compute_nonstatic_fields` to compare. It works, but this function is called way too many times for each class (not sure why, didn't look into that), so not great to leave a flag for that.

Wow, what a wall of text. But for once, it comes with non-trivial changes.

Thanks,
Marc

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

Commit messages:
 - Merge remote-tracking branch 'origin/lworld' into fix/field-ordering
 - cleanup
 - UnProblemList
 - For testing

Changes: https://git.openjdk.org/valhalla/pull/1511/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1511&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357785
  Stats: 239 lines in 13 files changed: 138 ins; 60 del; 41 mod
  Patch: https://git.openjdk.org/valhalla/pull/1511.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1511/head:pull/1511

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

From vromero at openjdk.org  Thu Jul 17 14:44:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Jul 2025 14:44:04 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v7]
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <t94LxB3lz6Vv4OM43bVhr22tRW_DV49SZIo2Gdq0LlY=.8c6671c9-55f7-4768-b470-f2c0739117f7@github.com>

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

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

  fixing bugs related to local classes, removing coupling in Flow

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1490/files
  - new: https://git.openjdk.org/valhalla/pull/1490/files/4f0959c9..1531d1b0

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

  Stats: 53 lines in 6 files changed: 33 ins; 14 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1490.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1490/head:pull/1490

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

From vromero at openjdk.org  Thu Jul 17 15:20:43 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Jul 2025 15:20:43 GMT
Subject: [lworld] RFR: 8359370: [lworld] allow instance fields of identity
 classes to be readable in the prologue phase [v8]
In-Reply-To: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
References: <InBaZ9ZKs3ffx8D_oSwob5yD1wHwiO2a_YcJHgtEds4=.075ee3ba-1d6f-4c05-8f78-8e47a6e0579a@github.com>
Message-ID: <RALMQVc01Kqy9vJVky-RHMrU1C1v7lJ48i8A5cNVefk=.1474be39-2409-455c-a6d8-247131d878db@github.com>

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

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

  removing unused field in Flow

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1490/files
  - new: https://git.openjdk.org/valhalla/pull/1490/files/1531d1b0..8323d159

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

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

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

From rriggs at openjdk.org  Fri Jul 18 19:14:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Jul 2025 19:14:51 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v3]
In-Reply-To: <Sw7PMk-IFQbMJN00EiKoJ0BsthEqBrFrHJYzZf9929Y=.1e418aaf-867c-4181-8ba3-95546c7d7f2d@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <Sw7PMk-IFQbMJN00EiKoJ0BsthEqBrFrHJYzZf9929Y=.1e418aaf-867c-4181-8ba3-95546c7d7f2d@github.com>
Message-ID: <tuKhrK7GWT0FdEa-jQ4Th9oo4nIHy-LKirvQtYFRVf0=.a6d161e7-fd0d-4330-b2a2-f2e13aabfdf8@github.com>

On Tue, 15 Jul 2025 22:41:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
>> 
>> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
>> 
>> Testing: tier 1-3, seems to have no new failures
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename, facelift test

Looks good; integrate?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1504#issuecomment-3090458296

From liach at openjdk.org  Fri Jul 18 20:42:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Jul 2025 20:42:14 GMT
Subject: [lworld] RFR: 8361496: [lworld] Treating interfaces as isValue()
 leads to failed assert [v3]
In-Reply-To: <Sw7PMk-IFQbMJN00EiKoJ0BsthEqBrFrHJYzZf9929Y=.1e418aaf-867c-4181-8ba3-95546c7d7f2d@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
 <Sw7PMk-IFQbMJN00EiKoJ0BsthEqBrFrHJYzZf9929Y=.1e418aaf-867c-4181-8ba3-95546c7d7f2d@github.com>
Message-ID: <C2FjZl80JUKcILlrMDW0ACoAHQ2b3B3lMeebYj62T0Q=.a4533236-d4e9-4b3c-9ea0-c29a6cefec6e@github.com>

On Tue, 15 Jul 2025 22:41:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
>> 
>> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
>> 
>> Testing: tier 1-3, seems to have no new failures
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename, facelift test

Thanks for the reminder and the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1504#issuecomment-3090654512

From liach at openjdk.org  Fri Jul 18 20:42:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Jul 2025 20:42:15 GMT
Subject: [lworld] Integrated: 8361496: [lworld] Treating interfaces as
 isValue() leads to failed assert
In-Reply-To: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
References: <FJXkeP1IOlk3BpP7XwCes25i0ndRB630TkoFGuJeyJg=.f9966877-b311-43c6-84aa-52b5b7c418a3@github.com>
Message-ID: <AN21A5bXDpHT8N35yWBXytcBnXQreUJOkF2QbZS5mVY=.4c45aa60-1537-4130-9e0b-b0cb18892658@github.com>

On Mon, 7 Jul 2025 22:44:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> Reviewed a few sites of isValue() usages that cause immediate trouble with bootstrap and basic tests. Factor out `ValueClass::isValueObjectCompatible` and `isValueObjectInstance` to represent the two states of value classes: field types that can hold value objects, and field types that definitely hold value objects.
> 
> I think we still need a more throughout review for all `isValue` usages, such as those in MethodHandle or VarHandle. Preliminary testing hasn't revealed anything yet.
> 
> Testing: tier 1-3, seems to have no new failures

This pull request has now been integrated.

Changeset: 64fe6c1e
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/64fe6c1eaadc28ab344771d4492304a71e6d7e86
Stats:     147 lines in 7 files changed: 116 ins; 13 del; 18 mod

8361496: [lworld] Treating interfaces as isValue() leads to failed assert

Reviewed-by: rriggs

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

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

From qamai at openjdk.org  Sun Jul 20 07:50:57 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 20 Jul 2025 07:50:57 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order
In-Reply-To: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
Message-ID: <LrHiTIbtboQ65uu_UxDZZhoWpSE2RL4fNI32DU9Hgis=.da80f36c-14b8-495b-ba92-5f9fb67854e9@github.com>

On Thu, 17 Jul 2025 12:07:56 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
> 
> But maybe, a bit of archeology:
> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
> 
> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
> static int sort_field_by_offset(ciField** a, ciField** b)` and
>   ```cpp
>   // Now sort them by offset, 
>   // (In principle, they could mix with superclass fields.)
>   fields->sort(sort_field_by_offset);
>   ```
>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
> 
> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstance...

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

> 472: }
> 473: 
> 474: static int sort_field_by_offset(ciField** a, ciField** b) {

Could you add a comment at `ciInstanceKlass._declared_nonstatic_fields` and `_nonstatic_fields` to specify exactly the order of the fields there? It is a little bit hard to grasp at the first sight, especially with flattened fields.

src/hotspot/share/oops/fieldStreams.hpp line 196:

> 194: };
> 195: 
> 196: template<typename FieldStreamType>

It would be good to say what this class does and what the template parameter is for.

src/hotspot/share/oops/fieldStreams.hpp line 325:

> 323:  * Doesn't traverse interfaces for now (let's decide how when/if the needs appear).
> 324:  */
> 325: template<typename FieldStreamType>

By "doesn't traverse interfaces for now" I assume this traverses both static and non-static fields. Tbh I think traversing static fields seems questionable, or maybe I miss some cases, maybe this stream can discard those, too?

src/hotspot/share/oops/inlineKlass.cpp line 436:

> 434:   }
> 435:   SigEntry::add_entry(sig, T_VOID, name(), offset);
> 436:   if (base_off == 0) {

Nice, I have a pending issue of making this sort less a minefield but removing it completely is absolutely better. The comment of this function says it sorts the flattened fields in the increasing offset order, please change it, too.

src/hotspot/share/runtime/signature.hpp line 591:

> 589:     : _bt(bt), _offset(offset), _symbol(symbol), _null_marker(null_marker) {}
> 590: 
> 591: #if 0

Why do you wrap it with `#if 0` instead of removing this function?

test/hotspot/jtreg/ProblemList.txt line 135:

> 133: runtime/valhalla/inlinetypes/verifier/StrictInstanceFieldsTest.java CODETOOLS-7904031 generic-all
> 134: runtime/valhalla/inlinetypes/verifier/StrictStaticFieldsTest.java CODETOOLS-7904031 generic-all
> 135: runtime/cds/appcds/RewriteBytecodesInlineTest.java 8361082 generic-all

This issue is fixed with #1498 , so this seems like a merge conflict, right?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2217682443
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2217682958
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2217683719
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2217684836
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2217685460
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2217686046

From qamai at openjdk.org  Sun Jul 20 13:27:00 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 20 Jul 2025 13:27:00 GMT
Subject: [lworld] RFR: 8349110: [lworld] Intrinsics for
 Unsafe.get/putFlatValue [v5]
In-Reply-To: <7fCHBFnGicE_vQdt8tLxvTQ5ShjPURocDRUMoQ_yx68=.3f013756-798c-413f-92d2-29b75d5c9206@github.com>
References: <7fCHBFnGicE_vQdt8tLxvTQ5ShjPURocDRUMoQ_yx68=.3f013756-798c-413f-92d2-29b75d5c9206@github.com>
Message-ID: <KEpGTWoe01vLx7iyjMLSiwX-3mZY15jIRdEsc4VmiEA=.f0934bdc-c5cf-4669-8d02-de6753360fef@github.com>

> Hi,
> 
> This PR implements intrinsics for `Unsafe::get/putFlatValue` and enables the corresponding tests in `TestIntrinsics`.
> 
> Please kindly review, thanks very much.

Quan Anh Mai 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 six additional commits since the last revision:

 - exclude test84
 - Merge branch 'lworld' into unsafeflatvalue
 - remove -DeoptimizeALot
 - Revisit TODOs in TestIntrinsics
 - Buffer an InlineTypeNode on mismatched access
 - Implement Unsafe::flatValue accesses

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1482/files
  - new: https://git.openjdk.org/valhalla/pull/1482/files/74378233..3327b8a2

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

  Stats: 1743 lines in 82 files changed: 1540 ins; 18 del; 185 mod
  Patch: https://git.openjdk.org/valhalla/pull/1482.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1482/head:pull/1482

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

From qamai at openjdk.org  Sun Jul 20 13:27:00 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 20 Jul 2025 13:27:00 GMT
Subject: [lworld] RFR: 8349110: [lworld] Intrinsics for
 Unsafe.get/putFlatValue [v4]
In-Reply-To: <Q-z4lRj0745r679e216L2ak7K33tFZ4IKFoTsw8vDCc=.931151b9-8d19-4054-87b8-20c00197fae2@github.com>
References: <7fCHBFnGicE_vQdt8tLxvTQ5ShjPURocDRUMoQ_yx68=.3f013756-798c-413f-92d2-29b75d5c9206@github.com>
 <-CLEMgcWQqt-XDleIcSVmlguUqQwI7iZo8ztxRC6JZE=.e1bbd9be-01b6-43e0-a5e6-f4d21324412f@github.com>
 <Q-z4lRj0745r679e216L2ak7K33tFZ4IKFoTsw8vDCc=.931151b9-8d19-4054-87b8-20c00197fae2@github.com>
Message-ID: <8kIpgu2k2yMM6b05_wLFkD5QZJj0s4HVkwVU1U-A1YQ=.cf14c958-bce1-446d-ab39-08e060acdba5@github.com>

On Tue, 17 Jun 2025 06:00:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove -DeoptimizeALot
>
> Testing looks good now except for one last failure with `compiler/valhalla/inlinetypes/TestIntrinsics.java` and `-XX:Tier0BackedgeNotifyFreqLog=0 -XX:Tier2BackedgeNotifyFreqLog=0 -XX:Tier3BackedgeNotifyFreqLog=0 -XX:Tier2BackEdgeThreshold=1 -XX:Tier3BackEdgeThreshold=1 -XX:Tier4BackEdgeThreshold=1 -Xbatch`:
> 
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/opt/mach5/mesos/work_dir/slaves/d2398cde-9325-49c3-b030-8961a4f0a253-S509733/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d98a4bd7-58a9-4f29-b8d0-431bc28dcc7e/runs/a5899c58-42e7-464d-909b-9619da50104d/workspace/open/src/hotspot/share/prims/unsafe.cpp:256), pid=2121432, tid=2121433
> #  assert(_obj == nullptr || !_obj->is_inline_type() || _obj->mark().is_larval_state()) failed: must be an object instance or a larval inline type
> #
> # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-06-16-1439046.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-06-16-1439046.tobias.hartmann.valhalla2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x1bbe2be]  Unsafe_PutInt+0x28e
> 
> Stack: [0x00007ff7140b4000,0x00007ff7141b5000],  sp=0x00007ff7141b33b0,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1bbe2be]  Unsafe_PutInt+0x28e  (unsafe.cpp:256)
> J 3090  jdk.internal.misc.Unsafe.putInt(Ljava/lang/Object;JI)V java.base at 25-lworld5ea (0 bytes) @ 0x00007ff6fc8582c4 [0x00007ff6fc858220+0x00000000000000a4]
> j  compiler.valhalla.inlinetypes.TestIntrinsics.test84(Lcompiler/valhalla/inlinetypes/MyValue1;)Lcompiler/valhalla/inlinetypes/MyValue1;+46
> j  compiler.valhalla.inlinetypes.TestIntrinsics.test84_verifier()V+16
> J 3280 c2 java.lang.invoke.LambdaForm$DMH+0x000000002e091000.invokeVirtual(Ljava/lang/Object;Ljava/lang/Object;)V java.base at 25-lworld5ea (14 bytes) @ 0x00007ff6fc883fe0 [0x00007ff6fc883fa0+0x0000000000000040]
> j  java.lang.invoke.LambdaForm$MH+0x000000002e105800.invoke(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+35 java.base at 25-lworld5ea
> J 3271 c2 jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base at 25-lworld5ea (92 bytes) @ 0x00007ff6fc881c80 [0x00007ff6fc881ba0+0x00000000000000e0]
> j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Objec...

@TobiHartmann The crash is due to [JDK-8322547](https://bugs.openjdk.org/browse/JDK-8322547). I have excluded the test.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1482#issuecomment-3094516957

From mchevalier at openjdk.org  Mon Jul 21 05:54:04 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 21 Jul 2025 05:54:04 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order
In-Reply-To: <LrHiTIbtboQ65uu_UxDZZhoWpSE2RL4fNI32DU9Hgis=.da80f36c-14b8-495b-ba92-5f9fb67854e9@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <LrHiTIbtboQ65uu_UxDZZhoWpSE2RL4fNI32DU9Hgis=.da80f36c-14b8-495b-ba92-5f9fb67854e9@github.com>
Message-ID: <g8K3EuOiRFQwu2KTzhEHaP1z4Rf35x3-EcDe8w9qfg4=.c116f934-8c6a-47b4-8931-2e1b55251041@github.com>

On Sun, 20 Jul 2025 07:45:44 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
>> 
>> But maybe, a bit of archeology:
>> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
>> 
>> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
>> static int sort_field_by_offset(ciField** a, ciField** b)` and
>>   ```cpp
>>   // Now sort them by offset, 
>>   // (In principle, they could mix with superclass fields.)
>>   fields->sort(sort_field_by_offset);
>>   ```
>>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
>> 
>> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that ...
>
> src/hotspot/share/runtime/signature.hpp line 591:
> 
>> 589:     : _bt(bt), _offset(offset), _symbol(symbol), _null_marker(null_marker) {}
>> 590: 
>> 591: #if 0
> 
> Why do you wrap it with `#if 0` instead of removing this function?

It's a leftover that survived the clean up, it should have been removed. I was trying to remove some sorting by removing the order function, and see if it's used somewhere legitimate, but this way it was still easily accessible. Anyway, it should have been, and will be, removed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2218253200

From mchevalier at openjdk.org  Mon Jul 21 07:45:53 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 21 Jul 2025 07:45:53 GMT
Subject: [lworld] RFR: 8354404: [lworld] compiler/startup/StartupOutput.java
 crashes during AdapterHandlerLibrary::initialize() due to too little
 CodeCacheSize
Message-ID: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>

Experimentally, replacing 800 with 2000 is needed to have this test pass on all platform. Somehow, while 1300 seems ok on my Linux (while having a fair share of "CodeCache is full. Compiler has been disabled." messages), Windows boxes seems to struggle even with 1800. Not sure why: isn't the size of the things in the code cache (that is, the code), depends mostly on the encoding of instructions, that is dependent on architecture, not OS? Anyway, it happens reliably, so something had to be done!

Let's compare (with debug builds so I can use `CodeCacheMinimumUseSpace`, that is 1200k by default on debug builds), for various values of `ReservedCodeCacheSize` (in k), when running `-version`. For mainline:
- [4, 28]
  ```
  # There is insufficient memory for the Java Runtime Environment to continue.
  # Native memory allocation (malloc) failed to allocate 3000 bytes. Error detail: `CodeCache: no room for StubRoutines` (continuation stubs)
  ```
  coming from
  - `report_should_not_call(char const*, int)`
  - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
  - `StubRoutines::initialize_continuation_stubs()`
  - `continuation_stubs_init()`
  - `init_globals()`
  
  with `3000` being `20000` for `ReservedCodeCacheSize` between 5 and 24, and being `500` for `ReservedCodeCacheSize` = 4 (the minimum).

- [29, 32] `fatal error: Initial size of CodeCache is too small`
  https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
  coming from
  - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
  - `SharedRuntime::generate_jfr_return_lease()`
  - `SharedRuntime::generate_jfr_stubs()`
  - `init_globals()`

- [33, 1112]
  ```
  # There is insufficient memory for the Java Runtime Environment to continue.
  # Native memory allocation (malloc) failed to allocate 1108928 bytes. Error detail: CodeCache: no room for Interpreter
  ```
  - `...`
  - `report_should_not_call(char const*, int)`
  - `StubQueue::StubQueue(StubInterface*, int, Mutex*, char const*)`
  - `TemplateInterpreter::initialize_stub()`
  - `interpreter_init_stub()`
  - `init_globals()`

- [1113, 1116] SIGSEGV
  - `CodeSection::emit_int8(unsigned char)`
  - `AbstractAssembler::emit_int8(int)`
  - `Assembler::push(Register)`
  - `MacroAssembler::enter()`
  - `RegisterSaver::save_live_registers(MacroAssembler*, int, int*, bool)`
  - `SharedRuntime::generate_resolve_blob(StubId, unsigned char*)`
  - `SharedRuntime::generate_stubs()`
  - `init_globals()`

- [1117, 1128] `fatal error: Initial size of CodeCache is too small`
  https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L596
  coming from
  - `SingletonBlob::operator new(unsigned long, unsigned int, bool)`
  - `DeoptimizationBlob::create(CodeBuffer*, OopMapSet*, int, int, int, int)`
  - `SharedRuntime::generate_deopt_blob()`
  - `SharedRuntime::generate_stubs()`
  - `init_globals()`
- [1129, 1144] `assert(_buffer != nullptr) failed: should be initialized`
  https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/runtime/sharedRuntime.cpp#L2526 
  coming from
  - `AdapterHandlerLibrary::generate_adapter_code(AdapterBlob*&, AdapterHandlerEntry*, int, BasicType*, bool)` 
  - `AdapterHandlerLibrary::create_adapter(AdapterBlob*&, int, BasicType*, bool)`
  - `AdapterHandlerLibrary::initialize()`
  - `SharedRuntime::init_adapter_library()`
  - `init_globals()`
- [1145, 1148] `assert(no_arg_blob != nullptr && obj_arg_blob != nullptr && int_arg_blob != nullptr && obj_int_arg_blob != nullptr && obj_obj_arg_blob != nullptr) failed: Initial adapters must be properly created`
  https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/runtime/sharedRuntime.cpp#L2605-L2609
  coming from 
  - `AdapterHandlerLibrary::initialize()`
  - `SharedRuntime::init_adapter_library()`
  - `init_globals()`

  (just after the previous)
- [1149, ~1700]
  ```
  Java HotSpot(TM) 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers
  Java HotSpot(TM) 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers
  ```
  and eventually works, but occasionally crashes with
  ```
  # There is insufficient memory for the Java Runtime Environment to continue.
  # Native memory allocation (malloc) failed to allocate 109000 bytes. Error detail: CodeCache: no room for StubRoutines (compiler stubs)
  ```
  from
  - `report_should_not_call(char const*, int)`
  - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
  - `StubRoutines::initialize_compiler_stubs()`
  - `compiler_stubs_init(bool)`
  - `C2Compiler::init_c2_runtime()`
  - `C2Compiler::initialize()`

  especially around 1180k, still happening at 1200k, which is the default minimum.
- Then a various number of `C1 initialization failed` (and sometimes `C2 initialization failed`) but it overall works.

And now, for Valhalla:
- [4, 20] finding the first behavior `CodeCache: no room for StubRoutines`
- [21, 24] a new kind of SIGSEGV!
  - `CodeSection::emit_int8(unsigned char)`
  - `AbstractAssembler::emit_int8(int)`
  - `Assembler::prefix(Assembler::Prefix)`
  - `Assembler::prefixq_and_encode(int, bool)`
  - `Assembler::subq(Register, int)`
  - `MacroAssembler::subptr(Register, int)`
  - `StubGenerator::generate_return_value_stub(unsigned char*, char const*, bool)`
  - `StubGenerator::generate_initial_stubs()`
  - `StubGenerator::StubGenerator(CodeBuffer*, StubGenBlobId)`
  - `StubGenerator_generate(CodeBuffer*, StubGenBlobId)`
  - `initialize_stubs(StubGenBlobId, int, int, char const*, char const*, char const*)`
  - `StubRoutines::initialize_initial_stubs()`
  - `initial_stubs_init()`
  - `init_globals()`
- [25, 28] first behavior again `CodeCache: no room for StubRoutines`
- [29, 32] `fatal error: Initial size of CodeCache is too small`
  https://github.com/openjdk/valhalla/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
  like the [29, 32] range of mainline
- [33, 1164] `Native memory allocation (malloc) failed to allocate 1158080 bytes. Error detail: CodeCache: no room for Interpreter` like the [33, 1112] range of mainline
- [1165, 1172] `fatal error: Initial size of CodeCache is too small`
  https://github.com/openjdk/valhalla/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
  - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
  - `SharedRuntime::generate_resolve_blob(SharedStubId, unsigned char*)`
  - `SharedRuntime::generate_stubs()`
  - `init_globals()`
- [1173, 1220] SIGSEGV
  - `CodeBlob::name() const`
  - `CodeBuffer::CodeBuffer(CodeBlob*)`
  - `AdapterHandlerLibrary::create_adapter(AdapterBlob*&, CompiledEntrySignature&, bool)`
  - `AdapterHandlerLibrary::initialize()`
  - `SharedRuntime::generate_stubs()`
  - `init_globals()`
  
  actually analogous to the range [1129, 1144] (`assert(_buffer != nullptr) failed: should be initialized`) of mainline. But Valhalla is missing this assert yet, the `_buffer` is `nullptr`, and `CodeBlob::name() const` is called on this null pointer that is provided to the ctor of `CodeBuffer`
- [1221, 1224] `assert(no_arg_blob != nullptr && obj_arg_blob != nullptr && int_arg_blob != nullptr && obj_int_arg_blob != nullptr && obj_obj_arg_blob != nullptr) failed: Initial adapters must be properly created`
  https://github.com/openjdk/valhalla/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/runtime/sharedRuntime.cpp#L2605-L2609
  same as the range [1145, 1148] of mainline
- [1225, 1228] SIGSEGV
  - `CodeSection::emit_int8(unsigned char)`
  - `AbstractAssembler::emit_int8(int)`
  - `Assembler::push(Register)`
  - `SharedRuntime::generate_handler_blob(SharedStubId, unsigned char*)`
  - `SharedRuntime::generate_stubs()`
  - `init_globals()`
- [1229, 1232] `fatal error: Initial size of CodeCache is too small`
  https://github.com/openjdk/valhalla/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L596
  same as the [1117, 1128] range of mainline
- [1233, 1236]
  ```
  Java HotSpot(TM) 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers
  Java HotSpot(TM) 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers
  Error occurred during initialization of boot layer
  java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToSpecial(Object,Object,Object,MemberName)Object/invokeStatic
  Suppressed: java.lang.BootstrapMethodError: bootstrap method initialization exception
  Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToSpecial(Object,Object,Object,MemberName)Object/invokeStatic
  ```
  exit code = 1
- [1237, 1300]
  ```
  Java HotSpot(TM) 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers
  Java HotSpot(TM) 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers
  Error occurred during initialization of boot layer
  java.lang.OutOfMemoryError: Out of space in CodeCache for adapters
  Suppressed: java.lang.OutOfMemoryError: Out of space in CodeCache for method handle intrinsic
  ```
  exit code = 1
- [1301, 1304]
  ```
  Java HotSpot(TM) 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers
  Java HotSpot(TM) 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers
  Error occurred during initialization of boot layer
  java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToSpecial(Object,MemberName)void/invokeStatic
  Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToSpecial(Object,MemberName)void/invokeStatic
  ```
  exit code = 1
- [1305, 1308]
  ```
  Java HotSpot(TM) 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers
  Java HotSpot(TM) 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers
  Error occurred during initialization of boot layer
  java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToSpecial(Object,MemberName)int/invokeStatic
  Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToSpecial(Object,MemberName)int/invokeStatic
  ```
  exit code = 1
- [1309, 1792]
  ```
  Java HotSpot(TM) 64-Bit Server VM warning: C1 initialization failed. Shutting down all compilers
  Java HotSpot(TM) 64-Bit Server VM warning: C2 initialization failed. Shutting down all compilers
  ```
  and eventually works
- [1793, 1993]
  ```
  Error occurred during initialization of boot layer
  java.lang.OutOfMemoryError: Out of space in CodeCache for adapters
  ```
  exit code = 1
  with possibly additional lines among:
  ```
  Suppressed: java.lang.OutOfMemoryError: Out of space in CodeCache for adapters
  Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToSpecial(Object,Object,MemberName)void/invokeStatic
  
  ```
  (yes, an empty line)
- [1994, ...] mostly works, but sometimes the same error as above, witnessed until 3780k (and especially between 3640 and 3780). Interestingly, at 3700k, we also see some fine runs, with, or without compiler shutdown. Starting 3800k, I never saw a failure, and starting 3900k, no compiler shutdown.

So, how to pick `CodeCacheMinimumUseSpace`, that is the smaller value of `ReservedCodeCacheSize` we allow? On mainline with the default value (1200k on debug, 400k on product), we don't see any crash anymore. On Valhalla, at 2000k, it works always as far as I can see, but around 3700, it crashes in most cases (maybe two thirds or three quarters of the runs). If we are aiming for a value that would guarantee no crashes, we should pick at least 3800k, that is quite a huge increase. If we consider the weird crashes around 3700k as acceptable (and maybe fixable), 2000k is probably fine. Since that's the debug value, that is three times scaled up from the product one

https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeCache.cpp#L208

that would mean taking `CodeCacheMinimumUseSpace` as 1267k (in the first case, maybe rounded to 1300k), or 667k (in the second case, maybe rounded to 700k).

That's for the minimum. As for the defaults: they still somewhat makes sense, in the meaning that we can run quite some things without filling the code cache. It's not clear to me what expectations we have and how we can decide.

I didn't change those as part of this PR, as the JBS issue is not primarily about that, and it looks like a more... subtle problem. But I can if a consensus emerges. Let the discussion begin!

Thanks,
Marc, the text wall builder (textmason?)

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

Commit messages:
 - trying a bit more...
 - Raise limit in StartupOutput.java

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

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

From thartmann at openjdk.org  Mon Jul 21 07:50:17 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 21 Jul 2025 07:50:17 GMT
Subject: [lworld] RFR: 8349110: [lworld] Intrinsics for
 Unsafe.get/putFlatValue [v5]
In-Reply-To: <KEpGTWoe01vLx7iyjMLSiwX-3mZY15jIRdEsc4VmiEA=.f0934bdc-c5cf-4669-8d02-de6753360fef@github.com>
References: <7fCHBFnGicE_vQdt8tLxvTQ5ShjPURocDRUMoQ_yx68=.3f013756-798c-413f-92d2-29b75d5c9206@github.com>
 <KEpGTWoe01vLx7iyjMLSiwX-3mZY15jIRdEsc4VmiEA=.f0934bdc-c5cf-4669-8d02-de6753360fef@github.com>
Message-ID: <EQeehoOaoHMqMVcJo9_397wGqhi85UKxPHAHkMR5a7s=.198ba604-f8c8-491f-a6a8-fc5cac98d902@github.com>

On Sun, 20 Jul 2025 13:27:00 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR implements intrinsics for `Unsafe::get/putFlatValue` and enables the corresponding tests in `TestIntrinsics`.
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai 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 six additional commits since the last revision:
> 
>  - exclude test84
>  - Merge branch 'lworld' into unsafeflatvalue
>  - remove -DeoptimizeALot
>  - Revisit TODOs in TestIntrinsics
>  - Buffer an InlineTypeNode on mismatched access
>  - Implement Unsafe::flatValue accesses

Ah, right. Let's convert this one to a bug then. Your changes look good to me. Thanks again!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1482#pullrequestreview-3036929958

From rriggs at openjdk.org  Mon Jul 21 18:09:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 21 Jul 2025 18:09:26 GMT
Subject: [lworld] RFR: 8361307: [lworld] Clarify identity vs value in Class,
 Objects, and document limitations of value objects
Message-ID: <fIE_gRwECFlFD-Be5vvy9lhbCVB7kId1K2c5dzL3J2M=.4e9f23a0-2203-45b0-b58c-816627343df3@github.com>

Javadoc updates to clarify value class vs identity class distinctions when in preview-mode and not.

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

Commit messages:
 - 8361307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects

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

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

From mchevalier at openjdk.org  Tue Jul 22 07:49:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 22 Jul 2025 07:49:32 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v2]
In-Reply-To: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
Message-ID: <pYPSjW74z_quJ0tI4z25I_pgZ4Z_o8_8CFQhISR7VUY=.95a1c79b-692e-4d66-86c2-8ba107b7d743@github.com>

> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
> 
> But maybe, a bit of archeology:
> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
> 
> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
> static int sort_field_by_offset(ciField** a, ciField** b)` and
>   ```cpp
>   // Now sort them by offset, 
>   // (In principle, they could mix with superclass fields.)
>   fields->sort(sort_field_by_offset);
>   ```
>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
> 
> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstance...

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

  Address Quan Anh's comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1511/files
  - new: https://git.openjdk.org/valhalla/pull/1511/files/23969db2..76a7ee4d

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

  Stats: 81 lines in 5 files changed: 33 ins; 32 del; 16 mod
  Patch: https://git.openjdk.org/valhalla/pull/1511.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1511/head:pull/1511

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

From mchevalier at openjdk.org  Tue Jul 22 07:49:33 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 22 Jul 2025 07:49:33 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v2]
In-Reply-To: <LrHiTIbtboQ65uu_UxDZZhoWpSE2RL4fNI32DU9Hgis=.da80f36c-14b8-495b-ba92-5f9fb67854e9@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <LrHiTIbtboQ65uu_UxDZZhoWpSE2RL4fNI32DU9Hgis=.da80f36c-14b8-495b-ba92-5f9fb67854e9@github.com>
Message-ID: <eL0vecBzKiFTPtGSmUoNiQAl3wznjBV2yZItMKMidLI=.88237604-754a-41c7-b267-9376ec629732@github.com>

On Sun, 20 Jul 2025 07:40:44 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Quan Anh's comments
>
> src/hotspot/share/oops/fieldStreams.hpp line 325:
> 
>> 323:  * Doesn't traverse interfaces for now (let's decide how when/if the needs appear).
>> 324:  */
>> 325: template<typename FieldStreamType>
> 
> By "doesn't traverse interfaces for now" I assume this traverses both static and non-static fields. Tbh I think traversing static fields seems questionable, or maybe I miss some cases, maybe this stream can discard those, too?

I guess if we are not going through the interfaces, indeed, it wouldn't be reasonable to traverse half the static fields.

> test/hotspot/jtreg/ProblemList.txt line 135:
> 
>> 133: runtime/valhalla/inlinetypes/verifier/StrictInstanceFieldsTest.java CODETOOLS-7904031 generic-all
>> 134: runtime/valhalla/inlinetypes/verifier/StrictStaticFieldsTest.java CODETOOLS-7904031 generic-all
>> 135: runtime/cds/appcds/RewriteBytecodesInlineTest.java 8361082 generic-all
> 
> This issue is fixed with #1498 , so this seems like a merge conflict, right?

Exactly.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2221542613
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2221543892

From mchevalier at openjdk.org  Tue Jul 22 07:51:47 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 22 Jul 2025 07:51:47 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order
In-Reply-To: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
Message-ID: <cEP0X2fa85j0vNMpIAhpIIP9mddecg8ABiq0ze4xcFk=.7963af1f-80d5-464f-b5d7-059a555c351d@github.com>

On Thu, 17 Jul 2025 12:07:56 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
> 
> But maybe, a bit of archeology:
> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
> 
> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
> static int sort_field_by_offset(ciField** a, ciField** b)` and
>   ```cpp
>   // Now sort them by offset, 
>   // (In principle, they could mix with superclass fields.)
>   fields->sort(sort_field_by_offset);
>   ```
>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
> 
> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstance...

Thanks for looking at it. I think I've addressed the comments. It looks better already: I missed a lot of cleanup (leaving outdated comments and `#if 0` behind, especially), because I was very unsure of what I was doing until it worked.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1511#issuecomment-3101493131

From qamai at openjdk.org  Tue Jul 22 13:51:42 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 22 Jul 2025 13:51:42 GMT
Subject: [lworld] RFR: 8349110: [lworld] Intrinsics for
 Unsafe.get/putFlatValue [v4]
In-Reply-To: <Q-z4lRj0745r679e216L2ak7K33tFZ4IKFoTsw8vDCc=.931151b9-8d19-4054-87b8-20c00197fae2@github.com>
References: <7fCHBFnGicE_vQdt8tLxvTQ5ShjPURocDRUMoQ_yx68=.3f013756-798c-413f-92d2-29b75d5c9206@github.com>
 <-CLEMgcWQqt-XDleIcSVmlguUqQwI7iZo8ztxRC6JZE=.e1bbd9be-01b6-43e0-a5e6-f4d21324412f@github.com>
 <Q-z4lRj0745r679e216L2ak7K33tFZ4IKFoTsw8vDCc=.931151b9-8d19-4054-87b8-20c00197fae2@github.com>
Message-ID: <qai1yBdZ5_T92s_bsEDnIswJ8_xCPmV7NPWN0GRu1hU=.9dec86bf-41f9-4006-86b0-7a910e6be864@github.com>

On Tue, 17 Jun 2025 06:00:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove -DeoptimizeALot
>
> Testing looks good now except for one last failure with `compiler/valhalla/inlinetypes/TestIntrinsics.java` and `-XX:Tier0BackedgeNotifyFreqLog=0 -XX:Tier2BackedgeNotifyFreqLog=0 -XX:Tier3BackedgeNotifyFreqLog=0 -XX:Tier2BackEdgeThreshold=1 -XX:Tier3BackEdgeThreshold=1 -XX:Tier4BackEdgeThreshold=1 -Xbatch`:
> 
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/opt/mach5/mesos/work_dir/slaves/d2398cde-9325-49c3-b030-8961a4f0a253-S509733/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d98a4bd7-58a9-4f29-b8d0-431bc28dcc7e/runs/a5899c58-42e7-464d-909b-9619da50104d/workspace/open/src/hotspot/share/prims/unsafe.cpp:256), pid=2121432, tid=2121433
> #  assert(_obj == nullptr || !_obj->is_inline_type() || _obj->mark().is_larval_state()) failed: must be an object instance or a larval inline type
> #
> # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-lworld5ea-LTS-2025-06-16-1439046.tobias.hartmann.valhalla2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-lworld5ea-LTS-2025-06-16-1439046.tobias.hartmann.valhalla2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x1bbe2be]  Unsafe_PutInt+0x28e
> 
> Stack: [0x00007ff7140b4000,0x00007ff7141b5000],  sp=0x00007ff7141b33b0,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1bbe2be]  Unsafe_PutInt+0x28e  (unsafe.cpp:256)
> J 3090  jdk.internal.misc.Unsafe.putInt(Ljava/lang/Object;JI)V java.base at 25-lworld5ea (0 bytes) @ 0x00007ff6fc8582c4 [0x00007ff6fc858220+0x00000000000000a4]
> j  compiler.valhalla.inlinetypes.TestIntrinsics.test84(Lcompiler/valhalla/inlinetypes/MyValue1;)Lcompiler/valhalla/inlinetypes/MyValue1;+46
> j  compiler.valhalla.inlinetypes.TestIntrinsics.test84_verifier()V+16
> J 3280 c2 java.lang.invoke.LambdaForm$DMH+0x000000002e091000.invokeVirtual(Ljava/lang/Object;Ljava/lang/Object;)V java.base at 25-lworld5ea (14 bytes) @ 0x00007ff6fc883fe0 [0x00007ff6fc883fa0+0x0000000000000040]
> j  java.lang.invoke.LambdaForm$MH+0x000000002e105800.invoke(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+35 java.base at 25-lworld5ea
> J 3271 c2 jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base at 25-lworld5ea (92 bytes) @ 0x00007ff6fc881c80 [0x00007ff6fc881ba0+0x00000000000000e0]
> j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Objec...

@TobiHartmann Thanks a lot for your reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1482#issuecomment-3102821111

From qamai at openjdk.org  Tue Jul 22 13:51:43 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 22 Jul 2025 13:51:43 GMT
Subject: [lworld] Integrated: 8349110: [lworld] Intrinsics for
 Unsafe.get/putFlatValue
In-Reply-To: <7fCHBFnGicE_vQdt8tLxvTQ5ShjPURocDRUMoQ_yx68=.3f013756-798c-413f-92d2-29b75d5c9206@github.com>
References: <7fCHBFnGicE_vQdt8tLxvTQ5ShjPURocDRUMoQ_yx68=.3f013756-798c-413f-92d2-29b75d5c9206@github.com>
Message-ID: <udnuaxxEppHiv6pfLbCBp1bXrDgPUK_f04dhk7eXTiQ=.dacdf980-d3ef-4a77-ba85-41255721ef2a@github.com>

On Fri, 6 Jun 2025 11:46:23 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This PR implements intrinsics for `Unsafe::get/putFlatValue` and enables the corresponding tests in `TestIntrinsics`.
> 
> Please kindly review, thanks very much.

This pull request has now been integrated.

Changeset: d1c30621
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d1c306214ea16513e04cf72bc4810a7ab6006e17
Stats:     223 lines in 7 files changed: 183 ins; 34 del; 6 mod

8349110: [lworld] Intrinsics for Unsafe.get/putFlatValue

Reviewed-by: thartmann

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

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

From mchevalier at openjdk.org  Tue Jul 22 14:17:46 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 22 Jul 2025 14:17:46 GMT
Subject: [lworld] RFR: 8354404: [lworld]
 compiler/startup/StartupOutput.java crashes during
 AdapterHandlerLibrary::initialize() due to too little CodeCacheSize
In-Reply-To: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
References: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
Message-ID: <lPBpnOh4JvrtnJ3UkP6Ii-smyh9AXv8iBPVgHWeGM3I=.a56dcfcd-68b4-4a89-8a03-b272b4f82f2d@github.com>

On Wed, 16 Jul 2025 14:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Experimentally, replacing 800 with 2000 is needed to have this test pass on all platform. Somehow, while 1300 seems ok on my Linux (while having a fair share of "CodeCache is full. Compiler has been disabled." messages), Windows boxes seems to struggle even with 1800. Not sure why: isn't the size of the things in the code cache (that is, the code), depends mostly on the encoding of instructions, that is dependent on architecture, not OS? Anyway, it happens reliably, so something had to be done!
> 
> Let's compare (with debug builds so I can use `CodeCacheMinimumUseSpace`, that is 1200k by default on debug builds), for various values of `ReservedCodeCacheSize` (in k), when running `-version`. For mainline:
> - [4, 28]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 3000 bytes. Error detail: `CodeCache: no room for StubRoutines` (continuation stubs)
>   ```
>   coming from
>   - `report_should_not_call(char const*, int)`
>   - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
>   - `StubRoutines::initialize_continuation_stubs()`
>   - `continuation_stubs_init()`
>   - `init_globals()`
>   
>   with `3000` being `20000` for `ReservedCodeCacheSize` between 5 and 24, and being `500` for `ReservedCodeCacheSize` = 4 (the minimum).
> 
> - [29, 32] `fatal error: Initial size of CodeCache is too small`
>   https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
>   coming from
>   - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
>   - `SharedRuntime::generate_jfr_return_lease()`
>   - `SharedRuntime::generate_jfr_stubs()`
>   - `init_globals()`
> 
> - [33, 1112]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 1108928 bytes. Error detail: CodeCache: no room for Interpreter
>   ```
>   - `...`
>   - `report_should_not_call(char const*, int)`
>   - `StubQueue::StubQueue(StubInterface*, int, Mutex*, char const*)`
>   - `TemplateInterpreter::initialize_stub()`
>   - `interpreter_init_stub()`
>   - `init_globals()`
> 
> - [1113, 1116] SIGSEGV
>   - `CodeSection::emit_int8(unsigned char)`
>   - `AbstractAssembler::emit_int8(int)`
>   - `Assembler::push(Register)`
>   - `MacroAssembler::enter()`
>   - `RegisterSaver::save_live_registers(MacroAssembler*, int, int*, bool)`
>   - `SharedRuntime::generate_resolve_blob(StubId, unsigne...

@TobiHartmann was wondering why it was so different, so I've dug in it.

There are a lot more adapters in Valhalla than in mainline right now (700 vs 300), which causes a multiple hundred kilo additional usage (between 1 and 2 per adapter). It seems that adapters for a same signature are not cached (at least in debug). But this part of the code is widely different between Valhalla and mainline, and that's because [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209) changed a lot of things there recently, and hasn't yet been merge in Valhalla it seems.

I've compared with mainline before this change, and it behaves similarly as Valhalla: a lot more adapters (very close in cardinal and set as Valhalla), same kind of weird crashes for lack of adapter space even for relatively high memory settings. Valhalla still seems to need a bit more memory, but it also needs more adapters, quite some being related to flat values in `jdk.internal.misc.Unsafe`. Nothing crazy. I think the next main -> valhalla main will change the profile of `java -version` wrt. code cache limit quite radically.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1509#issuecomment-3102941360

From coleenp at openjdk.org  Tue Jul 22 17:47:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 22 Jul 2025 17:47:31 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native
Message-ID: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>

This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
Added a test.
Tested with tier1 locally.

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

Commit messages:
 - 8363846: [lworld] Make Class.isIdentityClass() non-native

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

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

From rriggs at openjdk.org  Tue Jul 22 21:48:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 21:48:02 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <-Il4w5gwN_DWqiEoDZqZVnRCi4i80rsvrcTXNKeSEFs=.3315f3e5-1598-4ad6-a5cf-564c155c7385@github.com>

On Tue, 22 Jul 2025 17:41:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

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

> 632:         } else {
> 633:             return !isInterface();
> 634:         }

Isn't this going to take a performance hit?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2223890013

From rriggs at openjdk.org  Tue Jul 22 21:51:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 21:51:12 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <2k-Q-_WVJCWB4sjtTvK4ArhOLsqggB8ZnQK6wns6FCA=.d9b49966-46c4-4539-a555-7d0bfa7eab11@github.com>

On Tue, 22 Jul 2025 17:41:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 28:

> 26:  * @summary Test that IsIdentityClass and modifiers return true for flattened arrays.
> 27:  * @library /test/lib
> 28:  * @enablePreview

Since isIdentity depends on enable-preview, it should be run twice, once with and once without.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2223894810

From liach at openjdk.org  Tue Jul 22 23:47:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Jul 2025 23:47:07 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <BarVFI9alQnuNCUf__YYwL7wgh0RkWUOOAA3KpredW4=.9c9a6707-122d-4767-b41f-1d6518d70362@github.com>

On Tue, 22 Jul 2025 17:41:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

is_identity_class seems widely used in many areas, such as C2 - do we need to verify those usages?

src/hotspot/share/oops/instanceKlass.cpp line 3594:

> 3592: }
> 3593: 
> 3594: void InstanceKlass::check_can_be_annotated_with_NullRestricted(InstanceKlass* type, Symbol* container_klass_name, TRAPS) {

I am surprised we still have this remnant of implicit construction now we have strict fields - shouldn't we replace this with strictness checks?

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

PR Review: https://git.openjdk.org/valhalla/pull/1514#pullrequestreview-3045150746
PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2224022195

From liach at openjdk.org  Tue Jul 22 23:47:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Jul 2025 23:47:08 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native
In-Reply-To: <-Il4w5gwN_DWqiEoDZqZVnRCi4i80rsvrcTXNKeSEFs=.3315f3e5-1598-4ad6-a5cf-564c155c7385@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <-Il4w5gwN_DWqiEoDZqZVnRCi4i80rsvrcTXNKeSEFs=.3315f3e5-1598-4ad6-a5cf-564c155c7385@github.com>
Message-ID: <L0zks1P0jc20lUjE5TE2zfTvsWbH57LM4o_lPA6gFb4=.9b97711c-ce4c-440f-8c75-100bcd5d294c@github.com>

On Tue, 22 Jul 2025 21:45:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> src/java.base/share/classes/java/lang/Class.java line 634:
> 
>> 632:         } else {
>> 633:             return !isInterface();
>> 634:         }
> 
> Isn't this going to take a performance hit?

Where is the hit at?

Moving this method to Java should be friendly to both interpreter (no more jni context switch) and C2 (no more opacity). We can further simplify these to be  modifier checks later on.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2224018170

From coleenp at openjdk.org  Wed Jul 23 11:44:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 11:44:10 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native
In-Reply-To: <L0zks1P0jc20lUjE5TE2zfTvsWbH57LM4o_lPA6gFb4=.9b97711c-ce4c-440f-8c75-100bcd5d294c@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <-Il4w5gwN_DWqiEoDZqZVnRCi4i80rsvrcTXNKeSEFs=.3315f3e5-1598-4ad6-a5cf-564c155c7385@github.com>
 <L0zks1P0jc20lUjE5TE2zfTvsWbH57LM4o_lPA6gFb4=.9b97711c-ce4c-440f-8c75-100bcd5d294c@github.com>
Message-ID: <plscEU4t2PaGUoaXSDupycY5Z4TQqfBGwhdr1dhoErg=.c4e6573f-7b0d-4722-b4cf-9c07548c3947@github.com>

On Tue, 22 Jul 2025 23:39:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 634:
>> 
>>> 632:         } else {
>>> 633:             return !isInterface();
>>> 634:         }
>> 
>> Isn't this going to take a performance hit?
>
> Where is the hit at?
> 
> Moving this method to Java should be friendly to both interpreter (no more jni context switch) and C2 (no more opacity). We can further simplify these to be  modifier checks later on.

Yes this is better performance because C2 now doesn't have to intrinsify this native call.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225287655

From coleenp at openjdk.org  Wed Jul 23 11:48:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 11:48:02 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native
In-Reply-To: <BarVFI9alQnuNCUf__YYwL7wgh0RkWUOOAA3KpredW4=.9c9a6707-122d-4767-b41f-1d6518d70362@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <BarVFI9alQnuNCUf__YYwL7wgh0RkWUOOAA3KpredW4=.9c9a6707-122d-4767-b41f-1d6518d70362@github.com>
Message-ID: <u_nCVxnC8ZXEGm5X21S_-wBdzb9MxZBF5X580dYo1rE=.209875aa-b653-44bf-b6b0-b629ccf4e4df@github.com>

On Tue, 22 Jul 2025 23:43:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> src/hotspot/share/oops/instanceKlass.cpp line 3594:
> 
>> 3592: }
>> 3593: 
>> 3594: void InstanceKlass::check_can_be_annotated_with_NullRestricted(InstanceKlass* type, Symbol* container_klass_name, TRAPS) {
> 
> I am surprised we still have this remnant of implicit construction now we have strict fields - shouldn't we replace this with strictness checks?

This was part of another change, and we still need this to check if a field can be made an inline type.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225301191

From coleenp at openjdk.org  Wed Jul 23 11:59:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 11:59:49 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <uduj1cn1Xkk98xl0S8ghapK-DOq2_NOFJirPvEzxHIA=.799f650c-21a2-4a10-bb4e-40f8314b9929@github.com>

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

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

  Add a test for not enable preview.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1514/files
  - new: https://git.openjdk.org/valhalla/pull/1514/files/324e2c51..96dd8079

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

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

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

From forax at openjdk.org  Wed Jul 23 12:10:15 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 23 Jul 2025 12:10:15 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <u_nCVxnC8ZXEGm5X21S_-wBdzb9MxZBF5X580dYo1rE=.209875aa-b653-44bf-b6b0-b629ccf4e4df@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <BarVFI9alQnuNCUf__YYwL7wgh0RkWUOOAA3KpredW4=.9c9a6707-122d-4767-b41f-1d6518d70362@github.com>
 <u_nCVxnC8ZXEGm5X21S_-wBdzb9MxZBF5X580dYo1rE=.209875aa-b653-44bf-b6b0-b629ccf4e4df@github.com>
Message-ID: <3CqfsryHVDYH9iJo-4NdYYmJGYI8TqlA-ibTXATioEo=.5de2250c-0b19-4041-afbf-f45033e9ea69@github.com>

On Wed, 23 Jul 2025 11:45:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 3594:
>> 
>>> 3592: }
>>> 3593: 
>>> 3594: void InstanceKlass::check_can_be_annotated_with_NullRestricted(InstanceKlass* type, Symbol* container_klass_name, TRAPS) {
>> 
>> I am surprised we still have this remnant of implicit construction now we have strict fields - shouldn't we replace this with strictness checks?
>
> This was part of another change, and we still need this to check if a field can be made an inline type.

And a strict field can be null

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225360563

From coleenp at openjdk.org  Wed Jul 23 12:10:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 12:10:15 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <2k-Q-_WVJCWB4sjtTvK4ArhOLsqggB8ZnQK6wns6FCA=.d9b49966-46c4-4539-a555-7d0bfa7eab11@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <2k-Q-_WVJCWB4sjtTvK4ArhOLsqggB8ZnQK6wns6FCA=.d9b49966-46c4-4539-a555-7d0bfa7eab11@github.com>
Message-ID: <dDZ_kHrtJdxIqm8oI7Z08Vqe8YmL4lk1KaR9-ueYp3U=.4ee9d93c-ea4f-4a17-9c38-745e8c23e2ea@github.com>

On Tue, 22 Jul 2025 21:48:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a test for not enable preview.
>
> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 28:
> 
>> 26:  * @summary Test that IsIdentityClass and modifiers return true for flattened arrays.
>> 27:  * @library /test/lib
>> 28:  * @enablePreview
> 
> Since isIdentity depends on enable-preview, it should be run twice, once with and once without.

Added.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225360467

From coleenp at openjdk.org  Wed Jul 23 12:15:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 12:15:06 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <BarVFI9alQnuNCUf__YYwL7wgh0RkWUOOAA3KpredW4=.9c9a6707-122d-4767-b41f-1d6518d70362@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <BarVFI9alQnuNCUf__YYwL7wgh0RkWUOOAA3KpredW4=.9c9a6707-122d-4767-b41f-1d6518d70362@github.com>
Message-ID: <wkAgKfxpH-Ngjn0_lh3KL-j4WnhD-QzlLuFiaY8bJZw=.36032966-d96a-441e-919c-29636e0c47e1@github.com>

On Tue, 22 Jul 2025 23:44:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> is_identity_class seems widely used in many areas, such as C2 - do we need to verify those usages?

Good question.  I did check most/attempted all of these places and added the assert in klass.hpp but since AccessFlags are in klass, it is possible to copy them from an ArrayKlass to a ciKlass and fail the is_identity check for an array.  The only way to make this completely safe is to move the access flags, which I started in another repo but it's got pretty hairy since Klass and InstanceKlass are used interchangeably in some of the compiler code that I don't know very well, when I think they really mean InstanceKlass.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1514#issuecomment-3107679225

From rriggs at openjdk.org  Wed Jul 23 13:44:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 13:44:06 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <plscEU4t2PaGUoaXSDupycY5Z4TQqfBGwhdr1dhoErg=.c4e6573f-7b0d-4722-b4cf-9c07548c3947@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <-Il4w5gwN_DWqiEoDZqZVnRCi4i80rsvrcTXNKeSEFs=.3315f3e5-1598-4ad6-a5cf-564c155c7385@github.com>
 <L0zks1P0jc20lUjE5TE2zfTvsWbH57LM4o_lPA6gFb4=.9b97711c-ce4c-440f-8c75-100bcd5d294c@github.com>
 <plscEU4t2PaGUoaXSDupycY5Z4TQqfBGwhdr1dhoErg=.c4e6573f-7b0d-4722-b4cf-9c07548c3947@github.com>
Message-ID: <KmqdkAv0UUl2pGmwF6ychl8cJolEyNhhARk_jvRh_Lo=.d0f6ec7f-91d1-408e-9510-e5390ed7ee8b@github.com>

On Wed, 23 Jul 2025 11:41:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Where is the hit at?
>> 
>> Moving this method to Java should be friendly to both interpreter (no more jni context switch) and C2 (no more opacity). We can further simplify these to be  modifier checks later on.
>
> Yes this is better performance because C2 now doesn't have to intrinsify this native call.

I'd go ahead and create the isIdentity field and move this code to the constructor.
The modifiers, component type and primitive flag are all available at once.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225659984

From rriggs at openjdk.org  Wed Jul 23 14:15:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 14:15:06 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <uduj1cn1Xkk98xl0S8ghapK-DOq2_NOFJirPvEzxHIA=.799f650c-21a2-4a10-bb4e-40f8314b9929@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <uduj1cn1Xkk98xl0S8ghapK-DOq2_NOFJirPvEzxHIA=.799f650c-21a2-4a10-bb4e-40f8314b9929@github.com>
Message-ID: <2Ut051uweRFKBLN0R81ydCCcmN1HQJSP0FEneVH6ctI=.f08b7018-d126-4b93-bfca-36895fdd044d@github.com>

On Wed, 23 Jul 2025 11:59:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test for not enable preview.

For new tests we use junit. 
See other tests like UseValueClassTest for imports and per test annotations.

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 68:

> 66:             assertFalse(ValueClass.isFlatArray(array0));
> 67:         }
> 68:         assertFalse(Integer.class.isIdentity(), "Integer is not an IDENTITY type");

This test should be sensitive to whether enable-preview is true.
It should have failed in the second run. 
But due to the TEST.properties (enablePreview = true) it overrides the command line in the test.
Removing enablePreview in TEST.properties is the right fix for that but then another test needs a fix.
The RecursiveValueClass test will need to have @enablePreview added to each of its test runs.

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

PR Review: https://git.openjdk.org/valhalla/pull/1514#pullrequestreview-3047648355
PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225740147

From rriggs at openjdk.org  Wed Jul 23 14:18:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 14:18:06 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <2Ut051uweRFKBLN0R81ydCCcmN1HQJSP0FEneVH6ctI=.f08b7018-d126-4b93-bfca-36895fdd044d@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <uduj1cn1Xkk98xl0S8ghapK-DOq2_NOFJirPvEzxHIA=.799f650c-21a2-4a10-bb4e-40f8314b9929@github.com>
 <2Ut051uweRFKBLN0R81ydCCcmN1HQJSP0FEneVH6ctI=.f08b7018-d126-4b93-bfca-36895fdd044d@github.com>
Message-ID: <8gucu2YWXFC9phe7GgrU1aVgykEKvFupH9mtt2mG0BU=.0001cea2-3ad6-4fc6-92fe-3d51948848fa@github.com>

On Wed, 23 Jul 2025 14:10:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a test for not enable preview.
>
> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 68:
> 
>> 66:             assertFalse(ValueClass.isFlatArray(array0));
>> 67:         }
>> 68:         assertFalse(Integer.class.isIdentity(), "Integer is not an IDENTITY type");
> 
> This test should be sensitive to whether enable-preview is true.
> It should have failed in the second run. 
> But due to the TEST.properties (enablePreview = true) it overrides the command line in the test.
> Removing enablePreview in TEST.properties is the right fix for that but then another test needs a fix.
> The RecursiveValueClass test will need to have @enablePreview added to each of its test runs.

I'll fixup TEST.properties and the other test in a separate PR.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225754960

From coleenp at openjdk.org  Wed Jul 23 15:09:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 15:09:11 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <8gucu2YWXFC9phe7GgrU1aVgykEKvFupH9mtt2mG0BU=.0001cea2-3ad6-4fc6-92fe-3d51948848fa@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <uduj1cn1Xkk98xl0S8ghapK-DOq2_NOFJirPvEzxHIA=.799f650c-21a2-4a10-bb4e-40f8314b9929@github.com>
 <2Ut051uweRFKBLN0R81ydCCcmN1HQJSP0FEneVH6ctI=.f08b7018-d126-4b93-bfca-36895fdd044d@github.com>
 <8gucu2YWXFC9phe7GgrU1aVgykEKvFupH9mtt2mG0BU=.0001cea2-3ad6-4fc6-92fe-3d51948848fa@github.com>
Message-ID: <wNKcrsi2feAnXW5o-2r2-Uv4CGeFpoqH0EzgHdFPNWo=.56162ca9-1986-4e38-a8c8-a8c3fcbc4773@github.com>

On Wed, 23 Jul 2025 14:15:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 68:
>> 
>>> 66:             assertFalse(ValueClass.isFlatArray(array0));
>>> 67:         }
>>> 68:         assertFalse(Integer.class.isIdentity(), "Integer is not an IDENTITY type");
>> 
>> This test should be sensitive to whether enable-preview is true.
>> It should have failed in the second run. 
>> But due to the TEST.properties (enablePreview = true) it overrides the command line in the test.
>> Removing enablePreview in TEST.properties is the right fix for that but then another test needs a fix.
>> The RecursiveValueClass test will need to have @enablePreview added to each of its test runs.
>
> I'll fixup TEST.properties and the other test in a separate PR.

yes, that's surprising it passed.  Oh, I don't know how these work.  None of the other tests check for !enablePreview in this directory.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225897395

From liach at openjdk.org  Wed Jul 23 15:19:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Jul 2025 15:19:17 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <wNKcrsi2feAnXW5o-2r2-Uv4CGeFpoqH0EzgHdFPNWo=.56162ca9-1986-4e38-a8c8-a8c3fcbc4773@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <uduj1cn1Xkk98xl0S8ghapK-DOq2_NOFJirPvEzxHIA=.799f650c-21a2-4a10-bb4e-40f8314b9929@github.com>
 <2Ut051uweRFKBLN0R81ydCCcmN1HQJSP0FEneVH6ctI=.f08b7018-d126-4b93-bfca-36895fdd044d@github.com>
 <8gucu2YWXFC9phe7GgrU1aVgykEKvFupH9mtt2mG0BU=.0001cea2-3ad6-4fc6-92fe-3d51948848fa@github.com>
 <wNKcrsi2feAnXW5o-2r2-Uv4CGeFpoqH0EzgHdFPNWo=.56162ca9-1986-4e38-a8c8-a8c3fcbc4773@github.com>
Message-ID: <RlWd8hwaOcwVV35NY9a9RZazT9LpcyXiP2eYAscUzv8=.5b2bc86d-ee96-4189-a500-2dd0767bad82@github.com>

On Wed, 23 Jul 2025 15:06:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I'll fixup TEST.properties and the other test in a separate PR.
>
> yes, that's surprising it passed.  Oh, I don't know how these work.  None of the other tests check for !enablePreview in this directory.

We should be able to use `@enablePreview false` to explicitly turn it off, without touching `TEST.properties`:
https://github.com/openjdk/jtreg/blob/8a906f35aeacc79cc723ed4dd73aa2bb6c7dd8e9/src/share/classes/com/sun/javatest/regtest/config/RegressionTestFinder.java#L644-L650

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2225923179

From rriggs at openjdk.org  Wed Jul 23 15:30:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 15:30:39 GMT
Subject: [lworld] RFR: 8363956: [lworld] Valhalla vauetypes tests enablePreview
 should be per test
Message-ID: <ErMsl5UUY8Pyln8XBQf-zi_7yi-3lG-mkOWiR92VXKk=.4d4d1911-a2f5-4a59-a7c6-c90b72662eec@github.com>

The enable for preview should be per test, not per test directory.

Remove enablePreview = true from valhalla/valuetypes/TEST.properties and add to tests as needed

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

Commit messages:
 - 8363956: [lworld] Valhalla vauetypes tests enablePreview should be per test

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

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

From coleenp at openjdk.org  Wed Jul 23 15:54:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 15:54:54 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v3]
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <PS3zal9ubJmUOl2UWMtgEiV2jgizMRBgQY8dG1ycbRU=.b9d2f5c6-cf9e-4f36-ada6-82190d4e085c@github.com>

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

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

  Fix test to use junit and test without preview mode.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1514/files
  - new: https://git.openjdk.org/valhalla/pull/1514/files/96dd8079..f26fea89

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

  Stats: 38 lines in 1 file changed: 13 ins; 13 del; 12 mod
  Patch: https://git.openjdk.org/valhalla/pull/1514.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1514/head:pull/1514

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

From rriggs at openjdk.org  Wed Jul 23 15:57:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 15:57:04 GMT
Subject: [lworld] Integrated: 8363956: [lworld] Valhalla vauetypes tests
 enablePreview should be per test
In-Reply-To: <ErMsl5UUY8Pyln8XBQf-zi_7yi-3lG-mkOWiR92VXKk=.4d4d1911-a2f5-4a59-a7c6-c90b72662eec@github.com>
References: <ErMsl5UUY8Pyln8XBQf-zi_7yi-3lG-mkOWiR92VXKk=.4d4d1911-a2f5-4a59-a7c6-c90b72662eec@github.com>
Message-ID: <p-csw5Oy65iHujRnnJGmZ0fqPzOL-3jd337ddrUHYjg=.5bb91d5c-bf08-47bb-991b-7b9b301f6ea9@github.com>

On Wed, 23 Jul 2025 15:25:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The enable for preview should be per test, not per test directory.
> 
> Remove enablePreview = true from valhalla/valuetypes/TEST.properties and add to tests as needed

This pull request has now been integrated.

Changeset: 1fdd3816
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1fdd3816e4d720a6f26b917a5ce069b9146adc35
Stats:     4 lines in 2 files changed: 3 ins; 1 del; 0 mod

8363956: [lworld] Valhalla vauetypes tests enablePreview should be per test

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

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

From rriggs at openjdk.org  Wed Jul 23 16:02:17 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 16:02:17 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v2]
In-Reply-To: <RlWd8hwaOcwVV35NY9a9RZazT9LpcyXiP2eYAscUzv8=.5b2bc86d-ee96-4189-a500-2dd0767bad82@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <uduj1cn1Xkk98xl0S8ghapK-DOq2_NOFJirPvEzxHIA=.799f650c-21a2-4a10-bb4e-40f8314b9929@github.com>
 <2Ut051uweRFKBLN0R81ydCCcmN1HQJSP0FEneVH6ctI=.f08b7018-d126-4b93-bfca-36895fdd044d@github.com>
 <8gucu2YWXFC9phe7GgrU1aVgykEKvFupH9mtt2mG0BU=.0001cea2-3ad6-4fc6-92fe-3d51948848fa@github.com>
 <wNKcrsi2feAnXW5o-2r2-Uv4CGeFpoqH0EzgHdFPNWo=.56162ca9-1986-4e38-a8c8-a8c3fcbc4773@github.com>
 <RlWd8hwaOcwVV35NY9a9RZazT9LpcyXiP2eYAscUzv8=.5b2bc86d-ee96-4189-a500-2dd0767bad82@github.com>
Message-ID: <zujDMk9gO0cYTwI2GowWgRkGq8CrYctrWbRvfnsx2Qg=.5cc7446a-224d-4b7e-a0a7-2bc370041ea4@github.com>

On Wed, 23 Jul 2025 15:16:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> yes, that's surprising it passed.  Oh, I don't know how these work.  None of the other tests check for !enablePreview in this directory.
>
> We should be able to use `@enablePreview false` to explicitly turn it off, without touching `TEST.properties`:
> https://github.com/openjdk/jtreg/blob/8a906f35aeacc79cc723ed4dd73aa2bb6c7dd8e9/src/share/classes/com/sun/javatest/regtest/config/RegressionTestFinder.java#L644-L650

I'd prefer it to be explicit in each test, no need to chase down modes in config files.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226045125

From liach at openjdk.org  Wed Jul 23 16:09:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Jul 2025 16:09:16 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v3]
In-Reply-To: <PS3zal9ubJmUOl2UWMtgEiV2jgizMRBgQY8dG1ycbRU=.b9d2f5c6-cf9e-4f36-ada6-82190d4e085c@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <PS3zal9ubJmUOl2UWMtgEiV2jgizMRBgQY8dG1ycbRU=.b9d2f5c6-cf9e-4f36-ada6-82190d4e085c@github.com>
Message-ID: <LZCUA6R5xvDc3FQiSeyBhe96FgI9DfvQ5-BvbfLfQYI=.eee68a1c-5505-4d6a-ad5f-79901b196667@github.com>

On Wed, 23 Jul 2025 15:54:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test to use junit and test without preview mode.

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 52:

> 50: 
> 51:     private static void assertFalseIfPreview(boolean condition, String msg) {
> 52:         if (PreviewFeatures.isEnabled()) {

We can use `assertEquals(!PreviewFeatures.isEnabled(), msg)`

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 63:

> 61:         RuntimeMXBean runtimeMxBean = ManagementFactory.getRuntimeMXBean();
> 62:         List<String> arguments = runtimeMxBean.getInputArguments();
> 63:         boolean UseArrayFlattening = !arguments.contains("-XX:-UseArrayFlattening");

Optional comments:

I wonder if it's more usually to obtain flags with serviceability, or explicitly pass -D properties...

Also for these global states, it's better to capture them with a `@Setup static void setup()` method and store in static fields, especially if multiple tests use these states.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226056359
PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226054918

From rriggs at openjdk.org  Wed Jul 23 16:12:08 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 16:12:08 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v3]
In-Reply-To: <PS3zal9ubJmUOl2UWMtgEiV2jgizMRBgQY8dG1ycbRU=.b9d2f5c6-cf9e-4f36-ada6-82190d4e085c@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <PS3zal9ubJmUOl2UWMtgEiV2jgizMRBgQY8dG1ycbRU=.b9d2f5c6-cf9e-4f36-ada6-82190d4e085c@github.com>
Message-ID: <2J5B9f36sBaDcR73R3y9Knm2pszs-Dnoogisl6qt4VM=.f3a8303e-662a-45ec-b082-b95835d13b39@github.com>

On Wed, 23 Jul 2025 15:54:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test to use junit and test without preview mode.

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 71:

> 69:         } else {
> 70:             assertFalse(ValueClass.isFlatArray(array0));
> 71:         }

This does not seem to be related to Class.isIdentity(); what is the connection?
Identity or not is not connected to flat or not. Maybe it belongs in a different test.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226067440

From coleenp at openjdk.org  Wed Jul 23 16:51:21 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 16:51:21 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v3]
In-Reply-To: <KmqdkAv0UUl2pGmwF6ychl8cJolEyNhhARk_jvRh_Lo=.d0f6ec7f-91d1-408e-9510-e5390ed7ee8b@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <-Il4w5gwN_DWqiEoDZqZVnRCi4i80rsvrcTXNKeSEFs=.3315f3e5-1598-4ad6-a5cf-564c155c7385@github.com>
 <L0zks1P0jc20lUjE5TE2zfTvsWbH57LM4o_lPA6gFb4=.9b97711c-ce4c-440f-8c75-100bcd5d294c@github.com>
 <plscEU4t2PaGUoaXSDupycY5Z4TQqfBGwhdr1dhoErg=.c4e6573f-7b0d-4722-b4cf-9c07548c3947@github.com>
 <KmqdkAv0UUl2pGmwF6ychl8cJolEyNhhARk_jvRh_Lo=.d0f6ec7f-91d1-408e-9510-e5390ed7ee8b@github.com>
Message-ID: <EHih1NZcPeIHHNQVXNEjlF-JsgM4hUGbqk0mZXM3Gf4=.4f678ec9-333c-4f57-9460-0cc1fd0c038d@github.com>

On Wed, 23 Jul 2025 13:41:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Yes this is better performance because C2 now doesn't have to intrinsify this native call.
>
> I'd go ahead and create the isIdentity field and move this code to the constructor.
> The modifiers, component type and primitive flag are all available at once.

I'd rather not have anymore JVM/java.lang.Class handshake than we have now.  This uses existing fields.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226120736

From coleenp at openjdk.org  Wed Jul 23 16:51:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 16:51:22 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v3]
In-Reply-To: <LZCUA6R5xvDc3FQiSeyBhe96FgI9DfvQ5-BvbfLfQYI=.eee68a1c-5505-4d6a-ad5f-79901b196667@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <PS3zal9ubJmUOl2UWMtgEiV2jgizMRBgQY8dG1ycbRU=.b9d2f5c6-cf9e-4f36-ada6-82190d4e085c@github.com>
 <LZCUA6R5xvDc3FQiSeyBhe96FgI9DfvQ5-BvbfLfQYI=.eee68a1c-5505-4d6a-ad5f-79901b196667@github.com>
Message-ID: <2kLcwK9yYpXQ818pAx8FOn92_sA5mV02dMD_w0Ytw2Q=.38e79a3d-91b9-43fa-b156-d0149e1ac4cf@github.com>

On Wed, 23 Jul 2025 16:04:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test to use junit and test without preview mode.
>
> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 52:
> 
>> 50: 
>> 51:     private static void assertFalseIfPreview(boolean condition, String msg) {
>> 52:         if (PreviewFeatures.isEnabled()) {
> 
> We can use `assertEquals(!PreviewFeatures.isEnabled(), msg)`

Thats a good suggestion.

> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 63:
> 
>> 61:         RuntimeMXBean runtimeMxBean = ManagementFactory.getRuntimeMXBean();
>> 62:         List<String> arguments = runtimeMxBean.getInputArguments();
>> 63:         boolean UseArrayFlattening = !arguments.contains("-XX:-UseArrayFlattening");
> 
> Optional comments:
> 
> I wonder if it's more usually to obtain flags with serviceability, or explicitly pass -D properties...
> 
> Also for these global states, it's better to capture them with a `@Setup static void setup()` method and store in static fields, especially if multiple tests use these states.

I copied this out of a hotspot valhalla test.  If I remove the flattening tests, I suppose I won't need this anymore.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226134801
PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226137286

From coleenp at openjdk.org  Wed Jul 23 16:51:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 16:51:22 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v3]
In-Reply-To: <2kLcwK9yYpXQ818pAx8FOn92_sA5mV02dMD_w0Ytw2Q=.38e79a3d-91b9-43fa-b156-d0149e1ac4cf@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <PS3zal9ubJmUOl2UWMtgEiV2jgizMRBgQY8dG1ycbRU=.b9d2f5c6-cf9e-4f36-ada6-82190d4e085c@github.com>
 <LZCUA6R5xvDc3FQiSeyBhe96FgI9DfvQ5-BvbfLfQYI=.eee68a1c-5505-4d6a-ad5f-79901b196667@github.com>
 <2kLcwK9yYpXQ818pAx8FOn92_sA5mV02dMD_w0Ytw2Q=.38e79a3d-91b9-43fa-b156-d0149e1ac4cf@github.com>
Message-ID: <Y0LGt2rEtWP6yRCrQR2mt-0ynQcAcjKChgXj4Oj6LZM=.cc43e3db-b083-4391-bf64-ae3a67c90e17@github.com>

On Wed, 23 Jul 2025 16:43:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 63:
>> 
>>> 61:         RuntimeMXBean runtimeMxBean = ManagementFactory.getRuntimeMXBean();
>>> 62:         List<String> arguments = runtimeMxBean.getInputArguments();
>>> 63:         boolean UseArrayFlattening = !arguments.contains("-XX:-UseArrayFlattening");
>> 
>> Optional comments:
>> 
>> I wonder if it's more usually to obtain flags with serviceability, or explicitly pass -D properties...
>> 
>> Also for these global states, it's better to capture them with a `@Setup static void setup()` method and store in static fields, especially if multiple tests use these states.
>
> I copied this out of a hotspot valhalla test.  If I remove the flattening tests, I suppose I won't need this anymore.

There might be a better way to find this out though.  We use this in the Hotspot runtime valhalla tests, but those tests don't use junit, so @things aren't used.  For Hotspot, we're passing -XX flags for now and not using properties.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226151574

From coleenp at openjdk.org  Wed Jul 23 16:51:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 16:51:22 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v3]
In-Reply-To: <2J5B9f36sBaDcR73R3y9Knm2pszs-Dnoogisl6qt4VM=.f3a8303e-662a-45ec-b082-b95835d13b39@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <PS3zal9ubJmUOl2UWMtgEiV2jgizMRBgQY8dG1ycbRU=.b9d2f5c6-cf9e-4f36-ada6-82190d4e085c@github.com>
 <2J5B9f36sBaDcR73R3y9Knm2pszs-Dnoogisl6qt4VM=.f3a8303e-662a-45ec-b082-b95835d13b39@github.com>
Message-ID: <xxBJ3GCJSCWohxE9E5QPixCgX4fsMBhjVyykLbxAdSY=.bac418d5-e1c7-4574-9e2a-7b8bbaf2bd11@github.com>

On Wed, 23 Jul 2025 16:09:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test to use junit and test without preview mode.
>
> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 71:
> 
>> 69:         } else {
>> 70:             assertFalse(ValueClass.isFlatArray(array0));
>> 71:         }
> 
> This does not seem to be related to Class.isIdentity(); what is the connection?
> Identity or not is not connected to flat or not. Maybe it belongs in a different test.

With Fred's work for array flattening, I was testing that the array would be flattened.  But we do have other tests for this.  I can remove this part of the test.  I was trying to show that even if we've flattened an Integer array, the array itself is an identityClass.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226139190

From coleenp at openjdk.org  Wed Jul 23 17:24:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 17:24:54 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v4]
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <V1pQ5EBWxA0fkj1gKmL26I35Vxgti6rW7sLbv307EpQ=.8b2c5c79-5135-4675-ae9c-94e093c6b47e@github.com>

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

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

  Minimize the test.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1514/files
  - new: https://git.openjdk.org/valhalla/pull/1514/files/f26fea89..18f90e4f

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

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

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

From rriggs at openjdk.org  Wed Jul 23 18:30:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 18:30:16 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v4]
In-Reply-To: <EHih1NZcPeIHHNQVXNEjlF-JsgM4hUGbqk0mZXM3Gf4=.4f678ec9-333c-4f57-9460-0cc1fd0c038d@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <-Il4w5gwN_DWqiEoDZqZVnRCi4i80rsvrcTXNKeSEFs=.3315f3e5-1598-4ad6-a5cf-564c155c7385@github.com>
 <L0zks1P0jc20lUjE5TE2zfTvsWbH57LM4o_lPA6gFb4=.9b97711c-ce4c-440f-8c75-100bcd5d294c@github.com>
 <plscEU4t2PaGUoaXSDupycY5Z4TQqfBGwhdr1dhoErg=.c4e6573f-7b0d-4722-b4cf-9c07548c3947@github.com>
 <KmqdkAv0UUl2pGmwF6ychl8cJolEyNhhARk_jvRh_Lo=.d0f6ec7f-91d1-408e-9510-e5390ed7ee8b@github.com>
 <EHih1NZcPeIHHNQVXNEjlF-JsgM4hUGbqk0mZXM3Gf4=.4f678ec9-333c-4f57-9460-0cc1fd0c038d@github.com>
Message-ID: <64DHIDlwp2xppXVJi0kv2xOJmLEjXP8o-eEY-osSnNI=.aef4d802-28c8-456f-8501-534594112eb3@github.com>

On Wed, 23 Jul 2025 16:35:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I'd go ahead and create the isIdentity field and move this code to the constructor.
>> The modifiers, component type and primitive flag are all available at once.
>
> I'd rather not have anymore JVM/java.lang.Class handshake than we have now.  This uses existing fields.

The new field would be initialized by the code moved from IsIdentity() (not from the vm)
Skip it for now and it can be fixed up later.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226245440

From rriggs at openjdk.org  Wed Jul 23 18:30:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 18:30:16 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v4]
In-Reply-To: <V1pQ5EBWxA0fkj1gKmL26I35Vxgti6rW7sLbv307EpQ=.8b2c5c79-5135-4675-ae9c-94e093c6b47e@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <V1pQ5EBWxA0fkj1gKmL26I35Vxgti6rW7sLbv307EpQ=.8b2c5c79-5135-4675-ae9c-94e093c6b47e@github.com>
Message-ID: <lCNuLG_hs_GYG6Sqafs8XbccnwSv_oovsOHKXdy0YyE=.8ea7a3ba-19e0-45c8-ac8b-60b325be55cf@github.com>

On Wed, 23 Jul 2025 17:24:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minimize the test.

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 27:

> 25:  * @test
> 26:  * @summary Test that IsIdentityClass and modifiers return true for arrays that can be flattened.
> 27:  * @library /test/lib

You'll need to add `@enablePreview false` to counteract the setting in TEST.properties.
Its still running both tests as enablePreview = true.

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 41:

> 39: 
> 40: import jdk.internal.misc.PreviewFeatures;
> 41: import jdk.internal.value.ValueClass;

Unused import

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 62:

> 60:         assertFalseIfPreview(Modifier.isIdentity(imod), "Modifier of Integer should not have IDENTITY set");
> 61:         int amod = Integer[].class.getModifiers();
> 62:         assertTrue(Modifier.isIdentity(amod), "Modifier of array of inline types should have IDENTITY set");

Suggestion:

        assertEquals(PreviewFeatures.isPreviewEnabled(), Modifier.isIdentity(amod), "Modifier of array should have IDENTITY set");

Before Valhalla, Arrays had identity but did not have a modifier bit set.
When --enable-preview, the IDENTITY modifier bit is set.

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 68:

> 66:     void testAccessFlags() {
> 67:         Set<AccessFlag> iacc = Integer.class.accessFlags();
> 68:         assertFalseIfPreview(iacc.contains(Modifier.IDENTITY), "Access flags should not contain IDENTITY");

Suggestion:

        if (PreviewFeatures.isEnabled()) {
            Set<AccessFlag> iacc = Integer.class.accessFlags();
            assertFalse(iacc.contains(AccessFlag.IDENTITY), "Access flags should not contain IDENTITY");
        }
Without --enable-preview (before Valhalla), there was no IDENTITY accessflag.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226254970
PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226225014
PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226322924
PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226336992

From coleenp at openjdk.org  Wed Jul 23 19:02:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 19:02:22 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v5]
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <zIAOZY7PNVRqxbqRMqhxyEHYCUR4K14qBf5stVGBZtU=.21893d16-bd71-4dad-bb5f-dc8df4ee8c1d@github.com>

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:

 - Update test/jdk/valhalla/valuetypes/IsIdentityClassTest.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update test/jdk/valhalla/valuetypes/IsIdentityClassTest.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Add @enablePreview false and import.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1514/files
  - new: https://git.openjdk.org/valhalla/pull/1514/files/18f90e4f..3760602f

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

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

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

From qamai at openjdk.org  Wed Jul 23 19:02:06 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 23 Jul 2025 19:02:06 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v2]
In-Reply-To: <pYPSjW74z_quJ0tI4z25I_pgZ4Z_o8_8CFQhISR7VUY=.95a1c79b-692e-4d66-86c2-8ba107b7d743@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <pYPSjW74z_quJ0tI4z25I_pgZ4Z_o8_8CFQhISR7VUY=.95a1c79b-692e-4d66-86c2-8ba107b7d743@github.com>
Message-ID: <mvujtMHCrw3Gc3t52ReR4NnuSik-VH8ScVW79XJ54-s=.f284bc33-e149-4397-b272-69f044954c84@github.com>

On Tue, 22 Jul 2025 07:49:32 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
>> 
>> But maybe, a bit of archeology:
>> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
>> 
>> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
>> static int sort_field_by_offset(ciField** a, ciField** b)` and
>>   ```cpp
>>   // Now sort them by offset, 
>>   // (In principle, they could mix with superclass fields.)
>>   fields->sort(sort_field_by_offset);
>>   ```
>>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
>> 
>> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address Quan Anh's comments

LGTM, I have some small suggestions.

src/hotspot/share/oops/fieldStreams.hpp line 210:

> 208: class HierarchicalFieldStreamBase : public StackObj {
> 209: protected:
> 210:   virtual FieldStreamType& current_stream () = 0;

Small style: there should not be a space between the method name and the parenthesis. Also, I think these can be `private`.

src/hotspot/share/oops/fieldStreams.hpp line 277:

> 275:  */
> 276: template<typename FieldStreamType>
> 277: class HierarchicalFieldStream : public HierarchicalFieldStreamBase<FieldStreamType>  {

1. It's good practice marking a class as `final` so the compiler can do more efficient devirtualization.
2. It seems the `HierarchicalFieldStreamBase` is only for code reuse. Then it would be better to use private inheritance instead.

src/hotspot/share/oops/fieldStreams.hpp line 320:

> 318: 
> 319:  public:
> 320:   HierarchicalFieldStream(InstanceKlass* klass) :

While you are at it, this could be `explicit`, too.

src/hotspot/share/oops/fieldStreams.hpp line 342:

> 340:  * care about static fields, we restrict it to regular non-static fields.
> 341:  */
> 342: class TopDownHierarchicalNonStaticFieldStreamBase : public HierarchicalFieldStreamBase<JavaFieldStream> {

Same with this child of `HierarchicalFieldStreamBase`

src/hotspot/share/runtime/signature.hpp line 588:

> 586:     : _bt(T_ILLEGAL), _offset(-1), _symbol(nullptr) {}
> 587: 
> 588:   SigEntry(BasicType bt, int offset, Symbol* symbol, bool null_marker)

Ah `symbol` here should be the name, not the signature. Could you at least rename the parameter name here? Could we rename the field name, too?

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

Marked as reviewed by qamai (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1511#pullrequestreview-3048615246
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2226389572
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2226384669
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2226391619
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2226386450
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2226403068

From coleenp at openjdk.org  Wed Jul 23 19:17:16 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 19:17:16 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v5]
In-Reply-To: <64DHIDlwp2xppXVJi0kv2xOJmLEjXP8o-eEY-osSnNI=.aef4d802-28c8-456f-8501-534594112eb3@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <-Il4w5gwN_DWqiEoDZqZVnRCi4i80rsvrcTXNKeSEFs=.3315f3e5-1598-4ad6-a5cf-564c155c7385@github.com>
 <L0zks1P0jc20lUjE5TE2zfTvsWbH57LM4o_lPA6gFb4=.9b97711c-ce4c-440f-8c75-100bcd5d294c@github.com>
 <plscEU4t2PaGUoaXSDupycY5Z4TQqfBGwhdr1dhoErg=.c4e6573f-7b0d-4722-b4cf-9c07548c3947@github.com>
 <KmqdkAv0UUl2pGmwF6ychl8cJolEyNhhARk_jvRh_Lo=.d0f6ec7f-91d1-408e-9510-e5390ed7ee8b@github.com>
 <EHih1NZcPeIHHNQVXNEjlF-JsgM4hUGbqk0mZXM3Gf4=.4f678ec9-333c-4f57-9460-0cc1fd0c038d@github.com>
 <64DHIDlwp2xppXVJi0kv2xOJmLEjXP8o-eEY-osSnNI=.aef4d802-28c8-456f-8501-534594112eb3@github.com>
Message-ID: <iSAS3kB1pew8vaxPyeITqtxnC49WUgyscwXz5YFpvEc=.5c1984b1-6a12-4404-b449-653eab84e3da@github.com>

On Wed, 23 Jul 2025 17:38:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I'd rather not have anymore JVM/java.lang.Class handshake than we have now.  This uses existing fields.
>
> The new field would be initialized by the code moved from IsIdentity() (not from the vm)
> Skip it for now and it can be fixed up later.

okay.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226401855

From coleenp at openjdk.org  Wed Jul 23 19:17:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 19:17:18 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v4]
In-Reply-To: <lCNuLG_hs_GYG6Sqafs8XbccnwSv_oovsOHKXdy0YyE=.8ea7a3ba-19e0-45c8-ac8b-60b325be55cf@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <V1pQ5EBWxA0fkj1gKmL26I35Vxgti6rW7sLbv307EpQ=.8b2c5c79-5135-4675-ae9c-94e093c6b47e@github.com>
 <lCNuLG_hs_GYG6Sqafs8XbccnwSv_oovsOHKXdy0YyE=.8ea7a3ba-19e0-45c8-ac8b-60b325be55cf@github.com>
Message-ID: <t1aqpX2Ptpa77HYvazHyquInpFCaNSDI4ZRB4Hge7HI=.aa1d6df9-dbae-4ef6-bbb1-15302a703110@github.com>

On Wed, 23 Jul 2025 17:43:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minimize the test.
>
> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @summary Test that IsIdentityClass and modifiers return true for arrays that can be flattened.
>> 27:  * @library /test/lib
> 
> You'll need to add `@enablePreview false` to counteract the setting in TEST.properties.
> Its still running both tests as enablePreview = true.

Oh.  I see.  This test is really broken then.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2226402155

From coleenp at openjdk.org  Wed Jul 23 19:23:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Jul 2025 19:23:12 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v6]
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <zAoGA-QBPNwRzrdee_QhA-k8JOyx06YPzI0YAqMMPm8=.7eae5414-ec54-455a-b718-d03ff1a38250@github.com>

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

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

  Fix the test to test both --enable-preview and not.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1514/files
  - new: https://git.openjdk.org/valhalla/pull/1514/files/3760602f..50278a63

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

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

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

From rriggs at openjdk.org  Wed Jul 23 20:17:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Jul 2025 20:17:04 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v6]
In-Reply-To: <zAoGA-QBPNwRzrdee_QhA-k8JOyx06YPzI0YAqMMPm8=.7eae5414-ec54-455a-b718-d03ff1a38250@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <zAoGA-QBPNwRzrdee_QhA-k8JOyx06YPzI0YAqMMPm8=.7eae5414-ec54-455a-b718-d03ff1a38250@github.com>
Message-ID: <Ffbm2jLHMF5Flv54RFDGvSfAoYTixstaeKEQy3LcF7U=.dbc9d8bf-b876-4f2b-9b11-7a84cabbb5d6@github.com>

On Wed, 23 Jul 2025 19:23:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test to test both --enable-preview and not.

The test looks good, the conditions are more complicated than is obvious because with --enable-preview new modifier bits are defined with new used.
Thanks for the updates.

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

PR Review: https://git.openjdk.org/valhalla/pull/1514#pullrequestreview-3048874227

From dsimms at openjdk.org  Thu Jul 24 10:33:59 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 24 Jul 2025 10:33:59 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <-hmsa2Q7p6b_E0L6t_Fu8S8XtZ6OUJCb412ydsiulM4=.3d84d0b6-bd15-4308-a681-f9c2c4bac009@github.com>

Merge tag 'jdk-25+21' into lworld_merge_jdk_25_21
Added tag jdk-25+21 for changeset e2ae50d8

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

Commit messages:
 - Merge tag 'jdk-25+21' into lworld_merge_jdk_25_21
 - 8355569: Some nsk/jdi tests can glean the "main" thread by using the ClassPrepareEvent for the debuggee main class
 - 8297727: Forcing LF interpretation lead to StackOverflowError in reflection code
 - 8355956: Prepare javap for class file format aware access flag parsing
 - 8355650: Remove unused fields in ParkEvent
 - 8355971: Build warnings after the changes for JDK-8354996
 - 8350498: Remove two Camerfirma root CA certificates
 - 8354897: Support Soft/Weak Reference in AOT cache
 - 8354547: REDO: Force clients to explicitly pass mem_tag value, even if it is mtNone
 - 8355391: Use Long::hashCode in java.time
 - ... and 110 more: https://git.openjdk.org/valhalla/compare/64fe6c1e...e3ecda45

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

Changes: https://git.openjdk.org/valhalla/pull/1516/files
  Stats: 24151 lines in 707 files changed: 18003 ins; 3009 del; 3139 mod
  Patch: https://git.openjdk.org/valhalla/pull/1516.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1516/head:pull/1516

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

From mchevalier at openjdk.org  Thu Jul 24 11:38:44 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 24 Jul 2025 11:38:44 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v3]
In-Reply-To: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
Message-ID: <e2Y5iTgbaEu8uoEMCjvonuhWIWnzr0OzenJyidxymGU=.85640548-e13f-4166-b564-167e3003b2fe@github.com>

> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
> 
> But maybe, a bit of archeology:
> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
> 
> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
> static int sort_field_by_offset(ciField** a, ciField** b)` and
>   ```cpp
>   // Now sort them by offset, 
>   // (In principle, they could mix with superclass fields.)
>   fields->sort(sort_field_by_offset);
>   ```
>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
> 
> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstance...

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

  Second round of comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1511/files
  - new: https://git.openjdk.org/valhalla/pull/1511/files/76a7ee4d..c2ed2111

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

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

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

From mchevalier at openjdk.org  Thu Jul 24 11:44:11 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 24 Jul 2025 11:44:11 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v2]
In-Reply-To: <mvujtMHCrw3Gc3t52ReR4NnuSik-VH8ScVW79XJ54-s=.f284bc33-e149-4397-b272-69f044954c84@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <pYPSjW74z_quJ0tI4z25I_pgZ4Z_o8_8CFQhISR7VUY=.95a1c79b-692e-4d66-86c2-8ba107b7d743@github.com>
 <mvujtMHCrw3Gc3t52ReR4NnuSik-VH8ScVW79XJ54-s=.f284bc33-e149-4397-b272-69f044954c84@github.com>
Message-ID: <rVGpjgvGpNKA7o1qEYqPb9slUwgKR2Vt_a6DquerT8Q=.567946be-2b1f-4114-bc0f-b9fcfed95c46@github.com>

On Wed, 23 Jul 2025 18:50:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Quan Anh's comments
>
> src/hotspot/share/oops/fieldStreams.hpp line 277:
> 
>> 275:  */
>> 276: template<typename FieldStreamType>
>> 277: class HierarchicalFieldStream : public HierarchicalFieldStreamBase<FieldStreamType>  {
> 
> 1. It's good practice marking a class as `final` so the compiler can do more efficient devirtualization.
> 2. It seems the `HierarchicalFieldStreamBase` is only for code reuse. Then it would be better to use private inheritance instead.

1. Yes, good idea. I like that mostly for maintenance. On the other hand, despite my hopes, I never observed really compilers taking advantage of it in the wild (on made up examples, yes, of course).
2. I don't think I can: the public methods of the base class would then be private, and I need them in the public interface of the class. I've tried, and indeed, it doesn't compile.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2228271675

From qamai at openjdk.org  Thu Jul 24 11:50:17 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 24 Jul 2025 11:50:17 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v2]
In-Reply-To: <rVGpjgvGpNKA7o1qEYqPb9slUwgKR2Vt_a6DquerT8Q=.567946be-2b1f-4114-bc0f-b9fcfed95c46@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <pYPSjW74z_quJ0tI4z25I_pgZ4Z_o8_8CFQhISR7VUY=.95a1c79b-692e-4d66-86c2-8ba107b7d743@github.com>
 <mvujtMHCrw3Gc3t52ReR4NnuSik-VH8ScVW79XJ54-s=.f284bc33-e149-4397-b272-69f044954c84@github.com>
 <rVGpjgvGpNKA7o1qEYqPb9slUwgKR2Vt_a6DquerT8Q=.567946be-2b1f-4114-bc0f-b9fcfed95c46@github.com>
Message-ID: <M55LrRmsGvAJXaS7r2W1b1l5OdPNg9INitstFMZpwEA=.86b13748-972e-4f5a-bc3f-6385be4c8c38@github.com>

On Thu, 24 Jul 2025 11:41:01 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldStreams.hpp line 277:
>> 
>>> 275:  */
>>> 276: template<typename FieldStreamType>
>>> 277: class HierarchicalFieldStream : public HierarchicalFieldStreamBase<FieldStreamType>  {
>> 
>> 1. It's good practice marking a class as `final` so the compiler can do more efficient devirtualization.
>> 2. It seems the `HierarchicalFieldStreamBase` is only for code reuse. Then it would be better to use private inheritance instead.
>
> 1. Yes, good idea. I like that mostly for maintenance. On the other hand, despite my hopes, I never observed really compilers taking advantage of it in the wild (on made up examples, yes, of course).
> 2. I don't think I can: the public methods of the base class would then be private, and I need them in the public interface of the class. I've tried, and indeed, it doesn't compile.

I believe they do devirtualize with `final` while non-`final` methods go through the whole virtual call sequence: https://godbolt.org/z/9MM1Kqqx8

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2228284914

From coleenp at openjdk.org  Thu Jul 24 12:32:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Jul 2025 12:32:52 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v7]
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

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

  Fix the test some more.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1514/files
  - new: https://git.openjdk.org/valhalla/pull/1514/files/50278a63..16210aa3

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

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

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

From rriggs at openjdk.org  Thu Jul 24 13:19:07 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Jul 2025 13:19:07 GMT
Subject: [lworld] Integrated: 8361307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects
In-Reply-To: <fIE_gRwECFlFD-Be5vvy9lhbCVB7kId1K2c5dzL3J2M=.4e9f23a0-2203-45b0-b58c-816627343df3@github.com>
References: <fIE_gRwECFlFD-Be5vvy9lhbCVB7kId1K2c5dzL3J2M=.4e9f23a0-2203-45b0-b58c-816627343df3@github.com>
Message-ID: <WpdV8mHpIDYl-oYaaBM61q_MI48VBIDNbDrXcRLMssc=.9cf16777-6732-4a42-a832-ef535c7c9442@github.com>

On Mon, 21 Jul 2025 18:01:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Javadoc updates to clarify value class vs identity class distinctions when in preview-mode and not.

This pull request has now been integrated.

Changeset: 3626f889
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3626f889702c5300ff357f7ca088e542018f6d5b
Stats:     286 lines in 10 files changed: 235 ins; 8 del; 43 mod

8361307: [lworld] Clarify identity vs value in Class, Objects, and document limitations of value objects

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

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

From rriggs at openjdk.org  Thu Jul 24 15:32:09 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Jul 2025 15:32:09 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v7]
In-Reply-To: <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
Message-ID: <5Ylq_VxxuUr2UtI6zKuxdOOoc2JTsHP7-Ui68mYPyBY=.f9937e87-0577-4f8b-81da-f26be48763d2@github.com>

On Thu, 24 Jul 2025 12:32:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test some more.

Look good, thanks

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1514#pullrequestreview-3052179701

From fparain at openjdk.org  Thu Jul 24 16:48:22 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 24 Jul 2025 16:48:22 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in class
 loaders
Message-ID: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>

Add pre-registration of boxing classes when a class loader is registered by the VM.

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

Commit messages:
 - Fix tab
 - Add pre-registration of boxing classes

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

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

From fparain at openjdk.org  Thu Jul 24 17:00:47 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 24 Jul 2025 17:00:47 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v2]
In-Reply-To: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
Message-ID: <8m3SUe_XKAXwKXfT1ZXCk6YxbpsUySBgJVDyxGIt1Q8=.ac8f70d8-1392-4fd4-8682-cb057d3b1467@github.com>

> Add pre-registration of boxing classes when a class loader is registered by the VM.

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

  Remove comment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1517/files
  - new: https://git.openjdk.org/valhalla/pull/1517/files/12c2b458..aad64784

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

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

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

From liach at openjdk.org  Thu Jul 24 17:10:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 17:10:11 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v7]
In-Reply-To: <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
Message-ID: <YuTvh7DNsNtfJzss_76leRf8ln2JhfTNsRv4UoBfPSA=.5b3a94cd-e41d-4114-b0a4-0682741184a3@github.com>

On Thu, 24 Jul 2025 12:32:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test some more.

test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 30:

> 28:  * @enablePreview false
> 29:  * @modules java.base/jdk.internal.misc
> 30:  *          java.base/jdk.internal.value

TEST.properties is updated; we might remove these directives.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2229088882

From liach at openjdk.org  Thu Jul 24 18:16:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 18:16:10 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v7]
In-Reply-To: <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
Message-ID: <_Djap5xZZDez445GbyJyVqbpHIcxMfcApOOmkTrveYk=.e5ad3c72-92f2-46b2-b999-3b93e2ee928c@github.com>

On Thu, 24 Jul 2025 12:32:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test some more.

The redundant directives in tests are fine.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1514#pullrequestreview-3052703183

From coleenp at openjdk.org  Thu Jul 24 18:16:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Jul 2025 18:16:11 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v7]
In-Reply-To: <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
Message-ID: <rnD4aA3oBxTeSNwlprENQqfg162STjbbjuNFmwzyR2I=.34c0d471-2bf9-47f3-abe1-f33fe606279b@github.com>

On Thu, 24 Jul 2025 12:32:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
>> Added a test.
>> Tested with tier1 locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test some more.

Thank you for all your help with this test, Roger and Chen.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1514#issuecomment-3114391826

From coleenp at openjdk.org  Thu Jul 24 18:16:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Jul 2025 18:16:11 GMT
Subject: [lworld] RFR: 8363846: [lworld] Make Class.isIdentityClass()
 non-native [v7]
In-Reply-To: <YuTvh7DNsNtfJzss_76leRf8ln2JhfTNsRv4UoBfPSA=.5b3a94cd-e41d-4114-b0a4-0682741184a3@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
 <YGmjB8VlXoQ8XURBCURbQcIVIZJ9KWPXIL_eX5s2PBY=.bef0a682-2a7a-42f9-b1a6-fbe74db20c79@github.com>
 <YuTvh7DNsNtfJzss_76leRf8ln2JhfTNsRv4UoBfPSA=.5b3a94cd-e41d-4114-b0a4-0682741184a3@github.com>
Message-ID: <bo4lts2LNplvcLUB96fag_VBgtISAeEg4p2mgqLLB6Y=.ef1e59cb-d915-44d3-8cdd-f0b2bdf3a8dc@github.com>

On Thu, 24 Jul 2025 17:07:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the test some more.
>
> test/jdk/valhalla/valuetypes/IsIdentityClassTest.java line 30:
> 
>> 28:  * @enablePreview false
>> 29:  * @modules java.base/jdk.internal.misc
>> 30:  *          java.base/jdk.internal.value
> 
> TEST.properties is updated; we might remove these directives.

Thanks, I can't merge right now with the latest to test.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1514#discussion_r2229215214

From coleenp at openjdk.org  Thu Jul 24 18:16:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Jul 2025 18:16:12 GMT
Subject: [lworld] Integrated: 8363846: [lworld] Make Class.isIdentityClass()
 non-native
In-Reply-To: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
References: <kAPPO5VJ9zZKYLwAV2Aa8Ibl2ELB06FxfWMnkeDGiwU=.fc1e22b4-38f0-4f0d-8e9e-14b65e14dfd4@github.com>
Message-ID: <SYYwZphWqk0EZNfPHOBhcPHZzIdRzuyN4V86ZXWu6SY=.7888b83a-9986-4ec5-80c4-a5744702f753@github.com>

On Tue, 22 Jul 2025 17:41:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves isIdentityClass() implementation to Class.java, and checks within the JVM that is_identity_class() doesn't check the access flags for an ArrayKlass, since AccessFlags aren't initialized in ArrayKlasses.  The AccessFlags should be moved from Klass.hpp to InstanceKlass.cpp in mainline but that's a more complicated change and has several pieces.
> Added a test.
> Tested with tier1 locally.

This pull request has now been integrated.

Changeset: acfb4f04
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/acfb4f047c6a43b2d85f48385d356a0d54161e2c
Stats:     106 lines in 7 files changed: 87 ins; 14 del; 5 mod

8363846: [lworld] Make Class.isIdentityClass() non-native

Reviewed-by: liach, rriggs

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

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

From liach at openjdk.org  Thu Jul 24 19:27:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Jul 2025 19:27:11 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v2]
In-Reply-To: <8m3SUe_XKAXwKXfT1ZXCk6YxbpsUySBgJVDyxGIt1Q8=.ac8f70d8-1392-4fd4-8682-cb057d3b1467@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
 <8m3SUe_XKAXwKXfT1ZXCk6YxbpsUySBgJVDyxGIt1Q8=.ac8f70d8-1392-4fd4-8682-cb057d3b1467@github.com>
Message-ID: <8kF-BXZF_8N3D8n43bFDyaWQSvododdHubl1OCdngWc=.fd0406bf-e032-4fd0-a0d0-4739b7034cf1@github.com>

On Thu, 24 Jul 2025 17:00:47 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Add pre-registration of boxing classes when a class loader is registered by the VM.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment

Are we planning to register Optional next? And do we have a measure for how far the eager registration would go?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1517#issuecomment-3114635338

From fparain at openjdk.org  Thu Jul 24 20:14:02 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 24 Jul 2025 20:14:02 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v2]
In-Reply-To: <8kF-BXZF_8N3D8n43bFDyaWQSvododdHubl1OCdngWc=.fd0406bf-e032-4fd0-a0d0-4739b7034cf1@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
 <8m3SUe_XKAXwKXfT1ZXCk6YxbpsUySBgJVDyxGIt1Q8=.ac8f70d8-1392-4fd4-8682-cb057d3b1467@github.com>
 <8kF-BXZF_8N3D8n43bFDyaWQSvododdHubl1OCdngWc=.fd0406bf-e032-4fd0-a0d0-4739b7034cf1@github.com>
Message-ID: <sQ9BXamFrL2doPjKIq7ZqV7CV_T33YSflz6prLJm5Tw=.760a44ea-3a5c-416b-ab09-8a3acd9b0c5a@github.com>

On Thu, 24 Jul 2025 19:24:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> Are we planning to register Optional next? And do we have a measure for how far the eager registration would go?

Optional requires a different set of changes because it is not currently a class known by the JVM.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1517#issuecomment-3114783207

From dsimms at openjdk.org  Fri Jul 25 05:05:17 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 25 Jul 2025 05:05:17 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <-hmsa2Q7p6b_E0L6t_Fu8S8XtZ6OUJCb412ydsiulM4=.3d84d0b6-bd15-4308-a681-f9c2c4bac009@github.com>
References: <-hmsa2Q7p6b_E0L6t_Fu8S8XtZ6OUJCb412ydsiulM4=.3d84d0b6-bd15-4308-a681-f9c2c4bac009@github.com>
Message-ID: <DyFg33TFUCBNK9-oDDEtqc1AwtE3VxBNF9oeW-CMWus=.328f5968-a51f-4fad-93dc-dec153ab4144@github.com>

> Merge tag 'jdk-25+21' into lworld_merge_jdk_25_21
> Added tag jdk-25+21 for changeset e2ae50d8

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

  Problem list for 8364095

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1516/files
  - new: https://git.openjdk.org/valhalla/pull/1516/files/e3ecda45..083af868

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

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

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

From dsimms at openjdk.org  Fri Jul 25 05:05:17 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 25 Jul 2025 05:05:17 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <-hmsa2Q7p6b_E0L6t_Fu8S8XtZ6OUJCb412ydsiulM4=.3d84d0b6-bd15-4308-a681-f9c2c4bac009@github.com>
References: <-hmsa2Q7p6b_E0L6t_Fu8S8XtZ6OUJCb412ydsiulM4=.3d84d0b6-bd15-4308-a681-f9c2c4bac009@github.com>
Message-ID: <CNso2r_SFsP8zbaeYQE2SMkT5CVLuAObK9CYViycPeI=.08a8550c-92f2-4e48-8772-3a7f8d3a3d5b@github.com>

On Thu, 24 Jul 2025 10:26:09 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+21' into lworld_merge_jdk_25_21
> Added tag jdk-25+21 for changeset e2ae50d8

This pull request has now been integrated.

Changeset: 899efede
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/899efede437ba5b218a33ec13d5c00a15e94e054
Stats:     24152 lines in 708 files changed: 18005 ins; 3009 del; 3138 mod

Merge jdk

Merge jdk-25+21

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

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

From mchevalier at openjdk.org  Fri Jul 25 07:27:12 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 07:27:12 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v2]
In-Reply-To: <M55LrRmsGvAJXaS7r2W1b1l5OdPNg9INitstFMZpwEA=.86b13748-972e-4f5a-bc3f-6385be4c8c38@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <pYPSjW74z_quJ0tI4z25I_pgZ4Z_o8_8CFQhISR7VUY=.95a1c79b-692e-4d66-86c2-8ba107b7d743@github.com>
 <mvujtMHCrw3Gc3t52ReR4NnuSik-VH8ScVW79XJ54-s=.f284bc33-e149-4397-b272-69f044954c84@github.com>
 <rVGpjgvGpNKA7o1qEYqPb9slUwgKR2Vt_a6DquerT8Q=.567946be-2b1f-4114-bc0f-b9fcfed95c46@github.com>
 <M55LrRmsGvAJXaS7r2W1b1l5OdPNg9INitstFMZpwEA=.86b13748-972e-4f5a-bc3f-6385be4c8c38@github.com>
Message-ID: <B7rJgTLLykmVWQ7WR67rQsa3sJ9gArlHQvRhuAz3YQk=.b5bb49ad-ddd7-4a47-bc7b-ec7081749e41@github.com>

On Thu, 24 Jul 2025 11:47:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> 1. Yes, good idea. I like that mostly for maintenance. On the other hand, despite my hopes, I never observed really compilers taking advantage of it in the wild (on made up examples, yes, of course).
>> 2. I don't think I can: the public methods of the base class would then be private, and I need them in the public interface of the class. I've tried, and indeed, it doesn't compile.
>
> I believe they do devirtualize with `final` while non-`final` methods go through the whole virtual call sequence: https://godbolt.org/z/9MM1Kqqx8

Yes, of course, it can in such cases. But in actual code, I often end up with either an object of the final type (instead of a reference), and then, final doesn't help, or a reference/pointer to a base type, and so I don't save virtual call. In the past,  some big campaign of `final`izing everything were rewarded by no measurable performance improvement. But I still like it, as a hint for the reader not to try to find derived classes (but that the class actually is done implementing the thing it does), a warning that the class wasn't meant to be inherited (so be careful), and still hoping one in a while, it can save some virtual calls.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230364286

From thartmann at openjdk.org  Fri Jul 25 08:26:09 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Jul 2025 08:26:09 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v3]
In-Reply-To: <e2Y5iTgbaEu8uoEMCjvonuhWIWnzr0OzenJyidxymGU=.85640548-e13f-4166-b564-167e3003b2fe@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <e2Y5iTgbaEu8uoEMCjvonuhWIWnzr0OzenJyidxymGU=.85640548-e13f-4166-b564-167e3003b2fe@github.com>
Message-ID: <p002LGqLER6nKJZJYLWqdiI4ziTpkHNxgW8kIa3MdN4=.f5a5af30-272d-4f40-a23b-677cdbd33e44@github.com>

On Thu, 24 Jul 2025 11:38:44 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
>> 
>> But maybe, a bit of archeology:
>> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
>> 
>> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
>> static int sort_field_by_offset(ciField** a, ciField** b)` and
>>   ```cpp
>>   // Now sort them by offset, 
>>   // (In principle, they could mix with superclass fields.)
>>   fields->sort(sort_field_by_offset);
>>   ```
>>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
>> 
>> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second round of comments

Thanks for the thorough analysis Marc! I'm glad to see this code being fixed and cleaned up. Looks all good to me, I just found a few minor things.

> Nice, I have a pending issue of making this sort less a minefield but removing it completely is absolutely better.

@merykitty Should we close [JDK-8348547](https://bugs.openjdk.org/browse/JDK-8348547) as duplicate then? If so, I would suggest to integrate the regression tests attached to this bug with this PR. @marc-chevalier you might want to verify that they pass now.

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

> 3844:       if (!did_name)
> 3845:         stream->print("%s", type2name(t));
> 3846:       // If the entry has a non-default sort_offset, it must be a null marker

Comment needs to be updated.

src/hotspot/share/oops/fieldStreams.hpp line 336:

> 334: /* Iterates on the fields of a class and its super-class top-down (java.lang.Object first)
> 335:  * Doesn't traverse interfaces for now, because it's not clear which order would make sense
> 336:  * Let's decide how  when/if the needs appear. Since we are not traversing interfaces, we

Suggestion:

 * Let's decide when or if the need arises. Since we are not traversing interfaces, we

src/hotspot/share/oops/inlineKlass.cpp line 447:

> 445:     if (*PrintInlineKlassFields != '\0') {
> 446:       const char* class_name_str = _name->as_C_string();
> 447:       if (StringUtils::class_list_match(PrintInlineKlassFields, class_name_str)) {

Nice! I already added similar printing multiple times when debugging issues in this area. Not sure why I never integrated that.

src/hotspot/share/runtime/sharedRuntime.cpp line 2869:

> 2867:             if (bt == T_OBJECT) {
> 2868:               // Nullable inline type argument, insert InlineTypeNode::NullMarker field right after T_METADATA delimiter
> 2869:               // Set the sort_offset so that the field is detected as null marker by nmethod::print_nmethod_labels.

This comment needs to be updated. It still mentions the `sort_offset`.

src/hotspot/share/runtime/signature.hpp line 582:

> 580:   BasicType _bt;      // Basic type of the argument
> 581:   int _offset;        // Offset of the field in its value class holder for scalarized arguments (-1 otherwise). Used for packing and unpacking.
> 582:   float _sort_offset; // Offset used for sorting

I'm glad this is gone now. Always felt hacky.

src/hotspot/share/runtime/signature.hpp line 583:

> 581:   int _offset;        // Offset of the field in its value class holder for scalarized arguments (-1 otherwise). Used for packing and unpacking.
> 582:   Symbol* _name;    // Symbol for printing
> 583:   bool _null_marker;   // Is it a null marker? For printing

Suggestion:

  Symbol* _name;      // Symbol for printing
  bool _null_marker;  // Is it a null marker? For printing

test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java line 89:

> 87:                     .append("]: ");
> 88:             for (int i = 0; i < arrayField.length; ++i) {
> 89:                 if(i != 0) {

Suggestion:

                if (i != 0) {

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1511#pullrequestreview-3054493576
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230485359
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230466436
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230488247
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230483994
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230481700
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230458927
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230440942

From thartmann at openjdk.org  Fri Jul 25 08:32:07 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Jul 2025 08:32:07 GMT
Subject: [lworld] RFR: 8354404: [lworld]
 compiler/startup/StartupOutput.java crashes during
 AdapterHandlerLibrary::initialize() due to too little CodeCacheSize
In-Reply-To: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
References: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
Message-ID: <d9Vr1uE-4Qw9Mnwg-i796hXDwfPkUQ0HXERXXmUWENU=.e27a61f4-e29c-4dba-973c-c71e3034eec5@github.com>

On Wed, 16 Jul 2025 14:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Experimentally, replacing 800 with 2000 is needed to have this test pass on all platform. Somehow, while 1300 seems ok on my Linux (while having a fair share of "CodeCache is full. Compiler has been disabled." messages), Windows boxes seems to struggle even with 1800. Not sure why: isn't the size of the things in the code cache (that is, the code), depends mostly on the encoding of instructions, that is dependent on architecture, not OS? Anyway, it happens reliably, so something had to be done!
> 
> Let's compare (with debug builds so I can use `CodeCacheMinimumUseSpace`, that is 1200k by default on debug builds), for various values of `ReservedCodeCacheSize` (in k), when running `-version`. For mainline:
> - [4, 28]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 3000 bytes. Error detail: `CodeCache: no room for StubRoutines` (continuation stubs)
>   ```
>   coming from
>   - `report_should_not_call(char const*, int)`
>   - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
>   - `StubRoutines::initialize_continuation_stubs()`
>   - `continuation_stubs_init()`
>   - `init_globals()`
>   
>   with `3000` being `20000` for `ReservedCodeCacheSize` between 5 and 24, and being `500` for `ReservedCodeCacheSize` = 4 (the minimum).
> 
> - [29, 32] `fatal error: Initial size of CodeCache is too small`
>   https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
>   coming from
>   - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
>   - `SharedRuntime::generate_jfr_return_lease()`
>   - `SharedRuntime::generate_jfr_stubs()`
>   - `init_globals()`
> 
> - [33, 1112]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 1108928 bytes. Error detail: CodeCache: no room for Interpreter
>   ```
>   - `...`
>   - `report_should_not_call(char const*, int)`
>   - `StubQueue::StubQueue(StubInterface*, int, Mutex*, char const*)`
>   - `TemplateInterpreter::initialize_stub()`
>   - `interpreter_init_stub()`
>   - `init_globals()`
> 
> - [1113, 1116] SIGSEGV
>   - `CodeSection::emit_int8(unsigned char)`
>   - `AbstractAssembler::emit_int8(int)`
>   - `Assembler::push(Register)`
>   - `MacroAssembler::enter()`
>   - `RegisterSaver::save_live_registers(MacroAssembler*, int, int*, bool)`
>   - `SharedRuntime::generate_resolve_blob(StubId, unsigne...

Thanks for spending time on looking into this thoroughly. The fix looks good to me for now. As we discussed offline, let's file a follow-up RFE to check again once [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209) is integrated.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1509#pullrequestreview-3054577186

From qamai at openjdk.org  Fri Jul 25 08:55:17 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 25 Jul 2025 08:55:17 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v3]
In-Reply-To: <p002LGqLER6nKJZJYLWqdiI4ziTpkHNxgW8kIa3MdN4=.f5a5af30-272d-4f40-a23b-677cdbd33e44@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <e2Y5iTgbaEu8uoEMCjvonuhWIWnzr0OzenJyidxymGU=.85640548-e13f-4166-b564-167e3003b2fe@github.com>
 <p002LGqLER6nKJZJYLWqdiI4ziTpkHNxgW8kIa3MdN4=.f5a5af30-272d-4f40-a23b-677cdbd33e44@github.com>
Message-ID: <cSjjGOH1KHX_mA7N0rUKPAhQ0lVbxlqlQqSoMk4JlGE=.1766c8db-d23f-4348-89c5-dae438f99db7@github.com>

On Fri, 25 Jul 2025 08:23:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Second round of comments
>
> Thanks for the thorough analysis Marc! I'm glad to see this code being fixed and cleaned up. Looks all good to me, I just found a few minor things.
> 
>> Nice, I have a pending issue of making this sort less a minefield but removing it completely is absolutely better.
> 
> @merykitty Should we close [JDK-8348547](https://bugs.openjdk.org/browse/JDK-8348547) as duplicate then? If so, I would suggest to integrate the regression tests attached to this bug with this PR. @marc-chevalier you might want to verify that they pass now.

@TobiHartmann Unfortunately, I don't think this PR solves [JDK-8348547](https://bugs.openjdk.org/browse/JDK-8348547). It solves [JDK-8357186](https://bugs.openjdk.org/browse/JDK-8357186), though.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1511#issuecomment-3116954932

From mchevalier at openjdk.org  Fri Jul 25 09:23:08 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 09:23:08 GMT
Subject: [lworld] RFR: 8354404: [lworld]
 compiler/startup/StartupOutput.java crashes during
 AdapterHandlerLibrary::initialize() due to too little CodeCacheSize [v2]
In-Reply-To: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
References: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
Message-ID: <8BIOiszgD55f0jNYbGIANGMNYdLm2Vhm-OoCGx_bRRA=.1e2e199f-712d-4ba3-b8f8-f678f400e024@github.com>

> Experimentally, replacing 800 with 2000 is needed to have this test pass on all platform. Somehow, while 1300 seems ok on my Linux (while having a fair share of "CodeCache is full. Compiler has been disabled." messages), Windows boxes seems to struggle even with 1800. Not sure why: isn't the size of the things in the code cache (that is, the code), depends mostly on the encoding of instructions, that is dependent on architecture, not OS? Anyway, it happens reliably, so something had to be done!
> 
> Let's compare (with debug builds so I can use `CodeCacheMinimumUseSpace`, that is 1200k by default on debug builds), for various values of `ReservedCodeCacheSize` (in k), when running `-version`. For mainline:
> - [4, 28]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 3000 bytes. Error detail: `CodeCache: no room for StubRoutines` (continuation stubs)
>   ```
>   coming from
>   - `report_should_not_call(char const*, int)`
>   - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
>   - `StubRoutines::initialize_continuation_stubs()`
>   - `continuation_stubs_init()`
>   - `init_globals()`
>   
>   with `3000` being `20000` for `ReservedCodeCacheSize` between 5 and 24, and being `500` for `ReservedCodeCacheSize` = 4 (the minimum).
> 
> - [29, 32] `fatal error: Initial size of CodeCache is too small`
>   https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
>   coming from
>   - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
>   - `SharedRuntime::generate_jfr_return_lease()`
>   - `SharedRuntime::generate_jfr_stubs()`
>   - `init_globals()`
> 
> - [33, 1112]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 1108928 bytes. Error detail: CodeCache: no room for Interpreter
>   ```
>   - `...`
>   - `report_should_not_call(char const*, int)`
>   - `StubQueue::StubQueue(StubInterface*, int, Mutex*, char const*)`
>   - `TemplateInterpreter::initialize_stub()`
>   - `interpreter_init_stub()`
>   - `init_globals()`
> 
> - [1113, 1116] SIGSEGV
>   - `CodeSection::emit_int8(unsigned char)`
>   - `AbstractAssembler::emit_int8(int)`
>   - `Assembler::push(Register)`
>   - `MacroAssembler::enter()`
>   - `RegisterSaver::save_live_registers(MacroAssembler*, int, int*, bool)`
>   - `SharedRuntime::generate_resolve_blob(StubId, unsigne...

Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge remote-tracking branch 'origin/lworld' into JDK-8354404.StartupOutput-fails
 - trying a bit more...
 - Raise limit in StartupOutput.java

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

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

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

From mchevalier at openjdk.org  Fri Jul 25 09:26:05 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 09:26:05 GMT
Subject: [lworld] RFR: 8354404: [lworld]
 compiler/startup/StartupOutput.java crashes during
 AdapterHandlerLibrary::initialize() due to too little CodeCacheSize
In-Reply-To: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
References: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
Message-ID: <hZ9OeGr50dinBEXY5abUK8WUeqYoEXmOpxyhUQkWcLU=.6bb87f94-0e7f-4ef5-b0a1-276a953c0728@github.com>

On Wed, 16 Jul 2025 14:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Experimentally, replacing 800 with 2000 is needed to have this test pass on all platform. Somehow, while 1300 seems ok on my Linux (while having a fair share of "CodeCache is full. Compiler has been disabled." messages), Windows boxes seems to struggle even with 1800. Not sure why: isn't the size of the things in the code cache (that is, the code), depends mostly on the encoding of instructions, that is dependent on architecture, not OS? Anyway, it happens reliably, so something had to be done!
> 
> Let's compare (with debug builds so I can use `CodeCacheMinimumUseSpace`, that is 1200k by default on debug builds), for various values of `ReservedCodeCacheSize` (in k), when running `-version`. For mainline:
> - [4, 28]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 3000 bytes. Error detail: `CodeCache: no room for StubRoutines` (continuation stubs)
>   ```
>   coming from
>   - `report_should_not_call(char const*, int)`
>   - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
>   - `StubRoutines::initialize_continuation_stubs()`
>   - `continuation_stubs_init()`
>   - `init_globals()`
>   
>   with `3000` being `20000` for `ReservedCodeCacheSize` between 5 and 24, and being `500` for `ReservedCodeCacheSize` = 4 (the minimum).
> 
> - [29, 32] `fatal error: Initial size of CodeCache is too small`
>   https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
>   coming from
>   - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
>   - `SharedRuntime::generate_jfr_return_lease()`
>   - `SharedRuntime::generate_jfr_stubs()`
>   - `init_globals()`
> 
> - [33, 1112]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 1108928 bytes. Error detail: CodeCache: no room for Interpreter
>   ```
>   - `...`
>   - `report_should_not_call(char const*, int)`
>   - `StubQueue::StubQueue(StubInterface*, int, Mutex*, char const*)`
>   - `TemplateInterpreter::initialize_stub()`
>   - `interpreter_init_stub()`
>   - `init_globals()`
> 
> - [1113, 1116] SIGSEGV
>   - `CodeSection::emit_int8(unsigned char)`
>   - `AbstractAssembler::emit_int8(int)`
>   - `Assembler::push(Register)`
>   - `MacroAssembler::enter()`
>   - `RegisterSaver::save_live_registers(MacroAssembler*, int, int*, bool)`
>   - `SharedRuntime::generate_resolve_blob(StubId, unsigne...

Thanks @TobiHartmann. To be continued...

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

PR Comment: https://git.openjdk.org/valhalla/pull/1509#issuecomment-3117048890

From duke at openjdk.org  Fri Jul 25 09:26:07 2025
From: duke at openjdk.org (duke)
Date: Fri, 25 Jul 2025 09:26:07 GMT
Subject: [lworld] RFR: 8354404: [lworld]
 compiler/startup/StartupOutput.java crashes during
 AdapterHandlerLibrary::initialize() due to too little CodeCacheSize [v2]
In-Reply-To: <8BIOiszgD55f0jNYbGIANGMNYdLm2Vhm-OoCGx_bRRA=.1e2e199f-712d-4ba3-b8f8-f678f400e024@github.com>
References: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
 <8BIOiszgD55f0jNYbGIANGMNYdLm2Vhm-OoCGx_bRRA=.1e2e199f-712d-4ba3-b8f8-f678f400e024@github.com>
Message-ID: <rMS6zXFt-E5Z0U_ymYNJ4OXCokzkBFfh_4tfJmZH30E=.1ae9721f-d38d-44c8-ab92-459d4d80aae1@github.com>

On Fri, 25 Jul 2025 09:23:08 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Experimentally, replacing 800 with 2000 is needed to have this test pass on all platform. Somehow, while 1300 seems ok on my Linux (while having a fair share of "CodeCache is full. Compiler has been disabled." messages), Windows boxes seems to struggle even with 1800. Not sure why: isn't the size of the things in the code cache (that is, the code), depends mostly on the encoding of instructions, that is dependent on architecture, not OS? Anyway, it happens reliably, so something had to be done!
>> 
>> Let's compare (with debug builds so I can use `CodeCacheMinimumUseSpace`, that is 1200k by default on debug builds), for various values of `ReservedCodeCacheSize` (in k), when running `-version`. For mainline:
>> - [4, 28]
>>   ```
>>   # There is insufficient memory for the Java Runtime Environment to continue.
>>   # Native memory allocation (malloc) failed to allocate 3000 bytes. Error detail: `CodeCache: no room for StubRoutines` (continuation stubs)
>>   ```
>>   coming from
>>   - `report_should_not_call(char const*, int)`
>>   - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
>>   - `StubRoutines::initialize_continuation_stubs()`
>>   - `continuation_stubs_init()`
>>   - `init_globals()`
>>   
>>   with `3000` being `20000` for `ReservedCodeCacheSize` between 5 and 24, and being `500` for `ReservedCodeCacheSize` = 4 (the minimum).
>> 
>> - [29, 32] `fatal error: Initial size of CodeCache is too small`
>>   https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
>>   coming from
>>   - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
>>   - `SharedRuntime::generate_jfr_return_lease()`
>>   - `SharedRuntime::generate_jfr_stubs()`
>>   - `init_globals()`
>> 
>> - [33, 1112]
>>   ```
>>   # There is insufficient memory for the Java Runtime Environment to continue.
>>   # Native memory allocation (malloc) failed to allocate 1108928 bytes. Error detail: CodeCache: no room for Interpreter
>>   ```
>>   - `...`
>>   - `report_should_not_call(char const*, int)`
>>   - `StubQueue::StubQueue(StubInterface*, int, Mutex*, char const*)`
>>   - `TemplateInterpreter::initialize_stub()`
>>   - `interpreter_init_stub()`
>>   - `init_globals()`
>> 
>> - [1113, 1116] SIGSEGV
>>   - `CodeSection::emit_int8(unsigned char)`
>>   - `AbstractAssembler::emit_int8(int)`
>>   - `Assembler::push(Register)`
>>   - `MacroAssembler::enter()`
>>   - `RegisterSaver::save_live_registers(MacroA...
>
> Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'origin/lworld' into JDK-8354404.StartupOutput-fails
>  - trying a bit more...
>  - Raise limit in StartupOutput.java

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1509#issuecomment-3117050932

From mchevalier at openjdk.org  Fri Jul 25 09:40:52 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 09:40:52 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v4]
In-Reply-To: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
Message-ID: <Kb5Sh44Y5NxeemFrNJX0k_q6EEh5wpoZAFDtBmj0Eo8=.0ac0a424-98d7-404b-abd3-0c019670377e@github.com>

> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
> 
> But maybe, a bit of archeology:
> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
> 
> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
> static int sort_field_by_offset(ciField** a, ciField** b)` and
>   ```cpp
>   // Now sort them by offset, 
>   // (In principle, they could mix with superclass fields.)
>   fields->sort(sort_field_by_offset);
>   ```
>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
> 
> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstance...

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

  More review

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1511/files
  - new: https://git.openjdk.org/valhalla/pull/1511/files/c2ed2111..002fbef4

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

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

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

From mchevalier at openjdk.org  Fri Jul 25 09:40:53 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 09:40:53 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v3]
In-Reply-To: <e2Y5iTgbaEu8uoEMCjvonuhWIWnzr0OzenJyidxymGU=.85640548-e13f-4166-b564-167e3003b2fe@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <e2Y5iTgbaEu8uoEMCjvonuhWIWnzr0OzenJyidxymGU=.85640548-e13f-4166-b564-167e3003b2fe@github.com>
Message-ID: <6WHZLyAQUDI6WBsywdVrTdNWEG382evJu0A2W9r28KY=.950a52e6-fbab-408e-8012-8811b6d863f8@github.com>

On Thu, 24 Jul 2025 11:38:44 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
>> 
>> But maybe, a bit of archeology:
>> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
>> 
>> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
>> static int sort_field_by_offset(ciField** a, ciField** b)` and
>>   ```cpp
>>   // Now sort them by offset, 
>>   // (In principle, they could mix with superclass fields.)
>>   fields->sort(sort_field_by_offset);
>>   ```
>>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
>> 
>> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second round of comments

Should I do something to also associate this PR with JDK-8357186 then? I'm thinking of `issue add`, but I mostly mean it as a process question.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1511#issuecomment-3117083900

From mchevalier at openjdk.org  Fri Jul 25 09:40:54 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 09:40:54 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v3]
In-Reply-To: <p002LGqLER6nKJZJYLWqdiI4ziTpkHNxgW8kIa3MdN4=.f5a5af30-272d-4f40-a23b-677cdbd33e44@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <e2Y5iTgbaEu8uoEMCjvonuhWIWnzr0OzenJyidxymGU=.85640548-e13f-4166-b564-167e3003b2fe@github.com>
 <p002LGqLER6nKJZJYLWqdiI4ziTpkHNxgW8kIa3MdN4=.f5a5af30-272d-4f40-a23b-677cdbd33e44@github.com>
Message-ID: <3ygXzMw2qf5vQJcnSuTtASAS3OdURWIDHMZiHAspHwg=.0a100703-f117-48f2-831f-e5f4a985931c@github.com>

On Fri, 25 Jul 2025 08:21:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Second round of comments
>
> src/hotspot/share/code/nmethod.cpp line 3846:
> 
>> 3844:       if (!did_name)
>> 3845:         stream->print("%s", type2name(t));
>> 3846:       // If the entry has a non-default sort_offset, it must be a null marker
> 
> Comment needs to be updated.

I think it can just be removed: if it's a null marker, we print that it's a null marker. I think we don't need it.

> src/hotspot/share/runtime/sharedRuntime.cpp line 2869:
> 
>> 2867:             if (bt == T_OBJECT) {
>> 2868:               // Nullable inline type argument, insert InlineTypeNode::NullMarker field right after T_METADATA delimiter
>> 2869:               // Set the sort_offset so that the field is detected as null marker by nmethod::print_nmethod_labels.
> 
> This comment needs to be updated. It still mentions the `sort_offset`.

I think we can do without the second line. The first says we include a null marker, and the second gives true to the null_marker parameter. Pretty straightforward.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230642917
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2230645885

From qamai at openjdk.org  Fri Jul 25 11:34:12 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 25 Jul 2025 11:34:12 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v4]
In-Reply-To: <Kb5Sh44Y5NxeemFrNJX0k_q6EEh5wpoZAFDtBmj0Eo8=.0ac0a424-98d7-404b-abd3-0c019670377e@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <Kb5Sh44Y5NxeemFrNJX0k_q6EEh5wpoZAFDtBmj0Eo8=.0ac0a424-98d7-404b-abd3-0c019670377e@github.com>
Message-ID: <fGgvcsLx3J5ka6u0d6oG8WrrqWwLrObidRrylUXADPI=.e2baba06-9f13-4a13-a944-d1974dc2327e@github.com>

On Fri, 25 Jul 2025 09:40:52 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
>> 
>> But maybe, a bit of archeology:
>> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
>> 
>> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
>> static int sort_field_by_offset(ciField** a, ciField** b)` and
>>   ```cpp
>>   // Now sort them by offset, 
>>   // (In principle, they could mix with superclass fields.)
>>   fields->sort(sort_field_by_offset);
>>   ```
>>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
>> 
>> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More review

I think `issue add` is appropriate. `ciInstanceKlass::get_non_flat_field_by_offset` assumes increasing offset in `_declared_nonstatic_fields`, please fix it.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1511#issuecomment-3117453076

From mchevalier at openjdk.org  Fri Jul 25 12:09:13 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 12:09:13 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v5]
In-Reply-To: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
Message-ID: <T3z_MQcnX_izxo8N13DuvdLcvEdvoh06PeswhUcyS2Y=.248d1bd3-3f63-471d-b491-c31991a38912@github.com>

> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
> 
> But maybe, a bit of archeology:
> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
> 
> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
> static int sort_field_by_offset(ciField** a, ciField** b)` and
>   ```cpp
>   // Now sort them by offset, 
>   // (In principle, they could mix with superclass fields.)
>   fields->sort(sort_field_by_offset);
>   ```
>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
> 
> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstance...

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

  Fix get_non_flat_field_by_offset

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1511/files
  - new: https://git.openjdk.org/valhalla/pull/1511/files/002fbef4..7cb1c3fc

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

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

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

From qamai at openjdk.org  Fri Jul 25 12:14:04 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 25 Jul 2025 12:14:04 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v5]
In-Reply-To: <T3z_MQcnX_izxo8N13DuvdLcvEdvoh06PeswhUcyS2Y=.248d1bd3-3f63-471d-b491-c31991a38912@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <T3z_MQcnX_izxo8N13DuvdLcvEdvoh06PeswhUcyS2Y=.248d1bd3-3f63-471d-b491-c31991a38912@github.com>
Message-ID: <XAsY3PhY_kE84MZgHK5nl2yl6GRO-cN39DCgtfrtIzM=.b52f2122-30e0-4b55-865a-8fc5835da839@github.com>

On Fri, 25 Jul 2025 12:09:13 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
>> 
>> But maybe, a bit of archeology:
>> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
>> 
>> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
>> static int sort_field_by_offset(ciField** a, ciField** b)` and
>>   ```cpp
>>   // Now sort them by offset, 
>>   // (In principle, they could mix with superclass fields.)
>>   fields->sort(sort_field_by_offset);
>>   ```
>>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
>> 
>> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix get_non_flat_field_by_offset

Marked as reviewed by qamai (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1511#pullrequestreview-3055165862

From mchevalier at openjdk.org  Fri Jul 25 12:52:05 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 12:52:05 GMT
Subject: [lworld] Integrated: 8354404: [lworld]
 compiler/startup/StartupOutput.java crashes during
 AdapterHandlerLibrary::initialize() due to too little CodeCacheSize
In-Reply-To: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
References: <BU8GmbkiupUofgBjrNEs94yjF6zlNSlEHhzTc60GbNE=.d1fc32fc-7428-4cf0-b551-4a23717b18e7@github.com>
Message-ID: <aUhBSa2-4tYSyBosDG2SARdRi68BriyyLdJGGRUV7bw=.cc36ea56-3b59-4495-a2b9-ab9509204269@github.com>

On Wed, 16 Jul 2025 14:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Experimentally, replacing 800 with 2000 is needed to have this test pass on all platform. Somehow, while 1300 seems ok on my Linux (while having a fair share of "CodeCache is full. Compiler has been disabled." messages), Windows boxes seems to struggle even with 1800. Not sure why: isn't the size of the things in the code cache (that is, the code), depends mostly on the encoding of instructions, that is dependent on architecture, not OS? Anyway, it happens reliably, so something had to be done!
> 
> Let's compare (with debug builds so I can use `CodeCacheMinimumUseSpace`, that is 1200k by default on debug builds), for various values of `ReservedCodeCacheSize` (in k), when running `-version`. For mainline:
> - [4, 28]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 3000 bytes. Error detail: `CodeCache: no room for StubRoutines` (continuation stubs)
>   ```
>   coming from
>   - `report_should_not_call(char const*, int)`
>   - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
>   - `StubRoutines::initialize_continuation_stubs()`
>   - `continuation_stubs_init()`
>   - `init_globals()`
>   
>   with `3000` being `20000` for `ReservedCodeCacheSize` between 5 and 24, and being `500` for `ReservedCodeCacheSize` = 4 (the minimum).
> 
> - [29, 32] `fatal error: Initial size of CodeCache is too small`
>   https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
>   coming from
>   - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
>   - `SharedRuntime::generate_jfr_return_lease()`
>   - `SharedRuntime::generate_jfr_stubs()`
>   - `init_globals()`
> 
> - [33, 1112]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 1108928 bytes. Error detail: CodeCache: no room for Interpreter
>   ```
>   - `...`
>   - `report_should_not_call(char const*, int)`
>   - `StubQueue::StubQueue(StubInterface*, int, Mutex*, char const*)`
>   - `TemplateInterpreter::initialize_stub()`
>   - `interpreter_init_stub()`
>   - `init_globals()`
> 
> - [1113, 1116] SIGSEGV
>   - `CodeSection::emit_int8(unsigned char)`
>   - `AbstractAssembler::emit_int8(int)`
>   - `Assembler::push(Register)`
>   - `MacroAssembler::enter()`
>   - `RegisterSaver::save_live_registers(MacroAssembler*, int, int*, bool)`
>   - `SharedRuntime::generate_resolve_blob(StubId, unsigne...

This pull request has now been integrated.

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

8354404: [lworld] compiler/startup/StartupOutput.java crashes during AdapterHandlerLibrary::initialize() due to too little CodeCacheSize

Reviewed-by: thartmann

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

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

From mchevalier at openjdk.org  Fri Jul 25 12:54:28 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 12:54:28 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v6]
In-Reply-To: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
Message-ID: <6qXJeRXm7GLdxypQMDNJwkyi1yo9rsj9sH151d6Lqv4=.755c208c-73d4-4883-8e8d-517bf6da09ab@github.com>

> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
> 
> But maybe, a bit of archeology:
> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
> 
> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
> static int sort_field_by_offset(ciField** a, ciField** b)` and
>   ```cpp
>   // Now sort them by offset, 
>   // (In principle, they could mix with superclass fields.)
>   fields->sort(sort_field_by_offset);
>   ```
>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
> 
> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstance...

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

  i

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1511/files
  - new: https://git.openjdk.org/valhalla/pull/1511/files/7cb1c3fc..f6c0a00b

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

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

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

From thartmann at openjdk.org  Fri Jul 25 12:54:29 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 25 Jul 2025 12:54:29 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v5]
In-Reply-To: <T3z_MQcnX_izxo8N13DuvdLcvEdvoh06PeswhUcyS2Y=.248d1bd3-3f63-471d-b491-c31991a38912@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <T3z_MQcnX_izxo8N13DuvdLcvEdvoh06PeswhUcyS2Y=.248d1bd3-3f63-471d-b491-c31991a38912@github.com>
Message-ID: <9yTZ5MxYtZbcrQtbx0GY73AszVIKi-o2ma3AU6Lz_EE=.f4b4dea9-35ae-408e-83e9-638ef1ba76fe@github.com>

On Fri, 25 Jul 2025 12:09:13 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
>> 
>> But maybe, a bit of archeology:
>> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
>> 
>> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
>> static int sort_field_by_offset(ciField** a, ciField** b)` and
>>   ```cpp
>>   // Now sort them by offset, 
>>   // (In principle, they could mix with superclass fields.)
>>   fields->sort(sort_field_by_offset);
>>   ```
>>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
>> 
>> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix get_non_flat_field_by_offset

> Unfortunately, I don't think this PR solves [JDK-8348547](https://bugs.openjdk.org/browse/JDK-8348547). It solves [JDK-8357186](https://bugs.openjdk.org/browse/JDK-8357186), though.

Ah, makes sense. Thanks for clarifying.

Looks good.

src/hotspot/share/runtime/sharedRuntime.cpp line 2868:

> 2866:             _sig_cc_ro->appendAll(vk->extended_sig());
> 2867:             if (bt == T_OBJECT) {
> 2868:               // Nullable inline type argument, insert InlineTypeNode::NullMarker field right after T_METADATA delimite

Suggestion:

              // Nullable inline type argument, insert InlineTypeNode::NullMarker field right after T_METADATA delimiter

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1511#pullrequestreview-3055277484
PR Review Comment: https://git.openjdk.org/valhalla/pull/1511#discussion_r2231003150

From coleenp at openjdk.org  Fri Jul 25 13:01:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Jul 2025 13:01:36 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v2]
In-Reply-To: <8m3SUe_XKAXwKXfT1ZXCk6YxbpsUySBgJVDyxGIt1Q8=.ac8f70d8-1392-4fd4-8682-cb057d3b1467@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
 <8m3SUe_XKAXwKXfT1ZXCk6YxbpsUySBgJVDyxGIt1Q8=.ac8f70d8-1392-4fd4-8682-cb057d3b1467@github.com>
Message-ID: <5Iixin4I4PYuzkCxMlWwGLTcwkaB6fSwPdcp9_x5S7A=.8fbc9ac0-bf45-423f-8878-143aaa0b2e55@github.com>

On Thu, 24 Jul 2025 17:00:47 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Add pre-registration of boxing classes when a class loader is registered by the VM.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment

This came out quite nice by reusing the similar CDS code.

src/hotspot/share/classfile/systemDictionary.cpp line 210:

> 208:                                       ClassLoaderDataGraph::find_or_create(class_loader);
> 209:   }
> 210:   if (class_loader() != nullptr && cld->dictionary() != nullptr) {

I think this can just go in the 'else' statement and then you don't have to test if the dictionary is null.   Also, rather than ADD_WRAPPER_CLASS, can you make it function that takes the whole name with vmSymbols::java_lang_<name> since I think you anticipate adding other classes to this.

To this static function, pass JavaThread* current as the first parameter, so it doesn't have to call Thread::current() for each Handle.  It's not that bad for performance anymore but I still don't like that we have it.

Maybe:

static void add_wrapper_class(JavaThread* current, Symbol* classname).

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

PR Review: https://git.openjdk.org/valhalla/pull/1517#pullrequestreview-3055310489
PR Review Comment: https://git.openjdk.org/valhalla/pull/1517#discussion_r2231024374

From mchevalier at openjdk.org  Fri Jul 25 13:05:09 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 13:05:09 GMT
Subject: [lworld] RFR: 8357785: [lworld] TestResolvedJavaType fails due to
 unexpected getInstanceFields order [v6]
In-Reply-To: <6qXJeRXm7GLdxypQMDNJwkyi1yo9rsj9sH151d6Lqv4=.755c208c-73d4-4883-8e8d-517bf6da09ab@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
 <6qXJeRXm7GLdxypQMDNJwkyi1yo9rsj9sH151d6Lqv4=.755c208c-73d4-4883-8e8d-517bf6da09ab@github.com>
Message-ID: <0ObIrR5dpmNxiwTVEdt45uNZj--13oMMDfgXYKyYePE=.78a42956-74ac-405a-8c94-2232aeb412b8@github.com>

On Fri, 25 Jul 2025 12:54:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
>> 
>> But maybe, a bit of archeology:
>> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
>> 
>> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
>> static int sort_field_by_offset(ciField** a, ciField** b)` and
>>   ```cpp
>>   // Now sort them by offset, 
>>   // (In principle, they could mix with superclass fields.)
>>   fields->sort(sort_field_by_offset);
>>   ```
>>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
>> 
>> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   i

Thanks @TobiHartmann & @merykitty

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

PR Comment: https://git.openjdk.org/valhalla/pull/1511#issuecomment-3117707786

From mchevalier at openjdk.org  Fri Jul 25 13:05:10 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 25 Jul 2025 13:05:10 GMT
Subject: [lworld] Integrated: 8357785: [lworld] TestResolvedJavaType fails due
 to unexpected getInstanceFields order
In-Reply-To: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
References: <DV3lcKO65-R7-Wm3Q7DZru5ezCrtEOhHPMALwUIdVho=.9810db7e-ec2d-4386-90c8-d9b5a286a99c@github.com>
Message-ID: <Nmi3FzVhflXRsNppju766ax4_Nw5qAY_KK6CSvuzdp0=.3606461b-5b9e-44a6-971d-bb355e366660@github.com>

On Thu, 17 Jul 2025 12:07:56 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It's all a matter of order. In short, mainline doesn't sort objects fields by offset, but just take them as they come from the stream. The order can be arbitrary, but in some places, it matters it's the same everywhere. Valhalla is sorting too much for mainline's taste, a merge caused clashes.
> 
> But maybe, a bit of archeology:
> - Mainline [JDK-8350892: [JVMCI] Align ResolvedJavaType.getInstanceFields with Class.getDeclaredFields](https://bugs.openjdk.org/browse/JDK-8350892): it removed some sorting of fields, keeping it consistent between `reassign_fields_by_klass` and `ciInstanceKlass::compute_nonstatic_fields()`: they both had fields offset-sorted, now they are both stream-sorted. Most of HotSpot agrees with this new order. This change also add a new test checking the order is consistent: `compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java`.
> 
> - Valhalla: [#1429](https://github.com/openjdk/valhalla/pull/1429) brings [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) in Valhalla. This merge is a bit mysterious to me,  how some sorting reappeared in Valhalla-untouched code. For instance, [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) removed the function `
> static int sort_field_by_offset(ciField** a, ciField** b)` and
>   ```cpp
>   // Now sort them by offset, 
>   // (In principle, they could mix with superclass fields.)
>   fields->sort(sort_field_by_offset);
>   ```
>   from `int ciInstanceKlass::compute_nonstatic_fields()` (in `ciInstanceKlass.cpp`), but the merge only removes the comment, but leave the `->sort()` and `sort_field_by_offset`. My guess is that it was a tentative fix for some failing tests after merge. Nevertheless `compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/VirtualObjectDebugInfoTest.java` is ProblemListed.
> 
> - Valhalla: After this merge, Valhalla continues to assume some ordering, as one can see in [JDK-8355076: [lworld] Incorrect declared_nonstatic_fields computation](https://bugs.openjdk.org/browse/JDK-8355076) that (among other things), makes a new occurrence of `->sort(sort_field_by_offset)`, to be consistent with `InlineKlass::collect_fields`. But now, everything is different! The new test introduced by [JDK-8350892](https://bugs.openjdk.org/browse/JDK-8350892) connects more things together, and enforce the same order in `ciInstanceKlass::compute_nonstatic_fields` and in `Class.getDeclaredFields` (reflexion related, I think. I don't know that so well). Moreover `ciInstance...

This pull request has now been integrated.

Changeset: b2e518b7
Author:    Marc Chevalier <mchevalier at openjdk.org>
Committer: Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b2e518b7cf85527b90f34ba63bf5a1b775430cd0
Stats:     285 lines in 14 files changed: 147 ins; 75 del; 63 mod

8357785: [lworld] TestResolvedJavaType fails due to unexpected getInstanceFields order
8357186: [lworld] Clean up InlineKlass::collect_fields

Reviewed-by: qamai, thartmann

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

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

From fparain at openjdk.org  Fri Jul 25 16:56:21 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 25 Jul 2025 16:56:21 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v3]
In-Reply-To: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
Message-ID: <rooTFWc_aDg_ls0FfuwcvIO5anoKj8mpsU0fsyxgnDw=.73127558-d5cf-465e-91d4-232711d3459c@github.com>

> Add pre-registration of boxing classes when a class loader is registered by the VM.

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

  Refactor code according to Coleen's comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1517/files
  - new: https://git.openjdk.org/valhalla/pull/1517/files/aad64784..090d220a

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

  Stats: 17 lines in 1 file changed: 1 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/valhalla/pull/1517.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1517/head:pull/1517

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

From fparain at openjdk.org  Fri Jul 25 17:59:25 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 25 Jul 2025 17:59:25 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v4]
In-Reply-To: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
Message-ID: <xcMI2NARm0Mtzy_WyWlseW5frj2GukKXG5jcbzbAcAY=.5ffe313f-d728-4438-9f34-a35f803796bd@github.com>

> Add pre-registration of boxing classes when a class loader is registered by the VM.

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

  Second refactoring

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1517/files
  - new: https://git.openjdk.org/valhalla/pull/1517/files/090d220a..797d8e9e

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

  Stats: 27 lines in 1 file changed: 13 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1517.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1517/head:pull/1517

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

From fparain at openjdk.org  Fri Jul 25 18:15:53 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 25 Jul 2025 18:15:53 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v5]
In-Reply-To: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
Message-ID: <fIY-swt4ulRIafhgqSyACG5jreKVcl1qK50B2nlTpig=.24ec4a93-dafa-42eb-816a-990d84aff68c@github.com>

> Add pre-registration of boxing classes when a class loader is registered by the VM.

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

  Restore multiple returns

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1517/files
  - new: https://git.openjdk.org/valhalla/pull/1517/files/797d8e9e..671136d7

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

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

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

From fparain at openjdk.org  Fri Jul 25 18:32:21 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 25 Jul 2025 18:32:21 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v6]
In-Reply-To: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
Message-ID: <qrL74FS4ST45r-OS4qvE9qDbgTCeAiDGRG2Fn_ONNVA=.ff74a475-711a-415a-b780-12525c7a7314@github.com>

> Add pre-registration of boxing classes when a class loader is registered by the VM.

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

  Remove debugging code

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1517/files
  - new: https://git.openjdk.org/valhalla/pull/1517/files/671136d7..213aed30

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

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

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

From coleenp at openjdk.org  Fri Jul 25 18:32:21 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Jul 2025 18:32:21 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v5]
In-Reply-To: <fIY-swt4ulRIafhgqSyACG5jreKVcl1qK50B2nlTpig=.24ec4a93-dafa-42eb-816a-990d84aff68c@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
 <fIY-swt4ulRIafhgqSyACG5jreKVcl1qK50B2nlTpig=.24ec4a93-dafa-42eb-816a-990d84aff68c@github.com>
Message-ID: <31a3A22VmGDnjfzqLbSS7b91KGtuXpyZSNY9bKZgQIU=.34315190-d992-4ba0-ad58-db6ed7823a57@github.com>

On Fri, 25 Jul 2025 18:15:53 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Add pre-registration of boxing classes when a class loader is registered by the VM.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore multiple returns

src/hotspot/share/classfile/systemDictionary.cpp line 1786:

> 1784:   assert(k->is_loaded(), "must be");
> 1785:   assert(k->class_loader_data() != loader_data, "only for classes defined by a parent loader");
> 1786:   if (dictionary->find_class(current, name) == nullptr) {

You could also keep the assert and have it be:
assert(!CDSConfig::is_using_aot_linked_classes() || dictionary->find_class() == nullptr, "Ioi would like this probably");

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1517#discussion_r2231771358

From coleenp at openjdk.org  Fri Jul 25 21:33:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Jul 2025 21:33:11 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v5]
In-Reply-To: <31a3A22VmGDnjfzqLbSS7b91KGtuXpyZSNY9bKZgQIU=.34315190-d992-4ba0-ad58-db6ed7823a57@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
 <fIY-swt4ulRIafhgqSyACG5jreKVcl1qK50B2nlTpig=.24ec4a93-dafa-42eb-816a-990d84aff68c@github.com>
 <31a3A22VmGDnjfzqLbSS7b91KGtuXpyZSNY9bKZgQIU=.34315190-d992-4ba0-ad58-db6ed7823a57@github.com>
Message-ID: <4LhQCvv7RybQWWxjFeIRoiluzGL-_SQwCCkCu1ljJnU=.8dae62e4-1eb2-4531-8c7e-3da90a000312@github.com>

On Fri, 25 Jul 2025 18:29:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore multiple returns
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1786:
> 
>> 1784:   assert(k->is_loaded(), "must be");
>> 1785:   assert(k->class_loader_data() != loader_data, "only for classes defined by a parent loader");
>> 1786:   if (dictionary->find_class(current, name) == nullptr) {
> 
> You could also keep the assert and have it be:
> assert(!CDSConfig::is_using_aot_linked_classes() || dictionary->find_class() == nullptr, "Ioi would like this probably");

Oh, no this assert isn't right because you add wrapper classes when using_aot_linked_classes too.  Never mind this.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1517#discussion_r2232042966

From qamai at openjdk.org  Mon Jul 28 14:52:32 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 28 Jul 2025 14:52:32 GMT
Subject: [lworld] RFR: 8364191: [lworld] Accesses to atomic flat fields prevent
 scalar replacement
Message-ID: <a9jn2hT7AhnYpWxe1mYYs9JKnq1v-Kc94DRb3D6JgQI=.c185a8f9-50f4-4f16-b9e4-b9a289301701@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.

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

Commit messages:
 - add LoadFlatNode and StoreFlatNode

Changes: https://git.openjdk.org/valhalla/pull/1518/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364191
  Stats: 955 lines in 13 files changed: 746 ins; 187 del; 22 mod
  Patch: https://git.openjdk.org/valhalla/pull/1518.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1518/head:pull/1518

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

From coleenp at openjdk.org  Mon Jul 28 16:04:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 16:04:09 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v6]
In-Reply-To: <qrL74FS4ST45r-OS4qvE9qDbgTCeAiDGRG2Fn_ONNVA=.ff74a475-711a-415a-b780-12525c7a7314@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
 <qrL74FS4ST45r-OS4qvE9qDbgTCeAiDGRG2Fn_ONNVA=.ff74a475-711a-415a-b780-12525c7a7314@github.com>
Message-ID: <PkSBuMjLgcHjIzr45dSwk4MwhcTKK6YIsR9QgMaHp8o=.80bab084-40ec-4e85-8852-c0842ec9358f@github.com>

On Fri, 25 Jul 2025 18:32:21 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Add pre-registration of boxing classes when a class loader is registered by the VM.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debugging code

This looks good.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1517#pullrequestreview-3063539572

From fparain at openjdk.org  Mon Jul 28 16:11:16 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 28 Jul 2025 16:11:16 GMT
Subject: [lworld] RFR: 8364034: [lworld] Pre-register boxing classes in
 class loaders [v6]
In-Reply-To: <qrL74FS4ST45r-OS4qvE9qDbgTCeAiDGRG2Fn_ONNVA=.ff74a475-711a-415a-b780-12525c7a7314@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
 <qrL74FS4ST45r-OS4qvE9qDbgTCeAiDGRG2Fn_ONNVA=.ff74a475-711a-415a-b780-12525c7a7314@github.com>
Message-ID: <eP8S1tVr4JkLCzMpjIEs9MZZunlIjKb-iP4-veVucxw=.3a63ab8c-d9f4-40c3-aec6-1a2ecc6bb66e@github.com>

On Fri, 25 Jul 2025 18:32:21 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Add pre-registration of boxing classes when a class loader is registered by the VM.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debugging code

Coleen,
Thank you for your review and your suggestions.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1517#issuecomment-3127945932

From fparain at openjdk.org  Mon Jul 28 16:11:16 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 28 Jul 2025 16:11:16 GMT
Subject: [lworld] Integrated: 8364034: [lworld] Pre-register boxing classes in
 class loaders
In-Reply-To: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
References: <7BN-IIoOLf_7fYtQtP9R68N96ZJILMKEpl5MCGWHvJc=.3784237d-e84f-43ba-baa6-1698d93f51e9@github.com>
Message-ID: <QxRvHO_qvzRwJxQJlqyVehh1-VSY26M4nWZzvBYywEs=.a0863bd2-f4d8-4713-91ae-b0191599fbed@github.com>

On Thu, 24 Jul 2025 16:34:50 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Add pre-registration of boxing classes when a class loader is registered by the VM.

This pull request has now been integrated.

Changeset: 57a9aef0
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/57a9aef06831357e0bc96217d81fbb642abfa6d8
Stats:     43 lines in 3 files changed: 34 ins; 3 del; 6 mod

8364034: [lworld] Pre-register boxing classes in class loaders

Reviewed-by: coleenp

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

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

From coleenp at openjdk.org  Mon Jul 28 16:15:07 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 16:15:07 GMT
Subject: [lworld] RFR: Remove ensure_objArray and copying code and write a test
Message-ID: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>

This is the diff for removing copy_flatArray_to_objArray and ensure_objArray.  This is relative to lworld but should apply cleanly to your PR Fred.  I tested it against the tier1 tests in the lworld repo (in progress).

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

Commit messages:
 - Remove ensure_objArray and copying code and write a test.

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

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

From fparain at openjdk.org  Mon Jul 28 16:15:07 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 28 Jul 2025 16:15:07 GMT
Subject: [lworld] RFR: Remove ensure_objArray and copying code and write a
 test
In-Reply-To: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
References: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
Message-ID: <YiGzQN4VgocisBHKlqATcqF2r_-VK0Lx2xVKTqp1-FE=.98bff821-e3d9-49f4-bc29-028acfe129f8@github.com>

On Thu, 10 Jul 2025 18:15:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the diff for removing copy_flatArray_to_objArray and ensure_objArray.  This is relative to lworld but should apply cleanly to your PR Fred.  I tested it against the tier1 tests in the lworld repo (in progress).

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1507#pullrequestreview-3010488532

From liach at openjdk.org  Mon Jul 28 16:15:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 16:15:08 GMT
Subject: [lworld] RFR: Remove ensure_objArray and copying code and write a
 test
In-Reply-To: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
References: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
Message-ID: <7ml48iQUMLZX9_DOVt3XTa9M7Ds3aPuHPJ7DJ02ujYs=.59e50417-5ce9-49fd-8f20-53bf06f0a817@github.com>

On Thu, 10 Jul 2025 18:15:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the diff for removing copy_flatArray_to_objArray and ensure_objArray.  This is relative to lworld but should apply cleanly to your PR Fred.  I tested it against the tier1 tests in the lworld repo (in progress).

Note these two paths are only used by `Constructor::newInstance` and `Method::invoke` if system property `-Djdk.reflect.useNativeAccessorOnly=true` is set.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1507#issuecomment-3067337040

From coleenp at openjdk.org  Mon Jul 28 16:59:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 16:59:10 GMT
Subject: [lworld] RFR: Remove ensure_objArray and copying code and write a
 test
In-Reply-To: <7ml48iQUMLZX9_DOVt3XTa9M7Ds3aPuHPJ7DJ02ujYs=.59e50417-5ce9-49fd-8f20-53bf06f0a817@github.com>
References: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
 <7ml48iQUMLZX9_DOVt3XTa9M7Ds3aPuHPJ7DJ02ujYs=.59e50417-5ce9-49fd-8f20-53bf06f0a817@github.com>
Message-ID: <CEpg2MQkZidDNEX_2lAM_DTCfRGY7x5YCV8hv9AlS3k=.4b4570f9-31c5-4c11-bc68-e3d4e58bcd3e@github.com>

On Sun, 13 Jul 2025 22:21:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> Note these two paths are only used by Constructor::newInstance and Method::invoke if system property -Djdk.reflect.useNativeAccessorOnly=true is set.

Yes, my test passes at property.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1507#issuecomment-3128147209

From liach at openjdk.org  Mon Jul 28 17:30:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 17:30:06 GMT
Subject: [lworld] RFR: Remove ensure_objArray and copying code and write a
 test
In-Reply-To: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
References: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
Message-ID: <kL8DA2xd36APi7AgtUfSr9WwxLKUsD7dhQZI0pcije4=.3646174f-18e4-485a-9b65-297b75b41ca0@github.com>

On Thu, 10 Jul 2025 18:15:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the diff for removing copy_flatArray_to_objArray and ensure_objArray.  This is relative to lworld but should apply cleanly to your PR Fred.  I tested it against the tier1 tests in the lworld repo (in progress).

Looks great

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1507#pullrequestreview-3063919311

From coleenp at openjdk.org  Mon Jul 28 20:20:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 20:20:11 GMT
Subject: [lworld] RFR: Remove ensure_objArray and copying code and write a
 test
In-Reply-To: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
References: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
Message-ID: <NQpum1kzmTcQ3BM817s9OrLVW9yufQsG2ZPm4bfqItw=.204b15a9-b56d-4801-bbc9-cce3e87e1f33@github.com>

On Thu, 10 Jul 2025 18:15:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the diff for removing copy_flatArray_to_objArray and ensure_objArray.  This is relative to lworld but should apply cleanly to your PR Fred.  I tested it against the tier1 tests in the lworld repo (in progress).

Thanks for reviewing, Fred and Chen.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1507#issuecomment-3129393769

From coleenp at openjdk.org  Mon Jul 28 20:20:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Jul 2025 20:20:12 GMT
Subject: [lworld] Integrated: Remove ensure_objArray and copying code and write
 a test
In-Reply-To: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
References: <dZ_z1r2hhSNQVYXcOkM0jVKSVCPgdyERrgRwE5B2Aik=.a2aba2e6-fd7b-40e9-847d-2d8df0ab040d@github.com>
Message-ID: <LBzqitY-CeOeK8ie7kMmvzOT8ffCZp8rBIm1WNCxqcc=.bc5768fc-b43a-4870-baef-9fc1b15b72d2@github.com>

On Thu, 10 Jul 2025 18:15:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the diff for removing copy_flatArray_to_objArray and ensure_objArray.  This is relative to lworld but should apply cleanly to your PR Fred.  I tested it against the tier1 tests in the lworld repo (in progress).

This pull request has now been integrated.

Changeset: 79618d43
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/79618d4341a688be0869e8f69af75fb1f4a0757d
Stats:     118 lines in 4 files changed: 95 ins; 21 del; 2 mod

Remove ensure_objArray and copying code and write a test

Reviewed-by: fparain, liach

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

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

From amenkov at openjdk.org  Tue Jul 29 22:26:43 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 29 Jul 2025 22:26:43 GMT
Subject: [lworld] RFR: 8364321: Add JDI tests for value objects
Message-ID: <-QMi9yYM_PcYHVfa3QKrw8VsdBJVZCztsgmX2_KXNXQ=.e7d07668-4893-4df9-9a42-c36da8a60e42@github.com>

The fix adds sanity tests for JDI classes with value objects

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

Commit messages:
 - jdi sanity tests

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

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

From amenkov at openjdk.org  Tue Jul 29 23:31:14 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 29 Jul 2025 23:31:14 GMT
Subject: [lworld] Integrated: 8364321: Add JDI tests for value objects
In-Reply-To: <-QMi9yYM_PcYHVfa3QKrw8VsdBJVZCztsgmX2_KXNXQ=.e7d07668-4893-4df9-9a42-c36da8a60e42@github.com>
References: <-QMi9yYM_PcYHVfa3QKrw8VsdBJVZCztsgmX2_KXNXQ=.e7d07668-4893-4df9-9a42-c36da8a60e42@github.com>
Message-ID: <DHdlkCcpY5y1AFupD0PNxFnFFbvllt1dCNWdrIhq2Uo=.6f96c2e3-dac2-4a4f-9b88-22dc849cf288@github.com>

On Tue, 29 Jul 2025 22:21:22 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds sanity tests for JDI classes with value objects

This pull request has now been integrated.

Changeset: 4f9deefc
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4f9deefca85788f87ca8066cfa74aaac1aaca84f
Stats:     479 lines in 3 files changed: 479 ins; 0 del; 0 mod

8364321: Add JDI tests for value objects

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

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

From cjplummer at openjdk.org  Wed Jul 30 23:29:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 30 Jul 2025 23:29:17 GMT
Subject: [lworld] RFR: 8364321: Add JDI tests for value objects
In-Reply-To: <-QMi9yYM_PcYHVfa3QKrw8VsdBJVZCztsgmX2_KXNXQ=.e7d07668-4893-4df9-9a42-c36da8a60e42@github.com>
References: <-QMi9yYM_PcYHVfa3QKrw8VsdBJVZCztsgmX2_KXNXQ=.e7d07668-4893-4df9-9a42-c36da8a60e42@github.com>
Message-ID: <2l9YsdeHmYcIxYf8y6KA_AF-BIe1fQ-pIzttFkyXgsQ=.77224a42-f8ea-4e93-b3c4-277a56f36a00@github.com>

On Tue, 29 Jul 2025 22:21:22 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds sanity tests for JDI classes with value objects

test/jdk/com/sun/jdi/valhalla/FieldWatchpointsTest.java line 62:

> 60:     }
> 61: 
> 62:     static Value staticField = new Value(1);

It would be useful to also have this test take care of testing JDI with a flattened field. You can add a Value instance field to FieldWatchpointsTarg and see if you get events when Value.v is accessed.

test/jdk/com/sun/jdi/valhalla/ValueArrayReferenceTest.java line 110:

> 108:         List<Value> values = array.getValues();
> 109:         // Mirror.toString reports object type and reference id,
> 110:         // it should be enough to see if objects are different.

This is clever. When looking at `arraysEquals()` I was going to suggest that you iterate over the two arrays and compare each array element using `==` or `ObjectReference.equals()`, but I think your comment is right and what you are doing should work just as well.

test/jdk/com/sun/jdi/valhalla/ValueArrayReferenceTest.java line 147:

> 145:         for (ArrayReference arr1: arrays) {
> 146:             for (ArrayReference arr2: arrays) {
> 147:                 if (!arraysEquals(arr1, arr2)) {

This has some duplicate checks. For example, first you compare the 1st and 2nd arrays and later you compare the 2nd and 1st arrays. An alternate approach is a single loop that compares 1st and 2nd, then 2nd and 3rd, and then 3rd and 4th.  No need to compare any of the other combinations.

test/jdk/com/sun/jdi/valhalla/ValueClassTypeTest.java line 45:

> 43: class ValueClassTypeTarg {
> 44:     static value class Value {
> 45:         static Value staticField = new Value(1);

I'm not sure how adding Value.staticField provides any useful additional testing coverage that you don't already get from testing ValueClassTypeTarg.staticField.

test/jdk/com/sun/jdi/valhalla/ValueClassTypeTest.java line 59:

> 57:     }
> 58: 
> 59:     static Value staticField = new Value(2);

Using the same field name here makes the test code below somewhat confusing. I'd suggest using different names.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1519#discussion_r2244024679
PR Review Comment: https://git.openjdk.org/valhalla/pull/1519#discussion_r2244048455
PR Review Comment: https://git.openjdk.org/valhalla/pull/1519#discussion_r2244033108
PR Review Comment: https://git.openjdk.org/valhalla/pull/1519#discussion_r2243593617
PR Review Comment: https://git.openjdk.org/valhalla/pull/1519#discussion_r2243591651

From coleenp at openjdk.org  Thu Jul 31 20:15:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 31 Jul 2025 20:15:24 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in class
 loaders
Message-ID: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>

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

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

Commit messages:
 - Preload migrated classes as if initiated in every class loader.

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

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

From coleenp at openjdk.org  Thu Jul 31 20:15:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 31 Jul 2025 20:15:24 GMT
Subject: [lworld] RFR: 8364483: [lworld] Pre-register migrated classes in
 class loaders
In-Reply-To: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
References: <mMaCSHvc3a7BFIe1U8SpDhP0elNESj4LPVqjcoSNI4U=.d2e5fc2a-0a14-499b-abce-a499d725787d@github.com>
Message-ID: <vYuHN1WwMyGWNzlqrpTFpqhcKxy7DbGznoUkQayB2RM=.e690c398-ffec-4718-9fd5-928c81e2b42c@github.com>

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

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

src/hotspot/share/gc/z/zBarrierSet.inline.hpp line 38:

> 36: #include "oops/inlineKlass.inline.hpp"
> 37: #include "utilities/debug.hpp"
> 38: #include "utilities/copy.hpp"

This is unrelated but needed to get the product build to build.

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

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