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 My 0.02$ -- regardless of what Hotspot code might do _today_, I think it would be preferrable to make the FFM allocation code a bit more flexible (along the lines described above). Whether fully supported by the Java runtime or not, to my eyes it just seem that, at least in some configurations, the API doesn't do what it says on the tin. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3531975731
