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

Thomas Stuefe stuefe at openjdk.org
Mon Feb 26 13:26:55 UTC 2024


On Mon, 26 Feb 2024 10:15:37 GMT, Joachim Kern <jkern 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.
>
>> > > > > 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_...

@JoKern65 I would look for a simpler solution as a start. Fixing up usages of os::vm_allocation_granularity() will be a slog (Kudos to you though for being willing to take it on). Can we just fix the test in places for AIX?

Note that I have never been a fan of this particular jtreg test anyway. It conflates two different things:
- A the ability of the Operating System and the JVM reservation code to allocate in low-address regions
- B whether or not we then do the right decisions wrt narrow Klass decoding setup

(A) is very dependent on the Operating System and somewhat random (ASLR).

We also have now CompressedCPUSpecificClassSpaceReservation (which tests A) and CompressedClassPointersEncodingScheme (which tests B, but is not fleshed out yet).

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

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


More information about the hotspot-runtime-dev mailing list