The SA can run concurrently with Java threads, SA code that inspects locking state should be able to deal with that. On the other hand, the particular code is only used in printing routine and is not expected to be precise. When resolving an anonymous owner, we may not find one, because Java threads may already have moved on. Instead of crashing with a stacktrace, we should gracefully return null here.
Testing: - [x] sun/tools/jhsdb/JStackStressTest.java - [x] sun/tools/jhsdb - [x] serviceability/sa ------------- Commit messages: - 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock" Changes: https://git.openjdk.org/jdk/pull/15907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15907&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316401 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15907/head:pull/15907 PR: https://git.openjdk.org/jdk/pull/15907
