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

[Chris Plummer]

On Tue, 26 Sep 2023 04:52:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ok, so we are not (usually) at a safepoint, but no threads are moving. But the snapshot can not be taken atomically. Which means that the anonymous-state in the ObjectMonitor and the state of the lock-stack are not necessarily consistent, not even if we swap the popping and owner-update, right? This is what you mean by inconsistent state, right? Or is there a way to get an atomic snapshot of threads *and* monitors?
>> 
>> So yeah, we could print a warning when that happens.
>> 
>> However, even that problem would be pre-existing (monitors not agreeing with each other or with threads), and do we currently print a warning about it?
>
> @rkennke the "snapshot" is atomic - the target VM is suspended.

Atomicity means guaranteeing that a 2 or more operations are executed as if they are single operation from the viewpoint of other threads. There's no such concept with SA. The state is frozen, so SA can look at anything without worrying about the state changing as it looks at it. When I say the JVM is not in a consistent state, one example of that is when the JVM is in the middle of an atomic operation when SA looks at it. Another example is when SA looks at data that is normally only safe to look at when the VM is safe pointing. The code that David pointed out is another example. It's usually protected from observation by other threads by safe pointing, but SA can see the data when it's in the middle of executing this code. Order may or may not matter. Clearly the current order is problematic for SA. Switching the order may or may not be a problem. It depends on whether SA cares that a monitor on the lock_stack of one thread is shown to be owned by another thread. If that does break
  SA, I think SA might be able to recognize the situation and work around it, or just print a warning.

> However, even that problem would be pre-existing (monitors not agreeing with each other or with threads), and do we currently print a warning about it?

Likely not because it is likely not detected and doesn't result in some sort of failure, and probably whoever wrote the original code hadn't considered the possibility. Most of this type of SA error handling code (that result in a warning) is the results of eventually someone noticing a failure of some sort. If no one ever notices a failure, then the error handling is never worked on.

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

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