On Fri, 6 Mar 2026 14:30:44 GMT, Robert Toyonaga <[email protected]> wrote:
>> Ahhh, yes you are right. Back to your original suggestion, 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. So, an incorrect NMT report is tolerable. >> IIRC, this locking issue happens more frequently on linux-aarch64. Have you >> tested on that environment? > >> 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29962#issuecomment-4044911061
