RFR: 8139457: Array bases are aligned at HeapWord granularity

[Thomas Stuefe]

On Mon, 5 Dec 2022 12:57:12 GMT, Thomas Stuefe <stuefe 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)
>
> src/hotspot/share/oops/arrayOop.hpp line 141:
> 
>> 139: 
>> 140:     const size_t max_size_bytes = align_down(SIZE_MAX - base_offset_in_bytes(type), MinObjAlignmentInBytes);
>> 141:     const size_t max_elements_per_size_t = max_size_bytes / type2aelembytes(type);
> 
> Can we add an assert for max_size_bytes % type2aelembytes(type) == 0?

Also, this is pre-existing, but I wonder why this section exists for 64-bit. Regardless of the array type, we will cap out below and return INT_MAX-2 or -3, depending on UseCCP. Why even bother calculating this? Am I missing something?

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

PR: https://git.openjdk.org/jdk/pull/11044