JDK-8274794 : Print all owned locks in hs_err file
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-10-05
  • Updated: 2021-10-22
  • Resolved: 2021-10-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18 masterFixed
Related Reports
Relates :  
JDK-8275761 - Backout: JDK-8274794 Print all owned locks in hs_err file
Relates :  
JDK-8275162 - Replace 'def' macros in mutexLocker.cpp
Relates :  
JDK-8275800 - Redefinition leaks MethodData::_extra_data_lock
Sub Tasks
JDK-8275804 :  
[REDO] Print all owned locks in hs_err file - Closed
Description
The Thread::_owned_locks field and printing is only available in debug mode.  It would be better if it can be used to print all the owned locks in the hs_err_pid file and not just those defined in mutexLocker.cpp.

Instead have the mutex_array be populated in the Mutex constructor under a ThreadCritical lock.  There are some Mutex added after initialization in mutexLocker.cpp but the overhead of saving these is minimal.  This way all held locks will be printed in the hs_err file.
Comments
It doesn't actually make sense to embed a Mutex in a ResourceArea since they're used mostly for thread local data, so why lock? Thanks to [~eosterlund] for pointing me to the real bug. I will probably redo this change.
22-10-2021
There was a mutex embedded in metaspace that wasn't removed from the linked list by the destructor. $35 = (Mutex *) 0x7f52ba350020 $36 = (Mutex *) 0x7f53000ca400 $37 = (Mutex *) 0xf3f3f3f3f3f3f3f3 $38 = (Mutex *) 0x7f53000f2f68 $ grep -r 0xF3 memory/metaspace/blockTree.cpp: memset(p, 0xF3, word_size * sizeof(MetaWord)); This could also happen if there's a mutex embedded in a ResourceArea. I'm not going to redo this change. Thank you for backing it out last night.
22-10-2021
Unexpected mass failures in tier5 - SEGV in ~Mutex. Backing out to clean up CI.
22-10-2021
Changeset: 819d2df8 Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2021-10-21 11:28:22 +0000 URL: https://git.openjdk.java.net/jdk/commit/819d2df8b01e04bcc89a0a995e21b68799f890be
21-10-2021