RFR: 8331539: [REDO] NMT: add/make a mandatory MEMFLAGS argument to family of os::reserve/commit/uncommit memory API [v2]

[Thomas Stuefe]

On Fri, 24 May 2024 13:55:58 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > 1. NMT assumes reserves and commits to be different layers and, e.g., for committed regions to be fully contained in a reserved region. This is wrong and does not reflect the realities of mmap. We can overlay and overlap any reservation/committing/uncommitting/releasing in any way we want.
> 
> On Windows, a commit without reserve is not allowed. ([reference](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc#:~:text=MEM_COMMIT%20%7C%20MEM_RESERVE.-,Attempting%20to%20commit%20a%20specific%20address%20range%20by%20specifying%20MEM_COMMIT%20without%20MEM_RESERVE%20and%20a%20non%2DNULL%20lpAddress%20fails%20unless%20the%20entire%20range%20has%20already%20been%20reserved.%20The%20resulting%20error%20code%20is%20ERROR_INVALID_ADDRESS.,-An%20attempt%20to))

Sorry, but why does NMT have to enforce that? NMT should allow what the most flexible of OSes allows.

On mmap on Posix is a lot more flexible than VirtualAlloc on Windows. We want to be able to use the APIs that the OS gives us to the fullest. 

If the OS allows us to reserve a memory range with a single system call, then to treat that range as disjunct entities that I can commit/release independently from another, the JVM should be able to do just that without having to worry about NMT. NMT should cope with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/19343#issuecomment-2130872202