RFR: 8274794: Print all owned locks in hs_err file
Thomas Stuefe
stuefe at openjdk.java.net
Fri Oct 15 06:08:47 UTC 2021
On Thu, 14 Oct 2021 20:51:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> See CR for details. This saves the created mutex in a mutex_array during Mutex construction so that all Mutex, not just the ones in mutexLocker.cpp can be printed in the hs_err file. ThreadCritical is used to protect the mutex_array, and to avoid UB should be used when printing the owned locks, but since that is done during error handling, this seemed better not to lock during error handling. There's 0 probability that another thread will be creating a lock during this error handling anyway.
> Tested with tier1-8.
Hi Coleen,
Should we limit this to debug-only, to not pay the costs for analysis we don't need?
Would it make sense to use a linked list instead? Removal would be far cheaper. Also, since every Mutex lives in this list anyway without exception, we could make the list pointers just part of the Mutex class itself, to save having to allocate a node.
I wonder whether we should, for global Mutexes, skip the destruction sequence altogether. Oh, I see the global mutexes are all new'ed, so we never delete them.
Printing on error is a bit of a problem with no perfect solution. If you print without locking, you risk crashes. But those would be caught by secondary error handling. But you don't get your full list. If you draw the lock OTOH, you may deadlock if the lock is already active, but that would be caught by the STEP timeout system too. So I think what you do is okay either way.
Cheers, Thomas
src/hotspot/share/runtime/mutex.cpp line 284:
> 282: static void remove_mutex(Mutex* var) {
> 283: ThreadCritical tc;
> 284: int i = _mutex_array->find_from_end(var);
Ouch. You count on Mutexes either living forever or being very short-lived here?
-------------
PR: https://git.openjdk.java.net/jdk/pull/5958
More information about the hotspot-dev
mailing list