On Fri, 28 Mar 2025 09:44:00 GMT, Thomas Stuefe <stu...@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). +1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2766054807
