RFR: 8353564: Fail fatally if os::release_memory or os::uncommit_memory fails

[Thomas Stuefe]

On Thu, 22 Jan 2026 01:41:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't have an opinion on whether these methods failing are recoverable or not in general but I don't think failing to remove stack guard pages is a fatal error.

There was a prior discussion on this. https://github.com/openjdk/jdk/pull/24084#issuecomment-2752513700

The gist of it is, uncommit fails either for a parameter error (which would be a programmer error and should be asserted) or under very rare circumstances when we run out of mapping slots in the Linux VMA tree (since uncommitting a section inside a committed section would split the VMA in two and now you have more mappings). @stefank argued that in this case we are close to death anyway, even if we handle this particular error. The next malloc may already bring us over the line. So, an assert would be just practical

> And changing the API so that the callers can prepare (if necessary) and pass in an error message, does make me cringe somewhat.

Yes, I agree. I don't need those error strings. They don't really help much with error analysis, nor with recovery/prevention from the user's standpoint. If it's a programmer error, we need the hs-err file. If we hit an OS limit, it will be arbitrary where exactly it hits, so the information is not really relevant.

Much more sense would be to (in a separate PR) highlight the fact in the hs-err file that this particular native OOM may have been caused by running against the mapping limit, and that increasing said limit may help. Maybe we do this already, not sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/29240#issuecomment-3784926521