On Fri, 8 May 2026 09:56:29 GMT, Kevin Walls <[email protected]> wrote:
>> 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.) I don't follow what you are saying. You are calling `_lock.unlock()` which will call `pthread_mutex_unlock` on the actual OS mutex. You can't legitimately call that unless you are the owner. And even if that call doesn't immediately break anything, if you execute code that needs to lock that mutex the actual lock attempt may just block because it was already locked. Seems to me that what you really need here is a form of the old "lock barging" for the VMThread that will turn lock/unlock into no-ops for the revived VMThread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31011#discussion_r3217263651
