On Mon, 25 Sep 2023 16:16:51 GMT, Roman Kennke <rken...@openjdk.org> wrote:
> 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 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 247: > 245: // Java code and locking state can change at any time. > This code is not > 246: // expected to be precise, so we return null here. > 247: return null; If the JVM is in a consistent state, do we expect that this should not happen? If so, then a warning message would be the usual SA approach. Basically let the user know we detected an issue rather than just quietly succeeding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336208858
