RFR: 8325870: Zap end padding bits for ArrayOops in non-release builds

[Albert Mingkun Yang]

On Thu, 15 Feb 2024 07:25:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Make `ObjArrayAllocator` zap the end padding bits in not PRODUCT builds.
> 
> Issues like [JDK-8325074](https://bugs.openjdk.org/browse/JDK-8325074) / #17863 would then reproduce deterministically. Avoid future regressions.
> 
> Guarded `Copy::fill_to_bytes`, it was not clear if or how it handles `count == 0`. Given that almost all dispatch to memset, the `count == 0` would probably be alright, but as `obj_end - padding_in_bytes` may point beyond an object and thus outside the heap it seems prudent to guard it (I believe memset requires a valid pointer).

src/hotspot/share/gc/shared/memAllocator.cpp line 427:

> 425:   const address obj_end = reinterpret_cast<address>(mem) + size_in_bytes;
> 426: 
> 427:   const size_t padding_in_bytes = size_in_bytes - base_offset_in_bytes - length_in_bytes;

Since this is unsigned subtraction, could you add a assert that `size_in_bytes` is larger or equal? (Or calculate `zap_start = obj_start + offset + length` and compare it with `obj_end`.)

src/hotspot/share/utilities/globalDefinitions.hpp line 1038:

> 1036: const int      uninitBlockPad   = 0xF1;                     // value used to zap newly malloc'd blocks.
> 1037: const juint    uninitMetaWordVal= 0xf7f7f7f7;               // value used to zap newly allocated metachunk
> 1038: const jubyte   heapPaddingByte  = 0xBD;                     // value used to zap object padding in the heap

Could it have a `Val` suffix like its neighbors?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17864#discussion_r1492474049
PR Review Comment: https://git.openjdk.org/jdk/pull/17864#discussion_r1492468279