On Fri, 12 Dec 2025 15:37:37 GMT, Frederic Parain <[email protected]> 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

Reply via email to