RFR: 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing [v4]
Erik Österlund
eosterlund at openjdk.java.net
Tue Nov 24 13:41:06 UTC 2020
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
Looks good. Quite entertaining that the "leaf" rank is so far away from being a leaf level rank nowadays.
-------------
Marked as reviewed by eosterlund (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/903
More information about the hotspot-gc-dev
mailing list