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

[Stefan Karlsson]

On Wed, 28 Oct 2020 13:49:15 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());`

This pull request has now been integrated.

Changeset: 287b829c
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/287b829c
Stats:     19 lines in 1 file changed: 12 ins; 0 del; 7 mod

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

Reviewed-by: eosterlund

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

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