On Tue, 26 Sep 2023 05:03:13 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> @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 bre ak 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. Ok! So we would have to swap the popping and state-update at least. Unless we insert members between them, the updates would still be observable in any order, I suppose, but inserting membars just to make SA happy seems a bit much. Can one of you try swapping and see if that makes the problem appear less often? I could not yet reproduce the bug at all. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15907#discussion_r1336628312
