On Thu, 27 Mar 2025 13:51:51 GMT, Robert Toyonaga <d...@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. +1 Thanks for investigating the details of this (also nothing we couldn't change later if it bugs us). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2760736918
