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

[Roman Kennke]

On Wed, 13 Sep 2023 12:58:36 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's gtest a failure in the GHA run:
> 
> ```
>  [ RUN      ] arrayOopDesc.double_vm
> /home/runner/work/jdk/jdk/test/hotspot/gtest/oops/test_arrayOop.cpp:51: Failure
> check_max_length_overflow(T_DOUBLE) evaluates to false, where
> T_DOUBLE evaluates to �
> 
> [  FAILED  ] arrayOopDesc.double_vm (0 ms)
> [ RUN      ] arrayOopDesc.byte_vm
> [       OK ] arrayOopDesc.byte_vm (0 ms)
> [ RUN      ] arrayOopDesc.short_vm
> [       OK ] arrayOopDesc.short_vm (0 ms)
> [ RUN      ] arrayOopDesc.int_vm
> [       OK ] arrayOopDesc.int_vm (0 ms)
> [ RUN      ] arrayOopDesc.long_vm
> /home/runner/work/jdk/jdk/test/hotspot/gtest/oops/test_arrayOop.cpp:67: Failure
> check_max_length_overflow(T_LONG) evaluates to false, where
> T_LONG evaluates to �
> 
> [  FAILED  ] arrayOopDesc.long_vm (0 ms)
> ```

Aww, this max_array_length() method and 32bit builds. :-/
We should re-write this method altogether and special-case it for !_LP64 and maybe simply make it a switch on the incoming type, with hard-coded values. This might be easier to understand than getting the logic absolutely right. Also, with this change, and even more so with upcoming Lilliput changes, this method is a little too conservative and we could offer somewhat increased array lengths. Alternatively, we could do what the comments suggests and fix up all the uses of the method to use sensible types (size_t?) and make it simple and obvious.

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

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