Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8312180

(bf) MappedMemoryUtils passes incorrect arguments to msync (aix)

    XMLWordPrintable

Details

    • b12
    • aix
    • Not verified

    Backports

      Description

        While debugging a failure in TestByteBuffer.java, I noticed that msync is called on the wrong address and with a too-large length on AIX. These values come from calling force on a memory segment which passes them to the msync procedure on Unix platforms. Before passing the address and length to msync, they are modified wrt pagesize and some internal state.

        In my testing, the value returned by the Bits.pageSize() method (called internally in MappedMemoryUtils), is incorrect in the context of msync. I suspect this has to to with Dynamic Variable Page Sizes [1]. The VM is aware of the coarse-grained (eg. 64 KiB) page size, but mappings appear to operate on the fine-grained (eg. 4 KiB) page size returned by sysconf(_SC_PAGE_SIZE) and mentioned specifically in the AIX msync description [2].

        Sample values:

        - A call to force made with these values: address: 0xA00000007FB2000 index: 0 length: 0x20
        - Results in a call to force0 made with these values: address: 0xA00000007FB0000 len: 0x2020

        - sysconf(_SC_PAGE_SIZE) returns: 0x1000
        - Bits.pageSize() returns: 0x10000 (note the extra zero)

        As one might expect, when called with the wrong address and length, the msync procedure call often produces errors depending on which mapping appears at the large page boundary, and how much memory was mapped there.

        [1] https://www.ibm.com/docs/en/aix/7.2?topic=support-dynamic-variable-page-size
        [2] https://www.ibm.com/docs/en/aix/7.2?topic=m-msync-subroutine

        Attachments

          Issue Links

            Activity

              People

                tsteele Tyler Steele
                tsteele Tyler Steele
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: