RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

[Daniel D. Daugherty]

On Wed, 10 Jul 2024 21:28:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thank you for the confirming the reason of the timeout.
>> 
>> To be more clear about my point:
>> The test has 3 scenarios (see the test description):
>> ThreadReference.resume() resumes the thread suspended with:
>>  *   - with thread2.suspend()                                           <BR>
>>  *   - at a breakpoint                                                  <BR>
>>  *   - with VirtualMachine.suspend()                                    <BR>
>> 
>> So for 3rd scenario we should not call vm.resume() (as it converts 3rd scenario to 1st scenario).
>> The test can be fixed by different ways, to me remove logging between breakpoint2 and breakpoint3 is the simplest way.
>> Note that breakpoint2 is "runt2(), line 2" and breakpoint3 is "runt1(), line 7", there are 2 log statements. We can move breakpoint 3 to "runt2(), line 3" (I don't see much sense to have breakpoint 3 so far from breakpoint2 - we just need to ensure the thread was resumed )
>
> Removing log() statements to fix the problem can be risky because someone could re-add them in the future. What about my idea of doing a short sleep before the vm.suspend() to make sure the main thread has advanced to the pipe.readln(), and won't be doing any more log calls until it gets the next command from the debugger (which should be "quit").

Adding a `sleep()` between two statements does not scale when the test in
question is under different loads or run with different options. All it will do
is make a hang more rare (and frustrating to analyze).

We do use short sleeps when we are in a while-loop checking on a condition
of some sort that indicates that the "thing" for which we are waiting to happen
has happened.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1673123705