RFR: 8373591: C2: Fix the memory around some intrinsics nodes [v5]

[Dean Long]

On Wed, 7 Jan 2026 09:42:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is extracted from #28570 , there are 2 issues here:
>> 
>> - Some intrinsics nodes advertise incorrect `adr_type`. For example, `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too. Another case is `VectorizedHashCodeNode`, which reports its `adr_type` being `TypePtr::BOTTOM`, but it actually extracts a memory slice and does not consume the whole memory.
>> - For nodes such as `StrInflatedCopyNode`, as they consume more than they produce, during scheduling, we need to compute anti-dependencies. This is not the case, so we should fix it by making the nodes kill all the memory they consume. This issue is often not present because these intrinsics are not exposed bare to general usage.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into intrinsicsadrtype
>  - copyright year
>  - Merge branch 'master' into intrinsicsadrtype
>  - consolidate the memory effect into a function
>  - Use MemBar instead of widening the intrinsic memory
>  - Fix Shenandoah
>  - Fix memory around intrinsics nodes

So after looking at this PR I have learned that C2 can control reordering of memory operations in at least 3 ways: anti-dependencies, memory slices, or membars.  Are there are rules-of-thumb on which is best to use?  Using a membar seems the most conservative but probably allows fewer optimizations.

By the way, I see that LibraryCallKit::inline_encodeISOArray and corresponding Java method do pretty much the same things a compress.  So I tried adding a test for it in TestAntiDependency.java.  But to my surprise, it passes, even without the fixes in this PR.  I would expect it to fail, because the existing code uses TypeAryPtr::BYTES, so how does it prevent the movement of a char[] store in the test?

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

PR Comment: https://git.openjdk.org/jdk/pull/28789#issuecomment-3821336640