On Thu, 11 Jul 2024 22:36:05 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> The test hits a breakpoint on thread2 with SUSPEND_EVENT_THREAD policy, so >> only thread2 is suspended. It then does a vm.suspend(), which suspends all >> threads and bumps the suspendCount of thread2 up to 2. It then does an >> eventSet.resume(), which decrements the thread2 suspendCount to 1, so now >> all threads are suspended with a suspendCount of 1. thread2 is then resumed >> and we expect to hit the next thread2 breakpoint. The problem is that >> thread2 can't hit the breakpoint until the main thread has proceeded far >> enough, and if the vm.suspend() that suspended the main thread happens too >> quickly, it won't have proceeded far enough, so thread2 never hits the >> breakpoint. >> >> Essentially we need a vm.resume() to allow the main thread to run, but we >> need to do it in a way that does nullify part of what the test is testing >> for. So in order to allow the vm.resume() but not subvert the intent of the >> test, we first do a thread2.suspend() so the vm.resume() won't resume >> thread2. >> >> Testing in progress: tier1 and tier5 svc testing > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > Fix copyright and jcheck error I agree with Chris that this test is over-complicated. The introduction of the explicit sync makes it easier to understand. I've got also confused by the two pre-existed sub-sequential `vm.resume()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20088#issuecomment-2224350876
