On Fri, 8 May 2026 05:34:11 GMT, David Holmes <[email protected]> wrote:
>> Kevin Walls has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Attach API doc update > > src/hotspot/share/runtime/mutex.cpp line 617: > >> 615: raw_set_owner(nullptr); >> 616: _lock.unlock(); >> 617: } > > This seems more of a reset than a revive. And I see from your comments below > you refer to it as a "clear" so that would be a better name to use. If you > want to be explicit that this API is only related to the "revive" process > then maybe `clear_for_revive`? > > And if a mutex was locked at the time of the crash how can you just call > unlock from the current thread when it was not the owner? Yes, this is clearing locks specifically for a revived process, I can rename. Will make the assert a guarantee as well. > And if a mutex was locked at the time of the crash how can you just call > unlock from the current thread when it was not the owner? Yes, that is a problem, can't unlock a mutex you don't hold, hence this new method to unconditionally raw_set_owner(nullptr). The revival of memory has already revived Mutex states, and that can occasionally be a problem, e.g. crashing with heap lock held, and reviving that state. If we crash with the heap lock held, it's more useful to try and inspect the heap, than to refuse to try. 8-) But this is core file analysis after all, so we do understand that a crash happened at some random time and there is a chance things are in an inconsistent state. (If things are so inconsistent that the jcmd operation fails, it is likely that a native debugger is the tool to be using, not jcmd.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31011#discussion_r3207888128
