On Fri, 5 Jul 2024 09:23:21 GMT, KIRIYAMA Takuya <d...@openjdk.org> wrote:
> 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? This pull request has now been integrated. Changeset: d6c6847e Author: KIRIYAMA Takuya <kiriyama.tak...@fujitsu.com> Committer: David Holmes <dhol...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/d6c6847e32673d36a1958cefd1851ec9f3b1e2ad Stats: 25 lines in 4 files changed: 18 ins; 0 del; 7 mod 8335743: jhsdb jstack cannot print some information on the waiting thread Reviewed-by: dholmes, cjplummer, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/20049
