RFR: JDK-8315321: [aix] os::attempt_reserve_memory_at must map at the requested address or fail [v2]
Thomas Obermeier
duke at openjdk.org
Fri Sep 1 10:06:39 UTC 2023
On Thu, 31 Aug 2023 17:33:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> There is a long-standing bug on our AIX-port that may cause `os::attempt_reserve_memory_at()` to return a different address than requested.
>>
>> All other implementations - usually just using mmap(2) - will unmap again if the attach address differs from the requested one.
>>
>> On AIX, we use either mmap or shmat, depending on some internal logic and our page size goal. If we use shmat (mostly this is the default nowadays on AIX since we need to use System V APIs for 64K pages), we may end up with an address mapped to the next lower segment boundary. Not only may this round down the requested address by SHMLBA, but it has been observed to result in a very high address if the requested address had been very low (e.g. attempting to map below 0x20_0000 gave us 0xa00_0100_a000_0000). I assume (not having the sources to the AIX kernel) that this is either the result of a wraparound while looking for the next lower segment boundary or it is a segment chosen at random.
>>
>> Whatever the reason for that behavior, the contract for `os::attempt_reserve_memory_at()` is to return either the wish address or NULL, not some other address.
>
> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>
> - fixes
> - fix
code seems reasonable to me just from viewing at it
-------------
Marked as reviewed by TOatGithub at github.com (no known OpenJDK username).
PR Review: https://git.openjdk.org/jdk/pull/15481#pullrequestreview-1606655805
More information about the hotspot-runtime-dev
mailing list