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

Quan Anh Mai qamai at openjdk.org
Tue Jul 1 08:46:57 UTC 2025


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


More information about the valhalla-dev mailing list