RFR: 8364235: Fix for JDK-8361447 breaks the alignment requirements for GuardedMemory [v5]

[David Holmes]

On Sun, 3 Aug 2025 22:54:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The fix for [JDK-8361447](https://bugs.openjdk.org/browse/JDK-8361447) added a new field to the `GuardHeader`, not realizing that the size of the `GuardHeader` must be such that the address of the user-data has the strictest necessary alignment (16-byte).
>> 
>> We need to add a padding field to restore the alignment.
>> 
>> A static assert is added to check the alignment.
>> 
>> Testing:
>>  - tiers 1-3 (in progress)
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "padding" to the layout description

@kimbarrett and I discussed this further at some length after I flagged the `max_align_t` issue. On further analysis, considering in particular 32-bit systems, there is no guarantee that we actually get a properly aligned based address with `alignas(16)` when we are malloc'ing ourselves, as the "new alignment" may only be 8-bytes not 16-bytes. To deal with that Kim suggested revising the the `GuardedMemory` calculations so that we use `align_up(size, 16)` ensure the user-data will actually placed on a 16-byte boundary, regardless of the initial placement of the `GuardHeader` or its size. I am working on that revision.

I also want to investigate a potential regression test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26524#issuecomment-3149161654