This bug was introduced by JDK-8284161. "Object.wait (long timeoutMillis)" was changed to call "Object.wait0 (long timeoutMillis)" in JDK-8284161.
When "jhdsb jstack" is executed, the stack and lock information are printed in "sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(PrintStream tty, int frameCount)". This method checks whether the method is java.lang.Object.wait (...) and then reports the waitstate only if the check passes. https://github.com/openjdk/jdk/blob/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java#L103 if (getMethod().getName().asString().equals("wait") && getMethod().getMethodHolder().getName().asString().equals("java/lang/Object")) { However, after JDK-8284161, the waiting thread waits on "java.lang.Object.wait0 (long timeoutMillis)", so it no longer reports the waitstate. I changed "printLockInfo(PrintStream tty, int frameCount)" to check for "java.lang.Object.wait0 (...)". I confirmed that the lock information is correctly printed with this fix. I tested hotspot/jtreg/serviceability/sa/ and jdk/sun/tools/jhsdb/heapconfig/, and there were no regressions by this fix. Would anyone review this change, please? ------------- Commit messages: - 8335743: jhsdb jstack cannot print some information on the waiting thread Changes: https://git.openjdk.org/jdk/pull/20049/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20049&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335743 Stats: 24 lines in 4 files changed: 17 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20049/head:pull/20049 PR: https://git.openjdk.org/jdk/pull/20049
