On Mon, 25 Sep 2023 17:44:56 GMT, Chris Plummer <cjplum...@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. Yes. But unless we run this at a safepoint, there is no consistent state when we race with locking. I don't think we want to spam users with warnings whenever we run into anonymous owners (which is not too infrequent). Existing (pre-lightweight-) locking doesn't print warnings either, when a thread that's expected to lock on an object has moved on or otherwise encounters racy state. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336253796
