JDK-8254877 : GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2020-10-16
  • Updated: 2021-01-19
  • Resolved: 2020-12-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b27Fixed
Related Reports
Blocks :  
JDK-8255678 - Add Mutex::try_lock version without rank checks
Relates :  
JDK-8176393 - Fix Mutex ranking system
Description
This is something that can be seen in crashes from stack watermark processing:

in report_fatal 
    detail_fmt=0x7f2e101e92f8 "acquiring lock %s/%d out of order with lock %s/%d -- possible deadlock")
 in Mutex::set_owner_implementation
 in Mutex::set_owner
 in Mutex::lock_without_safepoint_check
 in MutexLocker::MutexLocker
 in GCLogPrecious::print_on_error
 in VMError::report
 in VMError::report_and_die
 in report_vm_error
 in ZVerifyBadOopClosure::do_oop
 in JNIHandleBlock::oops_do
 in Thread::oops_do_no_frames
 in JavaThread::oops_do_no_frames
 in ZVerify::verify_thread_head_bad
 in ZStackWatermark::start_processing_impl
Comments
Changeset: 287b829c Author: Stefan Karlsson <stefank@openjdk.org> Date: 2020-12-02 12:28:38 +0000 URL: https://git.openjdk.java.net/jdk/commit/287b829c
02-12-2020
My proposal was to use try_lock instead of a blocking lock. I implemented this with Semaphores, but this got rejected when I cleaned up the semaphore code to be more generic. Two other alternatives: 1) Use os::PlatformMutex. (causes include pollution because of the class is in the os:: class and can't be forward declared - could probably be fixed) 2) Use Mutex The later has a problem that there's no lock-ordering that works when unrelated locking code is used when printing hs_err files. There will always be the possiblity to have a lock order inversion if a crash happens while holding one of the locks. A solution to this is investigated in JDK-8255678, where the inversion restrictions are lifted for try_lock. The motivation is that if "you got the lock you got the lock" and will make progress. The solution then will be to rewrite locks taken during hs_err printing, to use try_lock instead. I'm hoping for (2), but if it doesn't pan out, then I'll implement (1).
03-11-2020
It is difficult to know what locks you will have when crashing or asserting. It seems unreasonable that the precious GC log constrains that you can't have locks lower than Mutex::tty when crashing, which is currently required. I'm gonna rewrite this so we can crash in a lock-free fashion.
28-10-2020