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

[Per Liden]

On Tue, 24 Nov 2020 12:16:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> 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());`
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch '8254877_gclogprecious_locks_rebased' into 8254877_gclogprecious_locks
>  - 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing
>  - Review 2
>  - Review 1
>  - 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing

Update looks good.

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

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