On Tue, 25 Mar 2025 20:20:55 GMT, Robert Toyonaga <d...@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
