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

[Joachim Kern]

On Fri, 23 Feb 2024 17:15:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > > > We don't use it, because mmap cannot be used with 64K pages. Or can it? We wrote the code originally 20 (?) years ago when the only way to get 64K pages was via shmget. Maybe that changed. It would be good if someone could check if this is still the case. Because using shmget instead of mmap causes a long tail of follow-up problems. mmap is so much easier.
> > > > 
> > > > 
> > > > I wrote a little test programm
> > > > ```
> > > >     int page_sz = sysconf (_SC_PAGE_SIZE);
> > > >     printf("page size for mmap: %d.\n", page_sz);  --> Output: 4096
> > > > 
> > > >     void* addr_mmap = mmap(NULL, 100000000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
> > > > 	struct vm_page_info pi;
> > > >     pi.addr = (uint64_t)addr_mmap;
> > > >     if (vmgetinfo(&pi, VM_PAGE_INFO, sizeof(pi)) == 0) {
> > > >       printf("real page size for mmap: %llu.\n", pi.pagesize);  --> Output: 4096
> > > >     } else {
> > > >       printf("no pagesize available.\n");
> > > >     }
> > > >     munmap(addr_mmap, 100000000);
> > > > ```
> > > > 
> > > > 
> > > >     
> > > >       
> > > >     
> > > > 
> > > >       
> > > >     
> > > > 
> > > >     
> > > >   
> > > > and ran this little program with envvar LDR_CNTRL=DATAPSIZE=64K at TEXTPSIZE=64K at STACKPSIZE=64K at SHMPSIZE=64K
> > > > Is this sufficient to prove that mmap is still only using 4K?
> > > 
> > > 
> > > No clue. Maybe there is a different way. Some fancy madvise option? Ask IBM?
> > > Astonishing that they have not yet provided large page support for mmap after 20 years.
> > 
> > 
> > I asked IBM. 64K Pages for mmap are available with AIX 7.3. I proved this. Unfortunately our current minimum release is AIX 7.2.5.7
> 
> Does that current minimum release need 64K pages? How many customers are that?
> 
> Remember, you still can use the JVM with 4K pages (-XX:-Use64KPages). Its not that the VM is unusable then.

Currently we have zero customers using SapMachine21, but a new product which customers are forced to install on all their APP-Servers will come soon. And this new product is based on SapMachine21. And it is already announced to SAP customers using AIX APP-servers that the minimum OS release for this product will be AIX 7.2.5
I do not want to bother them with performance reduction due to going back to 4K pages solely.

So, I would like to go the following way as sketched above: Going through the code and checking the right usage of  os::vm_allocation_granularity() and replacing it by os::vm_page_size() if the usage is not the granularity of the allocation address.

@tstuefe : Should I close this PR and open a new one for the new approach, or is it better to revert my previous changes and start again keeping this PR?

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

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