JDK-8257040 : [posix] os::split_reserved_memory will not work as expected on SysV shm
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8,11,16
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2020-11-25
  • Updated: 2021-01-14
  • Resolved: 2021-01-14
Related Reports
Relates :  
JDK-8257041 - [aix] os::release_memory may not release the full range
Relates :  
JDK-8256213 - Remove os::split_reserved_memory
Relates :  
JDK-8253649 - Potential bug in os::split_reserved_memory on windows
Description
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
Comments
Not an issue anymore after os::split_reserved_memory has been removed.
14-01-2021
It's mostly an AIX issue, the issue on Linux is theoretical, and the problem existed (with workarounds) for ages. I do not think a backport to 16 is necessary. I'll close this issue.
14-01-2021
[~coleenp] From jdk16 repo, I did not see it is backported. Also JDK-8256213.
14-01-2021
[~stuefe] [~minqi] Is this fixed on JDK 16 with JDK-8255917 ? os::split_reserved_memory is removed in 17.
13-01-2021