RFR: JDK-8316756: C2 EA fails with "missing memory path" when encountering unsafe_arraycopy stub call [v3]

[Christian Hagedorn]

On Mon, 15 Jan 2024 11:58:57 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> Before https://github.com/openjdk/jdk/pull/5259 the graph of the following program looked like this during Escape Analysis:
>> 
>> 
>> static int test() {
>>     MyClass obj = new MyClass(); // Non-escaping to trigger Escape Analysis
>>     UNSAFE.copyMemory(null, SRC_BASE, null, DST_BASE, 4);
>>     obj.x = 42;
>>     return obj.x;
>> }
>> 
>> With MemBarCPUOrder:
>> <img width="395" alt="working" src="https://github.com/openjdk/jdk/assets/71546117/63a82554-49ff-4373-8567-4457b094093f">
>> 
>> Setting `RC_NARROW_MEM` flag in `LibraryCallKit::inline_unsafe_copyMemory()` removes the `428 MergeMem` node. Without a `MergeMem` node after `432 StoreB` EA failes in Phase 2 of `ConnectionGraph::split_unique_types(...)` when trying to push the allocation's users on the appropriate worklist - `429 CallLeafNoFP` is not an expected user of `428 StoreB`. Therefore the assert `"EA: missing memory path"` is hit. 
>> Without MemBarCPUOrdera and after setting `RC_NARROW_MEM`:
>> <img width="370" alt="failing" src="https://github.com/openjdk/jdk/assets/71546117/5d98c38c-d404-4ac4-bd11-bc1e1b7b481f">
>> 
>> 
>> ### Proposed Fix
>> Dropping the `RC_NARROW_MEM` flag in `LibraryCallKit::inline_unsafe_copyMemory()` causes the introduction of a `MergeMem` between `StoreB` and `CallLeafNoFP`, so the corresponding code in EA doesn't encounter a `CallLeafNoFP` anymore:
>> <img width="336" alt="fixed" src="https://github.com/openjdk/jdk/assets/71546117/c538c199-6676-49a4-aaac-a2b3b8f11694">
>> 
>> Testing: Tier1-4 passed
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added testcase

src/hotspot/share/opto/escape.cpp line 4010:

> 4008:       }
> 4009:     } else if (n->is_CallLeaf()) {
> 4010:       // Runtime calls with narrow memory input (no MergeMem node)

Could we somehow assert here that we have a call with an intended narrow memory input? Directly asserting that this is an unsafe arraycopy might be too specific. But maybe we can add the following sanity check?

n->as_CallLeaf()->adr_type()->is_rawptr()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17347#discussion_r1453306060