Integrated: JDK-8315321: [aix] os::attempt_reserve_memory_at must map at the requested address or fail

Thomas Stuefe stuefe at openjdk.org
Fri Sep 1 11:08:50 UTC 2023


On Wed, 30 Aug 2023 08:15:36 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.

This pull request has now been integrated.

Changeset: c32e340d
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c32e340d94524de018c7c72e162ae3fee4953d06
Stats:     20 lines in 2 files changed: 16 ins; 0 del; 4 mod

8315321: [aix] os::attempt_reserve_memory_at must map at the requested address or fail

Reviewed-by: mdoerr

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

PR: https://git.openjdk.org/jdk/pull/15481


More information about the hotspot-runtime-dev mailing list