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

[Chen Liang]

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

>> 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.

I think runtime support is better for down the road for this part.

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

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