RFR: 8139457: Array bases are aligned at HeapWord granularity [v61]

[Paul Sandoz]

On Tue, 24 Oct 2023 10:35:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> See [JDK-8139457](https://bugs.openjdk.org/browse/JDK-8139457) for details.
>> 
>> Basically, when running with -XX:-UseCompressedClassPointers, arrays will have a gap between the length field and the first array element, because array elements will only start at word-aligned offsets. This is not necessary for smaller-than-word elements.
>> 
>> Also, while it is not very important now, it will become very important with Lilliput, which eliminates the Klass field and would always put the length field at offset 8, and leave a gap between offset 12 and 16.
>> 
>> Testing:
>>  - [x] runtime/FieldLayout/ArrayBaseOffsets.java (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] bootcycle (x86_64, x86_32, aarch64, arm, riscv, s390)
>>  - [x] tier1 (x86_64, x86_32, aarch64, riscv)
>>  - [x] tier2 (x86_64, aarch64, riscv)
>>  - [x] tier3 (x86_64, riscv)
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8139457
>  - Fix ARM build
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Various cleanups
>  - RISC changes
>  - Move gap init into allocate_header() (x86)
>  - Fix gtest failure on x86
>  - Merge remote-tracking branch 'upstream/master' into JDK-8139457
>  - Fix comments
>  - Fix inconsistencies in argument naming C1_MacroAssembler::allocate_array()
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/9bfa0829...7eaca124

You are correct that the access methods function correctly (and with a tweak so can the align* methods when Lilliput is enabled). However, the change in object array layout can result in exceptions that previously would never occur and that could break existing code.

The likelihood is the four methods referenced above are used for exotic atomic access, since plain accesses are already supported using direct array access or using methods on buffer. It's hard to know what percentages of those exotic accesses operate on `byte[]` and further will break when Lilliput is enabled. 

So out of an abundance of caution I suggested we deprecate (not for removal), on the presumption that existing code can keep running if Lilliput is disabled or object/array alignment is explicitly configured (via a VM flag). Unfortunately the deprecation signal is wider than we would like, since the methods function correctly for direct buffers (and for plain accesses, although i think that is less important). However, I argue it gives an opportunity to explain the situation and to point to better alternatives in a way that is much more visible than `@see` and release notes (which i think we should do even if we don't use the deprecate signal).

Jorn, you proposal to uniformly reject for `unitSize > 1` for methods `alignedSlice` and `alignmentOffset` gives no workaround for the user whose code is now broken. It's hard to assess the impact. In these known unknown cases i often err on the side of caution. One approach we could take is to uniformly reject only when Lilliput is enabled.

I suggest to follow up on JVMCI as a separate issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/11044#issuecomment-1777714766