On Tue, 11 Nov 2025 16:24:23 GMT, Jorn Vernee <[email protected]> wrote:
> Thanks, I think I get it. What happens if you try to allocate 4 bytes of > memory and request 8 byte alignment? Won't the result only be 4 byte aligned? No, it will still be 8 byte aligned. See the implementation notes in [the jemalloc man page](https://man.freebsd.org/cgi/man.cgi?query=malloc): > Allocation requests that are no more than half the quantum (8 or 16, > depending on architecture) are rounded up to the nearest power of two that is > at least sizeof(double). All other object size classes are multiples of the > quantum, (,,,) > I think the assumption of the current optimization is wrong: that malloc > always returns memory aligned to a _constant_ `MAX_MALLOC_ALIGN`, and instead > it depends on the size of the allocation, and the underlying allocator. Yes, that is the root of the problem. > I think ideally we'd be able to ask the allocator what the alignment of the > memory it will return of a certain size is (or ask it to do an aligned > allocation). Having something like `os::posix_memalign()` could eliminate the problem completely, and probably simplify the code in `allocateNativeInternal` quite a bit. > We could also use a helper method that returns the alignment for a certain > allocation size: > > ``` > private static final boolean IS_FREEBSD = > System.getProperty("os.name").equals(...); > > private long alignmentForSize(long size) { > if (IS_FREEBSD) { > ... > } else { > return Unsafe.ADDRESS_SIZE == 4 ? 8 : 16; > } > } > ``` Yeah, this would definitely make the code clearer! I spent quite some time trying to understand where this assumption around `MAX_MALLOC_ALIGN` came from :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3518105587
