RFR: 8274794: Print all owned locks in hs_err file

[Thomas Stuefe]

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.

Thinking this through further, I think that this is may not be the best approach. 

The number of dynamically generated Mutexes can be very high, and their lifetime is unpredictable. E.g. because each ClassLoaderData is guarded by a Mutex. And we can have a lot of them (not sure if JEP 416 will do away with reflection-specific loaders, but just think of dynamic languages like jruby. Or just people who like class loaders :-).

I just ran a test with 5000 loaders and the array gets quite big, linear search is not good here. Especially since GrowableArray compacts itself on every removal.

My alternative proposal would be, as I wrote, to use a double-linked list. Removal would be O(1). And if you embed the list pointers in the Mutex itself, you don't need much more memory. Compared to your patch you'd pay 8 bytes per Mutex more because you need two pointers, but you'd save the overhead GrowableArray causes. Less allocation churn too since you save allocation of the array. And it also solves the problem of releasing memory if you release a bunch of Mutexes. With a GrowableArray, it has to shrink itself, but if you embed the list pointers in Mutex you get memory management for free.

Cheers, Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/5958