[lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr and TypeAryKlassPtr [v6]

[Quan Anh Mai]

On Fri, 12 Dec 2025 15:37:37 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> @fparain Thanks for your review, This is not about choosing a layout, however, it is about choosing a refined class for the array that is created by `ValueClass::newNullRestrictedNonAtomicArray`. If we go with your suggestion, then the array created by this method will have a different refined type from an array created by `ValueClass::newNullRestrictedAtomicArray`, which seems dangerous because C2 may try to assume that 2 classes having the same properties should be equal. As a result, I went with this change which asserts at `ObjArrayKlass::allocate_klass_with_properties` that non-atomic is only requested when it is possible to do so, and changed the call sites that may have this property popping up. The common point of those 2 sites is `ObjArrayKlass::klass_with_properties`, so I think it is less clear whether we should normalize the properties argument there instead. What do you think?
>
> It has never been guaranteed, nor been a goal, to have `ValueClass::newNullRestrictedNonAtomicArray` and `ValueClass::newNullRestrictedAtomicArray` to return the same refined array class. The two factories aims are creating arrays with two different sets of properties. Depending on the characteristics of the element's class, they could have the same layout or not, but they are not the same "refinement".
> Looking past JEP 401, it is likely that non-atomic flat arrays will have to consider the length of the array in the layout selection process (because of limitation on indexing inside humongous arrays), so it is possible that for a given element type and a set of nullness/atomicity properties, several refinements would exist.

@fparain Thanks a lot for your explanation, I have made the change as you suggested.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2614818066