> 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?
KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8335743: jhsdb jstack cannot print some information on the waiting thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20049/files - new: https://git.openjdk.org/jdk/pull/20049/files/1daff6fa..8ebc2b4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20049&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20049&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 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
