On Wed, 26 Mar 2025 16:19:41 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> > > 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? > > I second @stefank here. > > Uncommit can fail, ironically, with an ENOMEM : if the uncommit punches a > hole into a committed region, this would cause a new new VMA on the > kernel-side. This may fail if we run against the limit for VMAs. Forgot what > it was, some sysconf setting. All of this is Linux specific, though. This happens when we hit the /proc/sys/vm/max_map_count limit, and this immediately crashes the JVM. > > I don't think this should be unconditionally a fatal error. Since the > allocator (whatever it is) can decide to re-commit the region later, and thus > "self-heal" itself. Is this referring to failures when we hit the max_map_count limit? I'm not convinced that you can recover from that without immediately hitting the same issue somewhere else in the code. Or maybe you are thinking about some of the other reasons for the uncommit to fail? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2755066544
