RFR: 8341491: Reserve and commit memory operations should be protected by NMT lock

[Robert Toyonaga]

On Wed, 26 Mar 2025 20:18:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > > > > I don't understand why we don't treat that as a fatal error OR make sure that all call-sites handles that error, which they don't do today.
> > > > 
> > > > 
> > > > I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> > > 
> > > 
> > > I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?
> > 
> > 
> > [`VirtualSpace::shrink_by`](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/memory/virtualspace.cpp#L373) allows uncommit to fail without crashing. I'm not certain of the intention behind that. But it seems like it's because shrinking is an optimization and not always critical that it be done immediately. [[1](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/gc/serial/tenuredGeneration.cpp#L258)]
> 
> The above example shows code that assumes that it is OK to fail uncommitting and continuing. I'm trying to figure it that assumption is true. So, what I meant was that I was looking for a concrete example of a failure mode of uncommit that would be an acceptable (safe) failure to continue executing from. That is, a valid failure that don't mess up the memory in an unpredictable/unknowable way.

So release/uncommit (via mmap,munmap, VirtualFree) could fail due to: ① Bad arguments, or ② The OS encountered an issue out of control of the JVM.

① JVM bug. Reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently. 

②  The only errors that aren't due to bad arugments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit).  VirtualFree only fails due to bad arguments according to windows docs. 

So if there's consensus that ENOMEM is not recoverable (or rare enough to not worry about), then it seems like its OK to fatally fail in all scenarios.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2758139261