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

[Roman Kennke]

On Wed, 7 Dec 2022 08:04:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test for 32bit build
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 435:
> 
>> 433: 
>> 434: void CollectedHeap::zap_filler_array_with(HeapWord* start, size_t words, juint value) {
>> 435:   int payload_start = align_up(arrayOopDesc::base_offset_in_bytes(T_INT), HeapWordSize) / HeapWordSize;
> 
> I see this in a number of places in the patch. Could you explain why this is correct? If base offset is not HeapWordSize aligned, then it looks like payload_start * HeapWordSize would be larger than the base offset.

Good catch! I modified this section so that it explicitely zaps the leading unaligned element. I checked other similar patterns in the code, they do look correct, but I modified them to use heap_word_size() instead for clarity.

> src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 55:
> 
>> 53:   const size_t header = arrayOopDesc::base_offset_in_bytes(element_type);
>> 54:   size_t byte_size = _word_size * BytesPerWord;
>> 55:   const size_t payload_size = byte_size - header;
> 
> Generational ZGC needs it to be able to write colored NULLs in object arrays, so a byte-centric approach will not work for us. Could you rewrite the code to take care of the "unaligned" 32 bits at the start of the array, and leave the word-centric segmented-clearing loop intact?

Right. I restored the previous code and align-up the base offset. Object arrays in ZGC would not use the leading unaligned 32bits anyway, afaik.

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

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