On Thu, 13 Nov 2025 19:12:41 GMT, Harald Eilertsen <[email protected]> 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 > 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. For what it's worth, I think the described behavior is non-conforming to the C standards before C23. Before C23, the description of the allocation functions all say "The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated ... " (That's from C11 7.22.3/1. C99 and C17 have the same wording. I can't find my copy of C89 right now, but expect it's pretty much the same.) DR75 reiterated that the malloc result must be suitably aligned for _any_ (emphasis in the DR) type. https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_075.html A consequence of the pre-C23 behavior is that max_align_t* p = malloc(1); is always valid. C23 permits that to be UB. (You aren't allowed to create misaligned pointers.) C23 added the phrase "and size less than or equal to the size requested" after "fundamental alignment requirement". I think that's sufficient to permit the described behavior. But we're not using C23 (yet), we're using C11. I would not be surprised if HotSpot also has code that assumes the result from malloc and friends is always aligned to at least max_align_t's alignment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3529751947
