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