RFR: 8356989: Unexpected null in C2 compiled code

Vladimir Kozlov kvn at openjdk.org
Fri May 23 04:35:54 UTC 2025


On Thu, 22 May 2025 09:24:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> In the test case, a non escaping array is initialized by an
>> `arraycopy` that uses this array as source and destination. Following
>> the `arraycopy`, one of the element of the array is tested for
>> `null`. That null check is constant folded to always `null` by escape
>> analysis. As I understand, the `Allocate` for the array should be
>> marked by EA as destination of an array copy. That state should then
>> be propagated by EA to uses and all destinations of an array copy
>> should be marked as unknown value. But EA has logic that explicitly
>> skips the case where an `ArrayCopy` has same source and
>> destination. Removing that logic fixes the failure.
>
> @vnkozlov you added that code with 7147744. What do you think?

Hi @rwestrel 

The comment simple said that the state of destination's fields (array elements) should be tracked by adding special (arracopy) edge when destination and source are different.  If source and destination are the same the connected edge is not needed because they were argument-escape already.

In original EA code we always set all arguments of arraycopy as argument-escape: [escape.cpp#L852](https://github.com/openjdk/jdk8u-dev/blob/e5f92a2396e9b0922c5e42dc809ad827052a9352/hotspot/src/share/vm/opto/escape.cpp#L852).

Then you optimized it [JDK-8076188](https://github.com/openjdk/jdk/commit/a9cdbd04076149927fc7c13704eb01ea32e2ca6f) by setting arguments of arraycopy to NoEscape state.  That invalidated original assumption and now we should take into account arraycopy.

Your fix looks reasonable for current code.

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

PR Comment: https://git.openjdk.org/jdk/pull/25389#issuecomment-2903218802


More information about the hotspot-compiler-dev mailing list