On Wed, 12 Nov 2025 11:27:06 GMT, Maurizio Cimadamore <[email protected]> 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
