RFR: 8371637: allocateNativeInternal sometimes return incorrectly aligned memory [v2]

[Kim Barrett]

On Fri, 14 Nov 2025 14:45:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > For what it's worth, I think the described behavior is non-conforming to the C standards before C23
> 
> The standard was ambiguous prior to that and https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm is a good read on that topic.

Thanks for the reference to that paper; that's part of what I was looking for.
Having read it carefully, I have a number of points of disagreement with it.
But that doesn't matter, because, as Harald Eilertsen said

> it's nevertheless the behaviour of the allocator used by libc on FreeBSD.

So we have to cope with that behavior.

One thing I found surprising in n2293 is that Windows CRT is classified as a
weak-alignment environment. So why haven't we previously run into this same
problem on Windows? Is that categorization mistaken? Or perhaps we *have* run
into this, and there is some Windows-specific workaround lurking somewhere? In
which case perhaps that is no longer needed if we're going to allow for
weak-alignment allocators.

If Windows is a weak-alignment environment, that would also suggest we don't
have a dependency on strong-alignment in HotSpot, else we'd expect to have run
into problems there too. That would be good, because I was really not looking
forward to searching for such dependencies.

So can anyone verify the Windows categorization? I don't have easy access.

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

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