> 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 two additional commits since the last revision: - New solution. Use a sync point to force debugger to wait until mainThread is no longer doing a println() - Make printThreadsInfo() public so tests can call it. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20088/files - new: https://git.openjdk.org/jdk/pull/20088/files/b70bcd19..a5d0abc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20088&range=00-01 Stats: 40 lines in 3 files changed: 26 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20088/head:pull/20088 PR: https://git.openjdk.org/jdk/pull/20088
