On Fri, 4 Dec 2020 15:30:15 GMT, Richard Reingruber <[email protected]> wrote:
> This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused
> timeout failures when graal is enabled.
>
> The fix is to avoid suspending all threads when a breakpoint is reached and
> then resume
> just the main thread again. This pattern was used in the test case
> EAMaterializeLocalAtObjectPollReturnReturn. It caused timeouts because graal
> threads remained suspended and, running with -Xbatch, the main thread waited
> (with timeout) for completion of compile tasks.
> The fix was applied to all breakpoints in the test. All explicit suspend
> calls now apply only
> to the main test thread and all explicit resume calls apply to all java
> threads.
>
> Testing: duration of the test case EAMaterializeLocalAtObjectPollReturnReturn
> is
> reduced from 30s to 10s.
test/jdk/com/sun/jdi/EATests.java line 1274:
> 1272: o = getLocalRef(env.targetMainThread.frame(0),
> XYVAL_NAME, "xy");
> 1273: } catch (Exception e) {
> 1274: msg("The local variable xy is out of scope because we
> suspended at the wrong bci. Resume and try again! (" + (++retryCount) + ")");
Please move the increment of retryCount to before the msg() call for clarify.
test/jdk/com/sun/jdi/EATests.java line 1275:
> 1273: } catch (Exception e) {
> 1274: msg("The local variable xy is out of scope because we
> suspended at the wrong bci. Resume and try again! (" + (++retryCount) + ")");
> 1275: env.vm().resume();
You are calling `VM.resume()` in a loop, yet you are suspending using
`ThreadReference.suspend()`. Although the it looks like this will work, it
seems that calling `ThreadReference.resume()` would be more appropriate.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1625
