On Tue, 9 Jul 2024 04:43:59 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 This pull request has now been integrated. Changeset: c8a95a76 Author: Chris Plummer <cjplum...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/c8a95a763c169b94c5ba07d2c6fbdf99ba3b9e3b Stats: 39 lines in 3 files changed: 26 ins; 6 del; 7 mod 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent Reviewed-by: amenkov, kevinw, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/20088
