RFR: 8327963: C2: fix construction of memory graph around Initialize node to prevent incorrect execution if allocation is removed [v15]

[Emanuel Peter]

On Fri, 24 Oct 2025 09:12:43 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review
>>  - Roberto's patches
>
> src/hotspot/share/opto/escape.cpp line 4467:
> 
>> 4465:           return MultiNode::CONTINUE;
>> 4466:         };
>> 4467:         init->apply_to_narrow_mem_projs(i, process_narrow_proj);
> 
> Is there a reason why this is not a `init->for_each_narrow_mem_proj(callback)`, that has an internal iterator?
> 
> Because with this API, I'm wondering: What would happen if I feed `apply_to_narrow_mem_projs` an iterator that does not belong to the `init`?

If it was a plain `for_each_narrow_mem_proj`, your `callback` would also not have to return anything, you could remove this line: `return MultiNode::CONTINUE;`.

> src/hotspot/share/opto/memnode.hpp line 1424:
> 
>> 1422:   template <class Callback> ProjNode* apply_to_narrow_mem_projs(DUIterator& i, Callback callback) const {
>> 1423:     return apply_to_narrow_mem_projs_any_iterator<Callback, UsesIterator>(UsesIterator(i, this), callback);
>> 1424:   }
> 
> Do we really need to have a `public` API where we can pass in an iterator? What if someone uses it with an iterator for the wrong node?
> 
> The only use for it seems to be [ConnectionGraph::split_unique_types](https://github.com/openjdk/jdk/pull/24570/files#diff-03f7ae3cf79ff61be6e4f0590b7809a87825b073341fdbfcf36143b99c304474R4467) with `DUIterator`.
> 
> Is there a reason you want to pass the iterator explicitly?

Also: why does it return anything? What kind of callback is exected here? I think the public API deserves a bit of documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24570#discussion_r2459559137
PR Review Comment: https://git.openjdk.org/jdk/pull/24570#discussion_r2459554017