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

[Chris Plummer]

On Mon, 25 Sep 2023 18:32:19 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> 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.

I need a better understanding of anonymous owners and the race you think is going on here. 99+% of the time if we are not at a safepoint, pretty much everything still works fine with SA. Safe points guarantee safe access, but not being at a safepoint does not guarantee there will be an issue for SA. It usually still works, and we try to report when it doesn't.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336297000