RFR: 8139457: Array bases are aligned at HeapWord granularity [v4]
Roman Kennke
rkennke at openjdk.org
Thu Dec 15 13:23:10 UTC 2022
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
More information about the hotspot-dev
mailing list