[lworld] RFR: 8353180: [lworld] C2: Meeting two constant TypeAryPtr with different nullness is wrongly treated as exact

[Christian Hagedorn]

On Thu, 5 Jun 2025 12:47:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> We are wrongly setting the result of the meet of two constant `TypeAryPtr` with different nullness as exact:
> https://github.com/openjdk/valhalla/blob/aacff31a86a3fc8cbc44a7e993d83c4bf9677055/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMeetingAryPtr.java#L66-L71
> 
> This causes an assertion failure during CCP to not be monotonic. This is now fixed.
> 
> There have been other occurrences where we wrongly set exactness even though nullness were different. Most of them have now been fixed with https://github.com/openjdk/valhalla/pull/1470 which corrected some of the wrong handling explicitely. 
> 
> Thanks,
> Christian

src/hotspot/share/opto/type.cpp line 4118:

> 4116:     const TypeAry* arr0 = TypeAry::make(etype, TypeInt::POS, /* stable= */ false, /* flat= */ true);
> 4117:     const bool exact = is_null_free; // Only exact if null-free because "null-free [LMyValue <: null-able [LMyValue".
> 4118:     const TypeAryPtr* arr = TypeAryPtr::make(TypePtr::BotPTR, arr0, klass, exact, Offset(0));

This was required before https://github.com/openjdk/valhalla/pull/1470 but I think the way the refactoring was done, we always set the correct exactness in `cast_to_flat_array()` which calls `make_from_klass_common()`:
https://github.com/openjdk/valhalla/blob/aacff31a86a3fc8cbc44a7e993d83c4bf9677055/src/hotspot/share/opto/graphKit.cpp#L1890-L1893

I think we should still set the exactness here correctly even though it seems we will eventually set it correctly in the caller. So, I left this fix in from my original fix before my last rebase.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1481#discussion_r2128859418