RFR: 8371637: allocateNativeInternal sometimes return incorrectly aligned memory

[Harald Eilertsen]

On Wed, 12 Nov 2025 11:27:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> From a logical point of view, what we'd need would be a couple of extra constants:
>> 
>> * `MIN_ALIGN`, this is the minimum alignment provided by the allocator/OS/platform combo
>> * `MAX_ALIGN`, this is the maximum alignment provided by the allocator/OS/platform combo
>> 
>> Then, we have three cases:
>> * if the requested alignment `A` is `A <= MIN_ALIGN`, we can just allocate and don't adjust for alignment
>> * if the requested alignment `A` is `MIN_ALIGN < A <= MAX_ALIGN` and the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
>> * otherwise, allocate a bigger segment and manually align the result
>> 
>> The problem is: how do we discover these constants?
>> 
>>> Having something like os::posix_memalign() could eliminate the problem completely, and probably simplify the code in allocateNativeInternal quite a bit.
>> 
>> Yeah, that would be nice -- but I noticed that `posix_memalign` is currently not allowed in hotspot code:
>> 
>> https://github.com/openjdk/jdk/blob/400a83da893f5fc285a175b63a266de21e93683c/src/hotspot/os/posix/forbiddenFunctions_posix.hpp#L45
>> 
>> So, allowing this would require some discussion. Also, going down this path will likely require its own `Unsafe` primitive, and intrinsics, plus potential tweaks to support NMT. So, not straightforward to pull off.
>
>> Then, we have three cases:
>> 
>>     * if the requested alignment `A` is `A <= MIN_ALIGN`, we can just allocate and don't adjust for alignment
>> 
>>     * if the requested alignment `A` is `MIN_ALIGN < A <= MAX_ALIGN` and the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
>> 
>>     * otherwise, allocate a bigger segment and manually align the result
> 
> If we can't establish a min alignment, we could at least have some way to determine the max alignment (I'd say probably 16 is a good number because of system ABI?), and then just use two rules:
> 
>  * if the requested alignment `A` is `A <= MAX_ALIGN` **and** the requested size is a multiple of the alignment, also just allocate and don't adjust for alignment
>  * otherwise, allocate a bigger segment and manually align the result
>  
>  This should still deliver the kind of compaction we were aiming for with the optimization, but hopefully get there in a more portable way?

@mcimadamore Thanks for the input! I will have to think more about this to be sure I see it clearly.

I was made aware by @bsdkurt that my original proposal here is flawed. It will work the same for platforms with a constant `MAX_MALLOC_ALIGN` of 16, but for the FreeBSD/jemalloc case, it still allocates only 8 bytes, but may cause access outside of the allocated memory. The test pass because the out of bounds accessed memory is not allocated or overwritten by somebody else.

Currently I think @JornVernee's suggestion looks the most promising. It allows for flexibility in determining the underlying architecture's alignment preferences base on the size of the allocation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28235#issuecomment-3521603834