RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix)

Tyler Steele tsteele at openjdk.org
Tue Jul 18 15:38:16 UTC 2023


On Tue, 18 Jul 2023 02:08:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Calls to `msync` on AIX require the length to be a multiple of a specific pagesize which may not be the same as the one returned by `Bits.pageSize()`, as explained in the JBS issue description.
>> 
>>> EINVAL The addr argument is not a multiple of the page size as **returned by the sysconf subroutine using the _SC_PAGE_SIZE value for the Name parameter**, ...
>> [emphasis added by me]
>> 
>> By adding this as platform dependant code, the correct value of page size is used on AIX. Other Unix platforms should see no change by calling sysconf instead of Bits.pagesize. Windows is unchanged.
>
> src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 172:
> 
>> 170:     private static int pageSize() {
>> 171:         int ps = pageSize0();
>> 172:         if (ps > 0) {
> 
> If `sysconf(_SC_PAGESIZE)` returns a value different from `Bits::pageSize` on other Unix platforms, this could cause an unexpected change in behavior.

Agreed. However, my thinking was that on systems with only one pagesize the size returned by sysconf is still the correct size to return. There is no need to pop back to the VM and trigger another call (to Bits.pageSize).

> src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 175:
> 
>> 173:             return ps;
>> 174:         } else {
>> 175:             return Bits.pageSize();
> 
> `Bits::pageSize` returns `UnsafeConstants::PAGE_SIZE` which is injected by the VM. Could it be that that value is somehow derived differently on AIX?

I believe so. See [the answer below](https://github.com/openjdk/jdk/pull/14904#issuecomment-1640454917) with regards to Dynamic Variable Page Sizes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14904#discussion_r1266954998
PR Review Comment: https://git.openjdk.org/jdk/pull/14904#discussion_r1266956602


More information about the nio-dev mailing list