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

[Stefan Karlsson]

On Tue, 25 Mar 2025 20:20:55 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> > ... swapping the order of the release and NMT release booking as a way to shrink the lock scope for the release operation:
> > ...
> > As long as we hold the reservation, no other thread can re-reserve the reservation, so Thread B can take its time to first perform the NMT release booking under the lock, and then perform the release without the lock.
> 
> Hi @stefank, I think that's true. But if the release/uncommit does not complete successfully we would need to readjust the accounting afterward. To do that we would need to retrieve the original memtag (at least for reserved regions) and potentially need to retrieve the original callsite data (if we're in detailed mode).

When does a release/uncommit fail? Would that be a JVM bug? What state is the memory in when such a failure happens? Do we even know if the memory is still committed if an uncommit fails?

If I look at the man page for munmap it only fails if you pass in incorrect values, which sounds like a JVM bug to me. 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.

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

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