RFR: JDK-8315321: [aix] os::attempt_reserve_memory_at must map at the requested address or fail
Thomas Stuefe
stuefe at openjdk.org
Wed Aug 30 08:24:33 UTC 2023
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) 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 an address at that exact address and not somewhere nearby or far away.
-------------
Commit messages:
- fix
Changes: https://git.openjdk.org/jdk/pull/15481/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15481&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8315321
Stats: 20 lines in 2 files changed: 16 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/jdk/pull/15481.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/15481/head:pull/15481
PR: https://git.openjdk.org/jdk/pull/15481
More information about the hotspot-runtime-dev
mailing list