Symptom
-------

The following test failed in the JDK16 CI because it reached the timeout of 1200 seconds:

com/sun/jdi/EATests.java#id1

Here's a snippet from the log file:

###(Debugger) The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again!


###(Debugger) Debuggee Stack:

frame[0]: EAMaterializeLocalAtObjectPollReturnReturnTarget.dontinline_brkpt_return_Integer() (bci:2)
frame[1]: EAMaterializeLocalAtObjectPollReturnReturnTarget.dontinline_testMethod() (bci:41)
frame[2]: EATestCaseBaseTarget.run() (bci:64)
frame[3]: EATestsTarget.main(java.lang.String[]) (bci:43)

###(Debugger) The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again!


###(Debugger) Debuggee Stack:

frame[0]: EAMate
result: Error. Agent error: java.lang.Exception: Agent 17 timed out with a timeout of 1200 seconds; check console log for any additional details


The test repeated this bit over and over:

###(Debugger) The local variable xy is out of scope because we suspended at the wrong bci. Resume and try again!

Analysis
--------

The test was executed with graal enabled as jvmci client.

The test cases make use of the TestScaffold in a way that all threads, including
graal threads, are suspended when one thread reaches a breakpoint and
subsequentially it resumes just the main thread. This is problematic: graal
threads remain suspended and the main thread blocks because of -Xbatch when it
calls a method that reaches the compile threshold. Note that, if graal is
enabled, -Xbatch won't make a java thread wait unconditionally until a
compilation task is completed. Instead it will continue after a given time
without progress [1].

This is the cause for (a) timeouts (b) a test case's main test methods are not
always compiled after warm-up.

[1] CompileBroker::wait_for_jvmci_completion() is with timeout
    https://github.com/openjdk/jdk/blob/fbdc1877e241552755ea208b890029e60a8df08c/src/hotspot/share/compiler/compileBroker.cpp#L1691