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

Thomas Stuefe stuefe at openjdk.org
Wed Mar 26 16:23:08 UTC 2025


On Wed, 26 Mar 2025 16:05:00 GMT, Stefan Karlsson <stefank at 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.

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.

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

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


More information about the hotspot-dev mailing list