JDK-8273456 : Do not hold ttyLock around stack walking
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-09-07
  • Updated: 2023-10-26
  • Resolved: 2021-09-10
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 17 JDK 18
17.0.10Fixed 18 b15Fixed
Related Reports
Relates :  
JDK-8273629 - compiler/uncommontrap/TestDeoptOOM.java fails with release VMs
Relates :  
JDK-8273636 - compiler/uncommontrap/TestDeoptOOM.java#id1 failed with "Error: VM option 'LogCompilation' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions."
Relates :  
JDK-8273635 - Attempting to acquire lock StackWatermark_lock/9 out of order with lock tty_lock/3
Description
In PrintDeoptimizationDetails, ttyLock is held to print out information about the compiledVFrame.  This printing with ZGC takes out the StackWatermark_lock which makes StackWatermark_lock have a lower lock ranking than ttyLock.  ttyLock is used to keep xml printing together.
Using a stringStream to compose messages outside the ttyLock, reduces the scope of the lock, at least during deoptimization.

This is one place where the inversion is that requires StackWatermark_lock to be a lower rank than tty.

Stack: [0x00007f5e3e11c000,0x00007f5e3e21d000],  sp=0x00007f5e3e2173e0,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1500cde]  Mutex::check_rank(Thread*)+0xfe
V  [libjvm.so+0x1501661]  Mutex::lock_without_safepoint_check(Thread*)+0x51
V  [libjvm.so+0x18c4e6c]  StackWatermark::process_one()+0x1c
V  [libjvm.so+0x18c5d29]  StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0x89
V  [libjvm.so+0xbf4afd]  frame::frame_size(RegisterMap*) const+0x11d
V  [libjvm.so+0x1abc977]  javaVFrame::print_value() const+0x3b7
V  [libjvm.so+0xaceb2c]  Deoptimization::create_vframeArray(JavaThread*, frame, RegisterMap*, GrowableArray<compiledVFrame*>*, bool)+0x1bc

Here's another:

V  [libjvm.so+0x175889c]  StackWatermark::process_one()+0x1c
V  [libjvm.so+0x1759769]  StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0x89
V  [libjvm.so+0xbc85a5]  frame::sender(RegisterMap*) const+0x105
V  [libjvm.so+0x19d70cd]  WB_VerifyFrames+0x2dd
j  sun.hotspot.WhiteBox.verifyFrames(ZZ)V+0
Comments
Fix request [17u] I backport this to improve debug printing. Low risk. The most critical part, changing the lock rank, is already in 17. Not clean, change to mutex.hpp already in 17. Including JDK-82273629. Test passes. SAP nightly testing passed.
25-10-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1911 Date: 2023-10-24 12:47:19 +0000
24-10-2023
Changeset: 461a467f Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2021-09-10 14:54:47 +0000 URL: https://git.openjdk.java.net/jdk/commit/461a467f91ba19ae35d7833b7d3e74f62f52e19c
10-09-2021