On Thu, 11 Jul 2024 04:43:49 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>>> mainThead is suspended and is holding a println related lock, and thread2 >>> is stuck on the 2nd log call in runt2 awaiting the same lock. >> >> The classic example of why suspension is fraught with peril - the target >> must be guaranteed not to be holding any resource needed by the suspender. I >> think removing the logging may be the best bet here - with comments in the >> code to ensure someone does not add it back. Or else use a more primitive >> (native?) mechanism to do the logging, not System.out.println(). > > Which logging should be removed? Alex suggest the logging between breakpoints > 2 and 3, but even that is not enough. There is logging after breakpoint 3, > and that happens before the vm.resume() is done. I'm not saying this can't be > done right, but I think pruning out logging like this in order to fix the > problem not only removes some valuable logging from the test, but still > leaves us open to this type of issue. > > I think the safer thing to do is to make sure mainThread is no longer logging > (or will attempt to log) when the vmsuspend is done. This could be done by > pruning some of its logging, but that has the same negatives as removing some > thread2 logging. My sleep suggestion is by far the simplest. The "purist" fix > would probably be the checkpoint approach (don't do the vm.suspend until > mainThread has reached a stable point). That ended up getting a bit uglier > than I had hoped, but I can finish up the work so you can have a look at it > if you'd like. Sorry I'm unclear on the different threads involved here. IIUC the vm.suspend comes from the debugger, and the mainthread and thread-2 are both threads in the debuggee, being suspended at different times? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673522390
