RFR: 8371637: allocateNativeInternal sometimes return incorrectly aligned memory

[Harald Eilertsen]

On Tue, 11 Nov 2025 16:24:23 GMT, Jorn Vernee <jvernee at openjdk.org> 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