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

[Roman Kennke]

On Wed, 15 Feb 2023 13:34:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify comment on arrayOopDesc::max_array_length()
>
> src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp line 166:
> 
>> 164: void C1_MacroAssembler::allocate_array(Register obj, Register len,
>> 165:                                        Register tmp1, Register tmp2, Register tmp3,
>> 166:                                        int header_size_in_bytes, int element_size,
> 
> Other platforms call this parameter base_offset_in_bytes. I looked at the code below, but couldn't convince myself that the MinOjbAlignmentInBytesMask usages were correct. Maybe they are because this is 32-bit code, but could be worth taking a closer look.

The use of MinObjAlignmentInBytes(Mask) below is not correct, afaict. It aligns-up the object size if either the header/base-offset is not aligned at 8 or if the element-size is not aligned at 8. I can kinda understand to align-up if the header-size is not 8-bytes-aligned (although, with this change this should only be needed for long or double element types), but what is the point of aligning-up the object size for, e.g., int[] or byte[]? I am not even sure why this currently works, as far as I can tell, this would tend to over-allocate arrays, and this should throw off size calculations. *scratches head*.
I any case, the fact that we are having this discussion and can't even figure out what is going on indicates that this is some seriously nasty code that should be rewritten to be more reasonable and understandable. Unfortunately I don't have access to arm hardware, and I wouldn't want to do it blindly. IIRC, @shipilev made the changes for this PR and verified that it does at least work well-enough to pass some sanity testing. I would suggest that either somebody (@shipilev?) could check this soon, or I file a follow-up bug to address this ASAP.

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

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