RFR: 8304824: NMT should not use ThreadCritical [v3]

[Thomas Stuefe]

On Fri, 13 Sep 2024 16:12:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > After switching to a Hotspot Mutex, it looks like the `windows-x64 / test (hs/tier1 common) GHA` is failing because the test `release_bad_ranges` in test_os.cpp is expecting an assertion and an error message to be printed. However, when this printing happens, `tty_lock` gets acquired out of rank order with the already held `NMT_lock`, causing the lock rank assertion fail. One solution would be to lower the rank of `tty_lock`. I'm not sure that's the best solution because that might cause rank conflicts with other locks (and it makes sense to give locks the highest possible rank to minimize future conflicts).
> 
> What code exactly locks tty_lock?

This is weird. We print the error in this case via print_error_for_unit_test(), which takes care only to use raw fprintf(stderr) for this very reason... therefore I am interested in understanding the lock semantics, to know if deadlock detection found a real problem or if this is just a weird error setup.

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

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2349320770