RFR: 8371637: allocateNativeInternal sometimes return incorrectly aligned memory [v2]

[Johan Sjölen]

On Thu, 13 Nov 2025 19:12:41 GMT, Harald Eilertsen <haraldei at openjdk.org> wrote:

>> `jdk.internal.foreign.SegmentFactories::allocateNativeInternal` assumes that the underlying implementation of malloc aligns allocations on 16 byte boundaries for 64 bit platforms, and 8 byte boundaries on 32 bit platforms. So for any allocation where the requested alignment is less than or equal to this default alignment it makes no adjustment.
>> 
>> However, this assumption does not hold for all allocators. Specifically jemallc, used by libc on FreeBSD will align small allocations on 8 or 4 byte boundaries, respectively. This causes allocateNativeInternal to sometimes return memory that is not properly aligned when the requested alignment is exactly 16 bytes.
>> 
>> To make sure we honour the requested alignment when it exaclty matches the quantum as defined by MAX_MALLOC_ALIGN, this patch ensures that we adjust the alignment also in this case.
>> 
>> This should make no difference for platforms where malloc allready aligns on the quantum, except for a few unnecessary trivial calculations.
>> 
>> This work was sponsored by: The FreeBSD Foundation
>
> Harald Eilertsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Second try to fix alignment for native segments
>    
>    Introducing a helper function as suggested by JornVernee to decide on
>    the proper alignment based on the segment size.
>    
>    This work was sponsored by: The FreeBSD Foundation
>    
>    Co-authored-by: JornVernee
>  - Test that native segments don't overlap
>    
>    This work was sponsored by: The FreeBSD Foundation

The VM (which the JDK interfaces with malloc through) guarantees at-most 16 byte alignment from `malloc`, so any alignment less than that is also going to be fine. We should, as always, test this, but I don't think that anything will break on the VM side with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3532178966