On Posix, os::spit_reserved_memory() does assume that the underlying range had been allocated with mmap and follows mmap semantics (mainly, that it can be munmapped page-wise).
Therefore it does not a split at all, but does a "shallow split", where it just adjusts the info in NMT and thats it.
If the underlying memory had been reserved with System V shm, this will fail, since it follows the same semantics as Windows VirtualAlloc. The mapping will still be a combined one, and releasing the first part of the split will release the whole mapping.
We use System V shm in two places:
- on Linux, when we work with large pages and UseSHM
- on AIX, where we use System V shared memory for almost everything to get 64K pages
Therefore it does not a split at all, but does a "shallow split", where it just adjusts the info in NMT and thats it.
If the underlying memory had been reserved with System V shm, this will fail, since it follows the same semantics as Windows VirtualAlloc. The mapping will still be a combined one, and releasing the first part of the split will release the whole mapping.
We use System V shm in two places:
- on Linux, when we work with large pages and UseSHM
- on AIX, where we use System V shared memory for almost everything to get 64K pages
- relates to
-
JDK-8257041 [aix] os::release_memory may not release the full range
-
- Closed
-
-
-
- Closed
-
-
JDK-8256213 Remove os::split_reserved_memory
-
- Resolved
-