My colleague Almaz Mingaleev raised the following issue:

This is a follow-up from a discussion in https://github.com/openjdk/jdk/pull/28235.

Currently SegmentFactories.MAX_MALLOC_ALIGN is defined as

```
  long MAX_MALLOC_ALIGN = Unsafe.ADDRESS_SIZE == 4 ? 8 : 16;
```

https://github.com/openjdk/jdk/blob/10ba0ab3c0017858bafb65b49a4cadd9a0351fb4/src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java#L53

which is based on glibc's malloc (https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html):

```
  The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)
```

Which, in turn, is based on an older, ambiguous version of the malloc standard. Recently it was improved, please check https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm for more information.

According to the current standard (7.24.4.1):

```
  The pointer returned if the allocation succeeds is
  suitably aligned so that it can be assigned to a pointer to any type of object with a
  fundamental alignment requirement and size less than or equal to the size requested
```

Existence of https://github.com/openjdk/jdk/pull/28235 shows that implementing FFM APIs against glibc is wrong and that makes current state of SegmentFactories contradictory: MAX_MALLOC_ALIGN is based on glibc guarantees and at the same time there is a fix for malloc implementations which follow the libc standard, but not glibc.

Using `alignof(max_align_t)` would be better: 1) that's what the libc standard guarantees 2) JVM runs in non-glibc environments and 3) users can change used malloc implementation by setting LD_PRELOAD.