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

[Thomas Stuefe]

On Thu, 15 Feb 2024 14:55:05 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

> Hi Thomas,
> 
> > But what you attempt to do already exists: this is exactly what vm_allocation_granularity() does:
> 
> Well, that's not really true. As I understand, on AIX, there are both alignments (4k, 256M) at the same time, depending on whether shmat or mmap is used. And both are used. Please see
> 
> https://github.com/openjdk/jdk/blob/9a1b843ff6ef72e17ec6096733408c5e265ee429/src/hotspot/os/aix/os_aix.cpp#L2169

Yes, I know. I wrote that code, remember :)

Please read https://bugs.openjdk.org/browse/JDK-8253683 for details. I described the issue and the confusion surrounding allocation granularity. I also touched on using different granularities for different memory regions. Please also read the comment from today. 

We have two ways to deal with this:

We can either implement a function that returns granularity as a function of memory region. That would work with mixed alignment requirements. However, that is really costly, invasive, complex, and really not needed because:
   - on Linux, we don't use shmget anymore. I removed that - we only allocate huge pages with mmap now, so its mmap across the board.
   - on AIX, `Use64KPagesThreshold` has always been `0` by default, since inception of 64K paged memory management in hotspot. So by default, we always were running either with mmap or with shmat underlying os::reserve_memory, we never mixed those APIs. And I find it very unlikely that customers ever used that switch. In fact, I would suggest making that switch const, or completely removing it. That would also simplify some coding.
   - on all other platforms, we don't have that problem. 

Therefore, I am for a simpler solution, which is a single value that is platform-dependent and never changes. And exactly that we have already: `os::vm_allocation_granularity()`. There is no need for a new value that means the same.

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

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