[lworld] RFR: 8351569: [lworld] Revisit atomic access modes in flat var handles [v2]

[Maurizio Cimadamore]

On Thu, 20 Mar 2025 14:06:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Enhance compareAndSetFlatValueAsBytes to work on different kinds of flat arrays
>>   Cache result of oop-free analysis
>>   Beef up tests to check different combinations of VM flags
>
> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2851:
> 
>> 2849:         Object expectedArray = ValueClass.newNullableAtomicArray(valueType, 1);
>> 2850:         Object xArray = ValueClass.newNullableAtomicArray(valueType, 1);
>> 2851:         if (arrayLayout(expectedArray.getClass()) != layout) {
> 
> This part feels a bit dirty: we are receiving a request for layout X - we need to be able to create an array with _that same layout_ -- but there's no primitive for doing that. Which means I have to try using different factories and make sure that I get something compatible (which isn't always guaranteed because of VM flags). All this guesswork should not be necessary -- that is, there should be an unsafe API to create an array with the layout I want (assuming that layout is supported of course)

I have considered avoiding the array creation -- but that is messy because it means you have to deal with nulls directly. E.g. if either `expected` or `x` are `null`, what is their corresponding numeric configuration? Going through an array element allows the code to remain agnostic as to how nulls are represented. Another way to avoid array creation would be to have some way to unsafely get the payload of a value as a long, including null channel and everything.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1402#discussion_r2005731807