JDK-8214997 : Crash holding 'access' lock can deadlock in JVMCI compiler thread
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2018-12-07
  • Updated: 2021-08-25
  • Resolved: 2021-08-25
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.
Other
tbdResolved
Related Reports
Relates :  
JDK-8221360 - Eliminate Shared_DirtyCardQ_lock
Relates :  
JDK-8214315 - G1: fatal error: acquiring lock SATB_Q_FL_lock/1 out of order with lock tty_lock/0
Description
If we have a crash (segfault &etc) while holding one of G1's 'access' rank locks in a JVMCI compiler thread, we can deadlock (or recursively crash in a debug build).  The problem is that printing the stack trace for such a thread typically prints an nmethod, which for JVMCI involves resolving a jweak.  If that jweak resolve itself hits a case in the SATB barrier where the same 'access' lock is needed, we deadlock in a product build, or crash in the crash handler in a debug build.  (Fortunately, the crash handler is pretty robust against such recursive failures.)
Comments
After JDK-8221360 there are no 'access' ranked locks.
25-08-2021
Other than printing that touches the nmethod::_jvmci_installed_code, I don't know of any other place where a weak reference would be dereferenced as part of the printing by the error handler.
07-12-2018