RFR: 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing

[Stefan Karlsson]

This is an alternative version of the fix proposed in 900:
https://github.com/openjdk/jdk/pull/900

Erik's description:
> Today, when you crash, the GCLogPrecious::_lock is taken. This effectively limits you to only get clean crash reports if you crash or assert without holding a lock of rank tty or lower. It is arguably difficult to know what locks you are going to have when crashing. Therefore, I don't think the precious GC log should constrain possible crashing contexts in that fashion.

As Erik mentioned in that PR, I'd like to retain the ability to easily dump the precious log when debugging. The proposed fix changes the Mutex to a Semaphore, and use trywait to safely access the buffer. In the unlikely event that another thread is holding the lock, the hs_err printer skips printing the log.

This also makes it possible to call precious logging from within the stack watermark processing code. I think there's a possibility that we might call the following error logging, when we fail to commit memory for a ZPage, when relocating, during stack watermark processing:
`log_error_p(gc)("Failed to commit memory (%s)", err.to_string());`

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

Commit messages:
 - 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing

Changes: https://git.openjdk.java.net/jdk/pull/903/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=903&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254877
  Stats: 27 lines in 2 files changed: 11 ins; 4 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/903.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/903/head:pull/903

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