On Thu, 12 Mar 2026 08:32:26 GMT, Afshin Zafari <[email protected]> wrote:
>>> I think the address size and range in the fatal message together with >>> call-stack trace that is printed on vm_exit are enough to let the user get >>> info about the source of failure >> >> Yes, good point, I forgot that we're already printing the range in the fatal >> error message. >> >>> IIRC, this locking issue happens more frequently on linux-aarch64. Have you >>> tested on that environment? >> >> No unfortunately, I don't have my own aarch64 Linux system to test on. By >> "locking issue" are you referring to lock contention or a different issue? > > @roberttoyonaga, All tests on linux-aarch64 passed. You can now move the lock > into the NMT record_virtual_memory_release method. TIA. @afshin-zafari, that's great! Thanks for running those tests. >You can now move the lock into the NMT record_virtual_memory_release method. Okay I have done that and updated the relevant comments too. Note that **`os::unmap_memory`** calls `MemTracker::record_virtual_memory_release` too. So we must now alter `os::unmap_memory` to use the same pattern as `os::release_memory`. Doing that results in the following possible race: Thread_A: lock (A1) update NMT with release unlock (A2) pd_unmap_memory Thread_B: (B1) pd_map_memory lock (B2) update NMT with reserve + commit unlock Problematic ordering: A1, B1, B2, A2 The OS allows remapping over an existing mapping using MAP_FIXED, so B1 can happen before A2. This results in Thread_B's mapping being destroyed. This race is only possible if Thread_B specifically requests to map the same range that Thread_A is in the process of unmapping. While technically possible, in practice this never happens. `PerfMemory::detach` also uses `MemTracker::record_virtual_memory_release` but a race is not possible in this case because MAP_FIXED is not used (the OS decides the address). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29962#issuecomment-4049290414
