RFR: JDK-8322943: runtime/CompressedOops/CompressedClassPointers.java fails on AIX [v2]

[Thomas Stuefe]

On Thu, 15 Feb 2024 13:34:49 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> While almost all platforms allow to mount shared memory (via `mmap()` or `shmat()`) at least at __SC_PAGE_SIZE_ boundaries (4k or 64k), AIX does only allow the allocation of `shmat()` memory at 256MiB boundaries. If `shmat()` on AIX is called with a wish address not at an 256MiB boundary, it fails. `vm_allocation_granularity()` is initialized on all platforms with page_size (alias `os::vm_page_size()`). This has a value of 4K or 64K. `vm_allocation_granularity()` is used at some places to generate the rules to compute the wish address for the allocation. Of course, on AIX we get in trouble, because this often misses the 256 MiB boundary. So, I identified (hopefully) all places, where the `vm_allocation_granularity()` is used to finally generate the which address for a shared memory mount. The goal is to replace all those occurrences of `vm_allocation_granularity()` by a new function `vm_shm_allocation_granularity()` with the following properties. For all platforms except AIX `vm_sh
 m_allocation_granularity()` returns the same value as `vm_allocation_granularity()`. So, the change is a NOP for all those platforms. On AIX `vm_shm_allocation_granularity()` returns 256 MiB, when `shmat()` will be called and `os::vm_page_size()`, when `mmap()` will be called.

Okay, thank you for confirming your intent. This is as I suspected from your initial change.

First off, please rename the issue to make it obvious that this affects not just AIX. I suggest something like "Introduce os::vm_shm_allocation_granularity" or somesuch. 

But what you attempt to do already exists: this is *exactly* what `vm_allocation_granularity()` does: returning the alignment requirement for attach addresses when mapping memory using the os::reserve_... APIs.

And AIX (in shmget mode) is not the only platform with this restriction. We have that on Windows too, where we only can attach at multiples of what MS calls "Allocation Granularity" - I think 64KB. Note that the name is a misnomer, should more precisely be called "Virtual Memory Adress Attach Granuarity" since it does not affect the size of the allocation, only the attach point alignment.

The problem in hotspot is that allocation granularity is often misunderstood to be a granularity that affects the reservation size as well. So people use it (even I, accidentally) to align up allocation sizes when it really only affects allocation address alignments.

E.g. you can happily allocate a SystemV shm segment of one page (4K), but you will only be able to attach it to SHMLBA aligned addresses. Same on Windows.

For a much more detailed explanation, please see https://bugs.openjdk.org/browse/JDK-8253683 - this mis-use of allocation_granularity is a long-standing bug in hotspot.

---

Bottomline, I am against introducing yet another system value just because the one that is supposed to do that job is misused. I much rather see the misuse of allocation granularity cleaned up.

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

PR Comment: https://git.openjdk.org/jdk/pull/17708#issuecomment-1946178623