On Sun, 16 Nov 2025 18:09:47 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 one > additional commit since the last revision: > > Fix calculation of allocationSize when byteAlignment < MAX_MALLOC_ALIGN > > This work was sponsored by: The FreeBSD Foundation > I believe this is the most concise way to support weak alignment allocators: > [bsdkurt@bb45e82](https://github.com/bsdkurt/jdk/commit/bb45e82a8772e50e321f07af37470fc4360b0adf) I think so too, I've updated the PR with the change now. Let's see if the tests agree. Both FreeBSD and Linux seemed happy on my local setup at least. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3552042604
