RFR: 8316401: sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"

[Roman Kennke]

On Mon, 25 Sep 2023 17:44:56 GMT, Chris Plummer <cjplummer at 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