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

[Roman Kennke]

On Thu, 19 Jan 2023 10:48:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into JDK-8139457
>>  - Fix gtest for correct base offsets in 32bit builds
>>  - Fix cast warning
>>  - Revert relaxation of array length
>>  - Add guards to ArrayBaseOffsets test to allow running with -UseCompressedClassPointers
>>  - Fix another cast warning
>>  - Clean cast warning from size_t to int
>>  - Clear leading 32bits in Z array allocator
>>  - SA adjustments
>>  - Test for 32bit build
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/500b45e1...c278a53b
>
> src/hotspot/share/gc/shared/memAllocator.cpp line 427:
> 
>> 425:   }
>> 426:   ArrayKlass* array_klass = ArrayKlass::cast(_klass);
>> 427:   const size_t hs = heap_word_size(arrayOopDesc::base_offset_in_bytes(array_klass->element_type()));
> 
> I don't think this makes sense. If base_offset_in_bytes return something that isn't word aligned, then `heap_word_size` will truncate the value and `hs` will less than the actual header size. This then snowballs back to the caller of `obj_memory_range`. Maybe we need change obj_memory_range to work with bytes instead of words?

I think that heap_word_size() aligns up:
inline size_t heap_word_size(size_t byte_size) {
  return (byte_size + (HeapWordSize-1)) >> LogHeapWordSize;
}
which makes obj_memory_range() ok as it is? I agree that it is not great, but it seems to be used only by check_for_bad_heap_word_value(), and for that purpose it is ok? Not 100% sure.

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

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