RFR: JDK-8322943: runtime/CompressedOops/CompressedClassPointers.java fails on AIX [v2]
Thomas Stuefe
stuefe at openjdk.org
Fri Feb 16 09:46:53 UTC 2024
On Fri, 16 Feb 2024 09:30:25 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.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17708#issuecomment-1948056846
More information about the hotspot-runtime-dev
mailing list